From noreply at sourceforge.net Thu Feb 1 06:50:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 Jan 2007 21:50:31 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1593073 ] Check_Log problem with log rotation Message-ID: Bugs item #1593073, was opened at 2006-11-08 20:13 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1593073&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Sparhawk (msparhawk) Assigned to: Nobody/Anonymous (nobody) Summary: Check_Log problem with log rotation Initial Comment: Release 1.4.5 In cases where a logfile being monitored is rotated, the matching contents of the oldlogfile (file being used for comparisons) will trigger an error even tho none exist in the active monitored log. On line 200 $DIFF $logfile $oldlog > $tempdiff # Count the number of matching log entries we have count=`$GREP -c "$query" $tempdiff` I'm no developer, but it looks like this doesn't differentiate between matches in oldlog and matches in logfile. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-02-01 00:50 Message: Logged In: YES user_id=375623 Originator: NO this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- Comment By: Mark Sparhawk (msparhawk) Date: 2007-01-25 14:03 Message: Logged In: YES user_id=1640959 Originator: YES I tweaked line 198 to remove diff output from the RHS file (the old log) $DIFF $logfile $oldlog | $GREP -v "^>" > $tempdiff File Added: check_log ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1593073&group_id=29880 From noreply at sourceforge.net Thu Feb 1 20:10:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Feb 2007 11:10:00 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1525363 ] radiusclient-ng vs. check_radius plugin Message-ID: Patches item #1525363, was opened at 2006-07-19 17:19 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1525363&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andy Shevchenko (andy_shev) >Assigned to: Holger Weiss (hweiss) Summary: radiusclient-ng vs. check_radius plugin Initial Comment: Hi! I've done to patch the check_radius for compilant to radiusclient-ng. Related stuff you can find at https://bugzilla.redhat.com/bugzilla/ show_bug.cgi?id=199395 Andy. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-02-01 20:10 Message: Logged In: YES user_id=759506 Originator: NO This patch isn't backward compatible, as it doesn't allow building check_radius against the original 'radiusclient' library. If you could provide a version of the patch which works with both libraries (by defining appropriate macros via Autoconf), I'd look into committing it. Otherwise, I might have a go at it myself, but that might take some time. BTW, personally, I'd prefer 'libradius' over 'radiusclient[-ng]' (for various reasons). Maybe I'll add support for that one sometime ... Thanks! Holger ---------------------------------------------------------------------- Comment By: Andy Shevchenko (andy_shev) Date: 2006-07-19 17:20 Message: Logged In: YES user_id=448807 Url without cuttings: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199395 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1525363&group_id=29880 From noreply at sourceforge.net Thu Feb 1 22:58:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Feb 2007 13:58:29 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1650176 ] check_snmp: Passing -Pu to snmpget command Message-ID: Feature Requests item #1650176, was opened at 2007-02-01 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Andrew Elwell (elwell2000) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp: Passing -Pu to snmpget command Initial Comment: Using a (Badly written) vendor supplied MIB from Areca for a raid card (see http://www.areca.us/support/download/RaidCards/AP_Driver/SNMP_MIBs.zip ) snmpget is only happy if we pass the "-Pu" (ignore underscores) flag to it. I have made a workaround by permanently patching the source of check_snmp.c PROBLEM: # snmpget -v1 -c public hostname ARECA-SNMP-MIB::raidState.0 Bad operator (_): At line 20 in /usr/share/snmp/mibs/ARECA-SNMP-MIB.txt ARECA-SNMP-MIB::raidState.0: Unknown Object Identifier # snmpget -v1 -c public -Pu hostname ARECA-SNMP-MIB::raidState.0 ARECA-SNMP-MIB::raidState.0 = STRING: "Normal" WORKAROUND: /* asprintf (&command_line, "%s -t %d -r %d -m %s -v %s %s %s:%s %s", */ /* Hack below to accept underscores as areca mib broken */ asprintf (&command_line, "%s -Pu -t %d -r %d -m %s -v %s %s %s:%s %s", But it'd be nice to be able to pass this flag to the check_snmp if needed Andrew ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 From noreply at sourceforge.net Fri Feb 2 03:00:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Feb 2007 18:00:23 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1331909 ] pop3(s) email-matching plugin Message-ID: Patches item #1331909, was opened at 2005-10-19 16:38 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1331909&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: kkvenkit (kkvenkit) Assigned to: Nobody/Anonymous (nobody) Summary: pop3(s) email-matching plugin Initial Comment: A Perl plugin to match email in a pop3(s) account. This was developed to monitor more than a dozen remote cron jobs that email results to a common pop3s account. Rather than manually verify an OK response for each check, this plugin is used to check the pop3s account once a day for an email that matches a specific subject. The contents of the email are then searched for specified ok-, warning-, and critical-resulting content. The subject, ok-, warning-, and critical-resulting patterns are Perl regular expressions. The host, username, password, pop3 or pop3s values are arguments to the plugin allowing the plugin to be re-used as many times as required. In addition to the standard ok/warning/critical result message, the line in the email address following the match is displayed. This allows contextual detail to be reported within the nagios interface. All the standard arguments are supported. Suggestions to extend this plugin are encouraged. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-02-02 03:00 Message: Logged In: YES user_id=759506 Originator: NO (Was re-submitted to the 'New Plugins' tracker and closed - see 1331956.) ---------------------------------------------------------------------- Comment By: kkvenkit (kkvenkit) Date: 2005-10-19 16:59 Message: Logged In: YES user_id=1034657 Just realized I submitted this to the wrong tracker. Please ignore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1331909&group_id=29880 From noreply at sourceforge.net Fri Feb 2 03:39:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Feb 2007 18:39:00 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1309349 ] check_http doesn't work with -C (needs -S too) Message-ID: Patches item #1309349, was opened at 2005-09-30 12:16 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: asharris (asharris) Assigned to: Nobody/Anonymous (nobody) Summary: check_http doesn't work with -C (needs -S too) Initial Comment: check_http help suggests: check_http www.verisign.com -C 14 but this does not check the certificate as the -S options is also required. However, to conform to the help, the following patch can be applied: 313c313,315 < check_cert = TRUE; --- > use_ssl = check_cert = TRUE; > if (specify_port == FALSE) > server_port = HTTPS_PORT; This ensures that SSL is enabled for certificate checking. Antony ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-02-02 03:39 Message: Logged In: YES user_id=759506 Originator: NO This was fixed in revision 1.88 of check_http. Thanks! ---------------------------------------------------------------------- Comment By: asharris (asharris) Date: 2005-09-30 12:21 Message: Logged In: YES user_id=1354360 Sorry, didn't realise I needed to use "diff -u". --- check_http.org 2005-09-30 11:14:40.000000000 +0100 +++ check_http.c 2005-09-30 10:44:07.000000000 +0100 @@ -310,7 +310,9 @@ usage2 (_("Invalid certificate expiration period"), optarg); else { days_till_exp = atoi (optarg); - check_cert = TRUE; + use_ssl = check_cert = TRUE; + if (specify_port == FALSE) + server_port = HTTPS_PORT; } #else usage4 (_("Invalid option - SSL is not available")); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1309349&group_id=29880 From noreply at sourceforge.net Fri Feb 2 15:07:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 06:07:16 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1650176 ] check_snmp: Passing -Pu to snmpget command Message-ID: Feature Requests item #1650176, was opened at 2007-02-01 16:58 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Andrew Elwell (elwell2000) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp: Passing -Pu to snmpget command Initial Comment: Using a (Badly written) vendor supplied MIB from Areca for a raid card (see http://www.areca.us/support/download/RaidCards/AP_Driver/SNMP_MIBs.zip ) snmpget is only happy if we pass the "-Pu" (ignore underscores) flag to it. I have made a workaround by permanently patching the source of check_snmp.c PROBLEM: # snmpget -v1 -c public hostname ARECA-SNMP-MIB::raidState.0 Bad operator (_): At line 20 in /usr/share/snmp/mibs/ARECA-SNMP-MIB.txt ARECA-SNMP-MIB::raidState.0: Unknown Object Identifier # snmpget -v1 -c public -Pu hostname ARECA-SNMP-MIB::raidState.0 ARECA-SNMP-MIB::raidState.0 = STRING: "Normal" WORKAROUND: /* asprintf (&command_line, "%s -t %d -r %d -m %s -v %s %s %s:%s %s", */ /* Hack below to accept underscores as areca mib broken */ asprintf (&command_line, "%s -Pu -t %d -r %d -m %s -v %s %s %s:%s %s", But it'd be nice to be able to pass this flag to the check_snmp if needed Andrew ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-02-02 09:07 Message: Logged In: YES user_id=375623 Originator: NO Have you tried: mibAllowUnderline true in snmp.conf (not snmpD.conf!) This should fix your problem. You can also specify numeric OIDs to avoid the need to parse mibs. If you need to specify multiple OIDs be sure to get the latest CVS (or upcoming nagios-plugins release) as it fixes a bug where multiple numeric OIDs would cause check_snmp to load the MIBs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 From noreply at sourceforge.net Fri Feb 2 17:57:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 08:57:32 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1592574 ] Plugin compilation fails in check_ntp.c Message-ID: Bugs item #1592574, was opened at 2006-11-08 11:29 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1592574&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Deon Ramsey (dramsey) >Assigned to: Ton Voon (tonvoon) Summary: Plugin compilation fails in check_ntp.c Initial Comment: I am trying to get Nagios 2.5 running on a RedHat Linux release 7.3 (Valhalla) . I have compiled Nagios itself with no problem, then went on to compile nagios-plugins-1.4.5 . The compiler dies with the following messages: nagios-host# make make all-recursive make[1]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5' Making all in lib make[2]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make all-recursive make[3]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib' Making all in tests make[4]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib/tests' make[4]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make[3]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make[2]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib' Making all in plugins make[2]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/plugins' if /usr/local/bin/gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -O2 -MT check_ntp.o -MD -MP -MF ".deps/check_ntp.Tpo" -c -o check_ntp.o check_ntp.c; \ then mv -f ".deps/check_ntp.Tpo" ".deps/check_ntp.Po"; else rm -f ".deps/check_ntp.Tpo"; exit 1; fi check_ntp.c: In function 'setup_request': check_ntp.c:295: error: invalid operands to binary & check_ntp.c:295: error: invalid operands to binary & check_ntp.c:295: error: invalid operands to binary & check_ntp.c:295: error: invalid operands to binary & make[2]: *** [check_ntp.o] Error 1 make[2]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5' make: *** [all] Error 2 nagios-host# At first, I suspected this to be a compiler error because I was using the gcc-2.96 installed by default in the OS, so I compiled and installed gcc-4.1.1 and tried again, but this didn't change anything. On an aside, I don't even *need* the ntp plugin, is there any support for telling the system not to build it in the first place ? ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-02-02 16:57 Message: Logged In: YES user_id=664364 Originator: NO Hi Deon, This should be fixed in CVS now. Please confirm with the snapshot at http://nagiosplug.sf.net/snapshot. This call will auto close after 7 days if there are no updates. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1592574&group_id=29880 From noreply at sourceforge.net Fri Feb 2 18:01:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 09:01:05 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1523748 ] check_disk should error if warn range is subset of critical Message-ID: Bugs item #1523748, was opened at 2006-07-17 10:37 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dick van den Burg (vandenburgd) Assigned to: Ton Voon (tonvoon) >Summary: check_disk should error if warn range is subset of critical Initial Comment: the new se->w_idfp and se->c_idfp in version 1.4.3 are not initialized resulting in the following error (on HP-UX 11.23) check_disk -c 5% -w 10% -p /dev/vg00/lvol1 INPUT ERROR: C_IDFP (0.000000) should be less than W_IDFP (64768802081573470261722606760322190900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0) and both should be between zero and 100 percent, inclusive for /dev/vg00/lvol1 check_disk: Could not parse arguments Usage: check_disk -w limit -c limit [-p path | -x device] [-t timeout][-m] [-e] [-W limit] [-K limit] [-v] [-q] The following patch corrects this *** check_disk.c Mon Jul 17 11:32:26 2006 --- check_disk.c.good Mon Jul 17 11:32:03 2006 *************** *** 462,467 **** --- 462,469 ---- se->c_df = c_df; se->w_dfp = w_dfp; se->c_dfp = c_dfp; + se->w_idfp = w_idfp; + se->c_idfp = c_idfp; se->found = 0; se->found_len = 0; *pathtail = se; ---------------------------------------------------------------------- Comment By: Dick van den Burg (vandenburgd) Date: 2006-07-17 16:46 Message: Logged In: YES user_id=780242 As the changes in CURRENT deleted every reference to w_idfp and c_idfp the error also disappears. Unfortunately the consistency check also dispappeared. Dick ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-07-17 11:27 Message: Logged In: YES user_id=664364 Dick, Can you try the snapshot at http://nagiosplug.sourceforge.net/snapshot. There have been fixes to check_disk recently. Please update if there is still a problem. I've marked the call in pending so it will autoclose in 7 days. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1523748&group_id=29880 From noreply at sourceforge.net Fri Feb 2 18:04:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 09:04:22 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484825 ] check_dhcp fails to link on Solaris 2.6 Message-ID: Bugs item #1484825, was opened at 2006-05-09 17:35 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp fails to link on Solaris 2.6 Initial Comment: /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a -liconv -lgen -lnsl gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/tmp/nagios-plugins-1.4.3/plugins-root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lresolv ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lnsl -R/usr/local/lib -R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 ===== Modifying the Makefile EXTRA_NETOBJS = getaddrinfo.o gethostbyname.o to EXTRA_NETOBJS = ../plugins/getaddrinfo.o ../plugins/gethostbyname.o fixes it ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-02-02 17:04 Message: Logged In: YES user_id=664364 Originator: NO Hi Duncan, This should be fixed in CVS now. Please can you try the snapshot at http://nagiosplug.sf.net/snapshot. This call with autoclose in 7 days if no updates are applied. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-06-20 19:43 Message: Logged In: YES user_id=664364 Ethan, Can I take this? I want to move the substitute getaddinfo library into lib/. This should fix various other tracker items as well. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 06:19 Message: Logged In: YES user_id=1495257 Same thing occurs on Solaris 7 using gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release): source='check_dhcp.c' object='check_dhcp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -c check_dhcp.c /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a - lgen -lnsl -lssl -lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket - lresolv ../intl/libintl.a -lgen -lnsl -lssl -lcrypto - R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 However on Solaris 8 using gcc version 3.3.2 this problem does not occurr: if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -MT check_dhcp.o -MD -MP -MF ".deps/check_dhcp.Tpo" -c - o check_dhcp.o check_dhcp.c; \ then mv -f ".deps/check_dhcp.Tpo" ".deps/check_dhcp.Po"; else rm -f ".deps/check_dhcp.Tpo"; exit 1; fi /bin/bash ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket - lresolv ../intl/libintl.a -liconv -lgen -lsocket -lssl - lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o - L/home/gtri/nagios/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl - lresolv ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto - R/usr/local/lib -R/usr/local/lib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 From noreply at sourceforge.net Fri Feb 2 18:05:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 09:05:35 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484822 ] check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Message-ID: Bugs item #1484822, was opened at 2006-05-09 17:31 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) >Assigned to: Ton Voon (tonvoon) Summary: check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Initial Comment: make[3]: Entering directory `/tmp/nagios-plugins-1.4.3/plugins' if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagioscl/package/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -Wall -g -O2 -MT check_smtp.o -MD -MP -MF ".deps/check_smtp.Tpo" -c -o check_smtp.o check_smtp.c; \ then mv -f ".deps/check_smtp.Tpo" ".deps/check_smtp.Po"; else rm -f ".deps/check_smtp.Tpo"; exit 1; fi check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: error: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.3' make: *** [all] Error 2 ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-02-02 17:05 Message: Logged In: YES user_id=664364 Originator: NO Hi Duncan and bubbafat, Hi Duncan, I think this is fixed in CVS now. Please can you try the snapshot at http://nagiosplug.sf.net/snapshot. This call with autoclose in 7 days if no updates are applied. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 06:25 Message: Logged In: YES user_id=1495257 Same thing happens on Solaris 7 with gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release). source='check_smtp.c' object='check_smtp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I/usr/local/include -I/usr/local/include -Wall -g -O2 -c check_smtp.c check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3' make: *** [all] Error 2 A lame fix is: --- nagios-plugins-1.4.3/plugins/check_smtp.c Wed Nov 2 03:47:26 2005 +++ nagios-plugins-1.4.3m/plugins/check_smtp.c Mon Apr 24 22:52:01 2006 @@ -26,6 +26,7 @@ #include "common.h" #include "netutils.h" #include "utils.h" +#include #ifdef HAVE_SSL int check_cert = FALSE; However, on Solaris 8 with gcc version 3.3.2, this is not needed. netdb.h gets included somehow. Haven't been able to trace it down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 From noreply at sourceforge.net Fri Feb 2 18:33:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 09:33:54 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1446016 ] check_jabber forces SSL Message-ID: Bugs item #1446016, was opened at 2006-03-08 23:40 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1446016&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Hadmut Danisch (hadmut) Assigned to: M. Sean Finney (seanius) Summary: check_jabber forces SSL Initial Comment: Hi, if check_tcp is called as check_jabber it forces the SSL flag to be set and thus fails to check jabber daemons without SSL. There are reasons to use jabber without SSL, e.g. when client certificates are required. Since jabberd does not support this feature, it must be used with stunnel. Since check_tcp does not support client certificates, it must check the unencrypted port directly, which is impossible due to the SSL enforcement. regards Hadmut ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2007-02-02 17:33 Message: Logged In: YES user_id=664364 Originator: NO Hadmut, This has been fixed in CVS now by Thomas Guyot - check_jabber will not use SSL by default. Ton ---------------------------------------------------------------------- Comment By: Hadmut Danisch (hadmut) Date: 2006-04-01 09:59 Message: Logged In: YES user_id=44878 Hi, sorry for answering so late, but I had difficulties in logging me in into sourceforge, the server seems to have been down or under maintenance several times. Introducing client certs would be a pretty good idea, also for other checks. :-) But this still does not solve the problem how to verify services without SSL. In my particular case the jabberd sits behind an stunnel, so I would need to check it twice, once without SSL from inside, and once with a SSL client certificate from outside. Both checks are currently impossible. BTW: the client cert and the certificate age check should be enabled for all types of SSL query, including things like SMTP+TLS etc. It does not make sense to offer a server, because I simply use stunnel to provide services. You can easily setup this on your own machine by using an /etc/inetd.conf entry like ssljabber stream tcp nowait root /usr/sbin/stunnel stunnel -v 3 -N rackjabber -p /etc/ssl/private/jabber.pem -r 5222 or any other TCP service. See the stunnel manual (just add ssljabber with a different port number to /etc/services) regards Hadmut ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2006-03-13 17:53 Message: Logged In: YES user_id=226838 hi hadmut, would a better solution be to introduce client cert checking? this was on my todo list for check_tcp quite a while ago but i never got around to it largely because i don't have any setups that require it. if you'd be interested in pursuing this and have a server i could test with maybe we could work together on this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1446016&group_id=29880 From noreply at sourceforge.net Fri Feb 2 20:46:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Feb 2007 11:46:06 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484822 ] check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Message-ID: Bugs item #1484822, was opened at 2006-05-09 16:31 Message generated for change (Comment added) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Ton Voon (tonvoon) Summary: check_smtp.c in 1.4.3 fails to compile on Solaris 2.6 Initial Comment: make[3]: Entering directory `/tmp/nagios-plugins-1.4.3/plugins' if gcc -DLOCALEDIR=\"/home/loki/fergusod/cvsroot/nagios2/shared/egg-nagioscl/package/usr/local/nagios2/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -Wall -g -O2 -MT check_smtp.o -MD -MP -MF ".deps/check_smtp.Tpo" -c -o check_smtp.o check_smtp.c; \ then mv -f ".deps/check_smtp.Tpo" ".deps/check_smtp.Po"; else rm -f ".deps/check_smtp.Tpo"; exit 1; fi check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: error: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.3' make: *** [all] Error 2 ---------------------------------------------------------------------- >Comment By: Duncan Ferguson (duncan_ferguson) Date: 2007-02-02 19:46 Message: Logged In: YES user_id=865292 Originator: YES Thanks. However, since I have just changed job I am unable to test. This one is down to bubbafat. Duncs ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-02-02 17:05 Message: Logged In: YES user_id=664364 Originator: NO Hi Duncan and bubbafat, Hi Duncan, I think this is fixed in CVS now. Please can you try the snapshot at http://nagiosplug.sf.net/snapshot. This call with autoclose in 7 days if no updates are applied. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-12 05:25 Message: Logged In: YES user_id=1495257 Same thing happens on Solaris 7 with gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release). source='check_smtp.c' object='check_smtp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I/usr/local/include -I/usr/local/include -Wall -g -O2 -c check_smtp.c check_smtp.c: In function `main': check_smtp.c:179: warning: implicit declaration of function `gethostbyname' check_smtp.c:179: warning: assignment makes pointer from integer without a cast check_smtp.c:181: dereferencing pointer to incomplete type make[3]: *** [check_smtp.o] Error 1 make[3]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3' make: *** [all] Error 2 A lame fix is: --- nagios-plugins-1.4.3/plugins/check_smtp.c Wed Nov 2 03:47:26 2005 +++ nagios-plugins-1.4.3m/plugins/check_smtp.c Mon Apr 24 22:52:01 2006 @@ -26,6 +26,7 @@ #include "common.h" #include "netutils.h" #include "utils.h" +#include #ifdef HAVE_SSL int check_cert = FALSE; However, on Solaris 8 with gcc version 3.3.2, this is not needed. netdb.h gets included somehow. Haven't been able to trace it down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484822&group_id=29880 From ton.voon at altinity.com Mon Feb 5 15:23:22 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 5 Feb 2007 14:23:22 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170256799.5612.23.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> Message-ID: <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> Hi Sean, John and Tobias, On 31 Jan 2007, at 15:19, sean finney wrote: > On Wed, 2007-01-31 at 12:50 +0000, Ton Voon wrote: >> QUOTING IN CONFIG FILE > > i think we should be very, very clear on this. my opinion is that > we shouldn't do any quote parsing/interpretation, and pass what > is given verbatim to the plugin. so for example > > [check_myname] > fullname=Sean Finney > > would be the equivalent of > > ./check_myname --fullname='Sean Finney' > > and > > [check_myname] > fullname="Sean Finney" > > would be > > ./check_myname --fullname='"Sean Finney"' > > and that as andreas suggested, we allow for escaping single characters > with a backslash character (which wouldn't be necessary in any of the > above, but might be necessary for some other reason). > > maybe we should just pony-up and do a formal grammar for it? > > inifile := (discarded|stanza)* > discarded := (whitespace)*(commentchar freetext)? newline > freetext := [^(newline)]* > newline := '\n' > commentchar := "#" | ';' > stanza := start declarations > start := "[" name "]" newline > name := [[:alnum:]]* > declarations := (declaration declarations) | nothing > declaration := whitespace name whitespace "=" freetext newline > > not sure if that covers everything... for example can a stanza > have no > declarations? It seems to me that the big dispute at the moment is the quoting of the config file. I assume this means everyone is happy about everything else in the RFC :) I agree that there needs to be clarity on the syntax, but I don't necessarily agree that we need to go down the road of creating a (nother) implementation of ini file parsing. It could just be an education issue. Can I suggest that we start with using an existing library first - I would choose http://ndevilla.free.fr/iniparser/html/index.html from http://en.wikipedia.org/wiki/INI_file for the C implementation. Once we have it integrated, we'd understand better the positives and negatives. As Sean points out, an iniparser_getdict() to return a list of keywords for a section would be a worthwhile enhancement to that library - this could be something that we contribute back upstream. If we find further down in the development cycle that this library is not sufficient, hopefully there would be a precise list of what features it lacks. I'm happy to add to the RFC that the config file syntax is not finalised, to set that expectation before we make it publicly available. I personally think the option handling part is the more difficult bit to code, so I don't want to get too distracted by the config syntax bit. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From klausman at schwarzvogel.de Mon Feb 5 15:30:58 2007 From: klausman at schwarzvogel.de (Tobias Klausmann) Date: Mon, 5 Feb 2007 15:30:58 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> Message-ID: <20070205143058.GA11064@eric.schwarzvogel.de> Hi! On Mon, 05 Feb 2007, Ton Voon wrote: > > On Wed, 2007-01-31 at 12:50 +0000, Ton Voon wrote: > >> QUOTING IN CONFIG FILE > > > > i think we should be very, very clear on this. my opinion is that > > we shouldn't do any quote parsing/interpretation, and pass what > > is given verbatim to the plugin. > > It seems to me that the big dispute at the moment is the quoting of > the config file. I assume this means everyone is happy about > everything else in the RFC :) Speaks for its quality :) > I agree that there needs to be clarity on the syntax, but I don't > necessarily agree that we need to go down the road of creating a > (nother) implementation of ini file parsing. It could just be an > education issue. > > Can I suggest that we start with using an existing library first - I > would choose http://ndevilla.free.fr/iniparser/html/index.html from > http://en.wikipedia.org/wiki/INI_file for the C implementation. Once > we have it integrated, we'd understand better the positives and > negatives. As Sean points out, an iniparser_getdict() to return a > list of keywords for a section would be a worthwhile enhancement to > that library - this could be something that we contribute back > upstream. If we find further down in the development cycle that this > library is not sufficient, hopefully there would be a precise list of > what features it lacks. > > I'm happy to add to the RFC that the config file syntax is not > finalised, to set that expectation before we make it publicly available. > > I personally think the option handling part is the more difficult bit > to code, so I don't want to get too distracted by the config syntax bit. I'm fine with this as long as we keep an eye out for incompatibilities. Having to tell Python users they can't use their language's stdlib ini-parsing module because it's incompatible won't come across terribly good, I guess :) Regards, Tobias PS: Reminds me of having hostnames identical in DNS and Novell's NDS: due to incompatibilities, you're stuck with case-folded [a-z0-9] and - plus various more complicated rules regarding leading and trailing - and numbers. Not nice. -- Never touch a burning system. From seanius at seanius.net Mon Feb 5 15:49:12 2007 From: seanius at seanius.net (sean finney) Date: Mon, 05 Feb 2007 15:49:12 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> Message-ID: <1170686952.6749.45.camel@localhost> On Mon, 2007-02-05 at 14:23 +0000, Ton Voon wrote: > Can I suggest that we start with using an existing library first - I > would choose http://ndevilla.free.fr/iniparser/html/index.html from > http://en.wikipedia.org/wiki/INI_file for the C implementation. Once > we have it integrated, we'd understand better the positives and > negatives. As Sean points out, an iniparser_getdict() to return a > list of keywords for a section would be a worthwhile enhancement to > that library - this could be something that we contribute back > upstream. If we find further down in the development cycle that this > library is not sufficient, hopefully there would be a precise list of > what features it lacks. more to the point, the above library not really usable *unless* it has some kind of iterator like that (or better an iterator over a the matching subset). the only other option would be to pass the long_opts struct to the ini-file-parsing function, and have it specifically look for all keys in --long-opts. however, over the weekend i started hacking out a bit of code for the ini parsing... perhaps it was a bit premature to do so given what you've said, but it does mean the wheel is already half-re-invented. with comments and natural use of whitespace it's currently 178 LoC, and would probably be less than 2x that to finish it. the iniparser LoC is an order of magnitude larger (~2000 just for the src dir), fwiw :) sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Mon Feb 5 15:59:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Feb 2007 06:59:14 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1652471 ] check_http is missing http Accept: header Message-ID: Bugs item #1652471, was opened at 2007-02-05 15:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1652471&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Vavra (vavra) Assigned to: Nobody/Anonymous (nobody) Summary: check_http is missing http Accept: header Initial Comment: check_http is not sending an "Accept:" header when connecting to http servers. Please add something like /* Accept Header */ asprintf (&buf, "%sAccept: text/html\r\n",buf); in function check_http() in check_http.c somewhere after /* optionally send the host header info */ if (host_name) asprintf (&buf, "%sHost: %s\r\n", buf, host_name); If you can spend some more time on this plugin, optionally add a command line parameter to let caller set/override this option (i.e. for changing "Accept:" from "text/html" to "text/xml"). Regards Andi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1652471&group_id=29880 From seanius at seanius.net Mon Feb 5 16:04:24 2007 From: seanius at seanius.net (sean finney) Date: Mon, 05 Feb 2007 16:04:24 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070205143058.GA11064@eric.schwarzvogel.de> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <20070205143058.GA11064@eric.schwarzvogel.de> Message-ID: <1170687864.6749.57.camel@localhost> hey guys, On Mon, 2007-02-05 at 15:30 +0100, Tobias Klausmann wrote: > I'm fine with this as long as we keep an eye out for > incompatibilities. Having to tell Python users they can't use > their language's stdlib ini-parsing module because it's > incompatible won't come across terribly good, I guess :) i sort of have my opinions about what the syntax should be, but this is a really good point. before we finalize the syntax we should take into consideration how it would be implemented in each language we care about[1], and make sure there are no fundamental limitations with the particular syntax we've chosen. sean [1] for us that's really only c and perl, but i think python ought to be included as well. any others? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ton.voon at altinity.com Mon Feb 5 16:07:45 2007 From: ton.voon at altinity.com (Ton Voon) Date: Mon, 5 Feb 2007 15:07:45 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170686952.6749.45.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <1170686952.6749.45.camel@localhost> Message-ID: <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> On 5 Feb 2007, at 14:49, sean finney wrote: > however, over the weekend i started hacking out a bit of code for the > ini parsing... perhaps it was a bit premature to do so given what > you've said, but it does mean the wheel is already half-re-invented. > with comments and natural use of whitespace it's currently 178 LoC, > and > would probably be less than 2x that to finish it. the iniparser > LoC is > an order of magnitude larger (~2000 just for the src dir), fwiw :) I like to think I give more consideration to people that have something to show - Gavin did some research into the "replacement inline" and said it was hard to do in perl, so that swayed decisions about switching to "defaults from config file". I'm happy to go with your parser and see where it takes us. Can we hold off finalising the syntax of the config files? I'm wondering if we need to compare with the perl implementation. Gavin, would you like to recommend a perl module to use? I'd like to be involved in the test cases to ensure the same config file works across languages. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Mon Feb 5 19:20:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Feb 2007 10:20:22 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1652625 ] po/Makefile broken Message-ID: Bugs item #1652625, was opened at 2007-02-05 18:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1652625&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: jspilon (jspilon) Assigned to: Nobody/Anonymous (nobody) Summary: po/Makefile broken Initial Comment: Version: 1.4.6 O/S: debian sarge 3.1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.6/plugins-root' Making install in po make[1]: Entering directory `/tmp/nagios-plugins-1.4.6/po' /bin/sh @MKINSTALLDIRS@ /var/nagios/share @MKINSTALLDIRS@: @MKINSTALLDIRS@: No such file or directory make[1]: *** [install-data-yes] Error 127 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.6/po' make: *** [install-recursive] Error 1 The problem appeared to be in po/Makefile I changed the following to get it working. 33c33 < MKINSTALLDIRS = ../mkinstalldirs --- > MKINSTALLDIRS = @MKINSTALLDIRS@ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1652625&group_id=29880 From gavin at openfusion.com.au Mon Feb 5 23:10:00 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Tue, 6 Feb 2007 09:10:00 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <1170686952.6749.45.camel@localhost> <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> Message-ID: <20070205221000.GA1287@openfusion.com.au> On Mon, Feb 05, 2007 at 03:07:45PM +0000, Ton Voon wrote: > > On 5 Feb 2007, at 14:49, sean finney wrote: > > > however, over the weekend i started hacking out a bit of code for the > > ini parsing... perhaps it was a bit premature to do so given what > > you've said, but it does mean the wheel is already half-re-invented. > > with comments and natural use of whitespace it's currently 178 LoC, > > and > > would probably be less than 2x that to finish it. the iniparser > > LoC is > > an order of magnitude larger (~2000 just for the src dir), fwiw :) > > I like to think I give more consideration to people that have > something to show - Gavin did some research into the "replacement > inline" and said it was hard to do in perl, so that swayed decisions > about switching to "defaults from config file". > > I'm happy to go with your parser and see where it takes us. > > Can we hold off finalising the syntax of the config files? I'm > wondering if we need to compare with the perl implementation. Gavin, > would you like to recommend a perl module to use? I'd like to be > involved in the test cases to ensure the same config file works > across languages. There are a zillion ini-parsing modules in perl (of course). I'd recommend we start with Config::Tiny, which is the super-minimalist version, but should probably still do what we want here. I'll dig out the branch where I'd started looking at this and see if I can get a perl version up in the next couple of days. Cheers, Gavin From benoit.mortier at opensides.be Tue Feb 6 10:36:35 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Tue, 6 Feb 2007 10:36:35 +0100 Subject: [Nagiosplug-devel] localization of the perl plugin Message-ID: <200702061036.36358.benoit.mortier@opensides.be> Hello all, Let me introduce myself, i'am the person responsible for the localization of the plugins. Now that we have a framework to correctly localize the plugin, i'am asking if there is some people willing to translate them in their own languages. If you are interested by this task just reply and i will send you back the file needed. Cheers -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From jd at op5.se Tue Feb 6 10:49:28 2007 From: jd at op5.se (Johannes Dagemark) Date: Tue, 06 Feb 2007 10:49:28 +0100 Subject: [Nagiosplug-devel] localization of the perl plugin In-Reply-To: <200702061036.36358.benoit.mortier@opensides.be> References: <200702061036.36358.benoit.mortier@opensides.be> Message-ID: <45C84F28.3020803@op5.se> Hello Benoit I think I could contribute with at least a Swedish translation of the plugins. Best regards Johannes Dagemark op5 AB Benoit Mortier wrote: > Hello all, > > Let me introduce myself, i'am the person responsible for the localization of > the plugins. > > Now that we have a framework to correctly localize the plugin, i'am asking > if there is some people willing to translate them in their own languages. > > If you are interested by this task just reply and i will send you back the > file needed. > > Cheers From noreply at sourceforge.net Tue Feb 6 13:37:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Feb 2007 04:37:15 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653253 ] check_nt: Wrong Unit in perfdata Message-ID: Bugs item #1653253, was opened at 2007-02-06 12:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653253&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: check_nt: Wrong Unit in perfdata Initial Comment: These Plugin puts everytime I call it, an % into the perfdata. The % is the Perfunit like this: Perfdata= 65.000000%;0.000000;0.000000;0 Is there an patch available or must I execute the check_nt plugin in an other way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653253&group_id=29880 From ae at op5.se Tue Feb 6 16:19:42 2007 From: ae at op5.se (Andreas Ericsson) Date: Tue, 06 Feb 2007 16:19:42 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170687864.6749.57.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <20070205143058.GA11064@eric.schwarzvogel.de> <1170687864.6749.57.camel@localhost> Message-ID: <45C89C8E.3090507@op5.se> sean finney wrote: > > [1] for us that's really only c and perl, but i think python ought to > be included as well. any others? Shell. I think I could hack something up in sed to read it though, or we could supply a helper program in C to do it from shell. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From benoit.mortier at opensides.be Tue Feb 6 19:40:03 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Tue, 6 Feb 2007 19:40:03 +0100 Subject: [Nagiosplug-devel] localization of the perl plugin In-Reply-To: <45C84F28.3020803@op5.se> References: <200702061036.36358.benoit.mortier@opensides.be> <45C84F28.3020803@op5.se> Message-ID: <200702061940.04923.benoit.mortier@opensides.be> Le Mardi 6 F?vrier 2007 10:49, Johannes Dagemark a ?crit?: > Hello Benoit > > I think I could contribute with at least a Swedish translation of the > plugins. Hello, Thanks for your offer, i have send a mail with the file and the explanation to your private mail. Cheers -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From seanius at seanius.net Tue Feb 6 20:50:55 2007 From: seanius at seanius.net (sean finney) Date: Tue, 06 Feb 2007 20:50:55 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <1170686952.6749.45.camel@localhost> <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> Message-ID: <1170791456.24813.11.camel@localhost> On Mon, 2007-02-05 at 15:07 +0000, Ton Voon wrote: > On 5 Feb 2007, at 14:49, sean finney wrote: > > > however, over the weekend i started hacking out a bit of code for the > > ini parsing... perhaps it was a bit premature to do so given what > > you've said, but it does mean the wheel is already half-re-invented. > > with comments and natural use of whitespace it's currently 178 LoC, > > and > > would probably be less than 2x that to finish it. the iniparser > > LoC is > > an order of magnitude larger (~2000 just for the src dir), fwiw :) > > I like to think I give more consideration to people that have > something to show - Gavin did some research into the "replacement > inline" and said it was hard to do in perl, so that swayed decisions > about switching to "defaults from config file". okay, i've put the finishing touches on it and committed it (parse_ini.c and parse_ini.h). there's also a small main function in parse_ini.c to show how the function works in case it's not obvious. the only publicly exported function is: char* np_get_defaults(const char *locator, const char *default_section); where locator is in the form [stanza[@[inifile]]]. if i mis-remembered that it's [[[stanza]@]inifile] it shouldn't be too hard to flipflop the logic. the string returned is either a NULL pointer or a dynamically allocated string in the form "--foo=bar --foo2=bar2....". i haven't incorporated it into the build system or anything at this point (having a library with main() in it wouldn't work so well anyway), so if you want to give it a go prep the build area as normal and then the following ought to compile it into a.out: gcc -Wall -g parse_ini.c -I../plugins -I.. -I../gl utils_base.o there are still the fine details like syntax/quoting/etc, but the hard work is done. both files with comments/whitespace and the unnecessary main function included are 266 LoC total, most of which is dedicated to allocation and parsing. don't you just love c? :) i'd appreciate those with the time and the C-fu to take a look at the code, double checking for off-by-one and similar type stuff. questions, comments, etc are also encouraged :) sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From noreply at sourceforge.net Wed Feb 7 10:14:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 01:14:10 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653934 ] wrong order of header files in check_swap.c Message-ID: Bugs item #1653934, was opened at 2007-02-07 10:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: wrong order of header files in check_swap.c Initial Comment: In plugins/check_swap.c the order of header files to include is wrong for at least OpenBSD. sys/param.h needs to be included before sys/swap.h. See the attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 From noreply at sourceforge.net Wed Feb 7 13:29:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 04:29:22 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653934 ] wrong order of header files in check_swap.c Message-ID: Bugs item #1653934, was opened at 2007-02-07 10:14 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) >Assigned to: Holger Weiss (hweiss) Summary: wrong order of header files in check_swap.c Initial Comment: In plugins/check_swap.c the order of header files to include is wrong for at least OpenBSD. sys/param.h needs to be included before sys/swap.h. See the attached patch. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-02-07 13:29 Message: Logged In: YES user_id=759506 Originator: NO As I currently don't have access to an OpenBSD box, as is not documented as a general requirement for on OpenBSD[*], and as I cannot reproduce the problem on NetBSD or FreeBSD: What happens without your patch? Could you post the error message you get during compilation? Thanks a lot! Holger [*] See: http://www.openbsd.org/cgi-bin/man.cgi?query=swapctl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 From noreply at sourceforge.net Wed Feb 7 14:03:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 05:03:35 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653934 ] wrong order of header files in check_swap.c Message-ID: Bugs item #1653934, was opened at 2007-02-07 10:14 Message generated for change (Comment added) made by nsturm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Holger Weiss (hweiss) Summary: wrong order of header files in check_swap.c Initial Comment: In plugins/check_swap.c the order of header files to include is wrong for at least OpenBSD. sys/param.h needs to be included before sys/swap.h. See the attached patch. ---------------------------------------------------------------------- >Comment By: nsturm (nsturm) Date: 2007-02-07 14:03 Message: Logged In: YES user_id=1323236 Originator: YES Here is the error message: if cc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/local/include/postgresql - I/usr/include -I/usr/include/kerberosV -I/usr/local/include -O2 -pipe -DLDAP_ DEPRECATED -Wformat -Wbounded -MT check_swap.o -MD -MP -MF ".deps/check_swap.Tpo " -c -o check_swap.o check_swap.c; then mv -f ".deps/check_swap.Tpo" ".deps/che ck_swap.Po"; else rm -f ".deps/check_swap.Tpo"; exit 1; fi In file included from check_swap.c:46: /usr/include/sys/swap.h:52: error: `MAXPATHLEN' undeclared here (not in a function) ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-02-07 13:29 Message: Logged In: YES user_id=759506 Originator: NO As I currently don't have access to an OpenBSD box, as is not documented as a general requirement for on OpenBSD[*], and as I cannot reproduce the problem on NetBSD or FreeBSD: What happens without your patch? Could you post the error message you get during compilation? Thanks a lot! Holger [*] See: http://www.openbsd.org/cgi-bin/man.cgi?query=swapctl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 From noreply at sourceforge.net Wed Feb 7 14:43:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 05:43:43 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1650176 ] check_snmp: Passing -Pu to snmpget command Message-ID: Feature Requests item #1650176, was opened at 2007-02-01 16:58 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Priority: 5 Private: No Submitted By: Andrew Elwell (elwell2000) >Assigned to: Thomas Guyot (dermoth) Summary: check_snmp: Passing -Pu to snmpget command Initial Comment: Using a (Badly written) vendor supplied MIB from Areca for a raid card (see http://www.areca.us/support/download/RaidCards/AP_Driver/SNMP_MIBs.zip ) snmpget is only happy if we pass the "-Pu" (ignore underscores) flag to it. I have made a workaround by permanently patching the source of check_snmp.c PROBLEM: # snmpget -v1 -c public hostname ARECA-SNMP-MIB::raidState.0 Bad operator (_): At line 20 in /usr/share/snmp/mibs/ARECA-SNMP-MIB.txt ARECA-SNMP-MIB::raidState.0: Unknown Object Identifier # snmpget -v1 -c public -Pu hostname ARECA-SNMP-MIB::raidState.0 ARECA-SNMP-MIB::raidState.0 = STRING: "Normal" WORKAROUND: /* asprintf (&command_line, "%s -t %d -r %d -m %s -v %s %s %s:%s %s", */ /* Hack below to accept underscores as areca mib broken */ asprintf (&command_line, "%s -Pu -t %d -r %d -m %s -v %s %s %s:%s %s", But it'd be nice to be able to pass this flag to the check_snmp if needed Andrew ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-02-07 08:43 Message: Logged In: YES user_id=375623 Originator: NO This feature request will auto-close in 14 days of inactivity. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-02-02 09:07 Message: Logged In: YES user_id=375623 Originator: NO Have you tried: mibAllowUnderline true in snmp.conf (not snmpD.conf!) This should fix your problem. You can also specify numeric OIDs to avoid the need to parse mibs. If you need to specify multiple OIDs be sure to get the latest CVS (or upcoming nagios-plugins release) as it fixes a bug where multiple numeric OIDs would cause check_snmp to load the MIBs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 From noreply at sourceforge.net Wed Feb 7 15:12:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 06:12:12 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1653934 ] wrong order of header files in check_swap.c Message-ID: Bugs item #1653934, was opened at 2007-02-07 10:14 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Holger Weiss (hweiss) Summary: wrong order of header files in check_swap.c Initial Comment: In plugins/check_swap.c the order of header files to include is wrong for at least OpenBSD. sys/param.h needs to be included before sys/swap.h. See the attached patch. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-02-07 15:12 Message: Logged In: YES user_id=759506 Originator: NO Odd, according to swapctl(2), this shouldn't be necessary. However, I've committed your patch to CVS. Thank you very much! Holger ---------------------------------------------------------------------- Comment By: nsturm (nsturm) Date: 2007-02-07 14:03 Message: Logged In: YES user_id=1323236 Originator: YES Here is the error message: if cc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../gl -I../intl -I/usr/include/ldap -I/usr/local/include/postgresql - I/usr/include -I/usr/include/kerberosV -I/usr/local/include -O2 -pipe -DLDAP_ DEPRECATED -Wformat -Wbounded -MT check_swap.o -MD -MP -MF ".deps/check_swap.Tpo " -c -o check_swap.o check_swap.c; then mv -f ".deps/check_swap.Tpo" ".deps/che ck_swap.Po"; else rm -f ".deps/check_swap.Tpo"; exit 1; fi In file included from check_swap.c:46: /usr/include/sys/swap.h:52: error: `MAXPATHLEN' undeclared here (not in a function) ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2007-02-07 13:29 Message: Logged In: YES user_id=759506 Originator: NO As I currently don't have access to an OpenBSD box, as is not documented as a general requirement for on OpenBSD[*], and as I cannot reproduce the problem on NetBSD or FreeBSD: What happens without your patch? Could you post the error message you get during compilation? Thanks a lot! Holger [*] See: http://www.openbsd.org/cgi-bin/man.cgi?query=swapctl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1653934&group_id=29880 From ton.voon at altinity.com Wed Feb 7 15:47:57 2007 From: ton.voon at altinity.com (Ton Voon) Date: Wed, 7 Feb 2007 14:47:57 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170791456.24813.11.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <1170686952.6749.45.camel@localhost> <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> <1170791456.24813.11.camel@localhost> Message-ID: On 6 Feb 2007, at 19:50, sean finney wrote: > okay, i've put the finishing touches on it and committed it > (parse_ini.c > and parse_ini.h). there's also a small main function in > parse_ini.c to > show how the function works in case it's not obvious. the only > publicly > exported function is: > > char* np_get_defaults(const char *locator, const char > *default_section); > > where locator is in the form [stanza[@[inifile]]]. if i mis- > remembered > that it's [[[stanza]@]inifile] it shouldn't be too hard to flipflop > the > logic. the string returned is either a NULL pointer or a dynamically > allocated string in the form "--foo=bar --foo2=bar2....". > > i haven't incorporated it into the build system or anything at this > point (having a library with main() in it wouldn't work so well > anyway), > so if you want to give it a go prep the build area as normal and then > the following ought to compile it into a.out: > > gcc -Wall -g parse_ini.c -I../plugins -I.. -I../gl utils_base.o > > there are still the fine details like syntax/quoting/etc, but the > hard work is done. both files with comments/whitespace and the > unnecessary main function included are 266 LoC total, most of which is > dedicated to allocation and parsing. don't you just love c? :) > > i'd appreciate those with the time and the C-fu to take a look at the > code, double checking for off-by-one and similar type stuff. > questions, > comments, etc are also encouraged :) Good work, Sean! I've added some extra files in CVS, with two test ini files - one of which is based on Config::Tiny's test file. I don't think they should conflict with the existing build. You're right about not having these files in the build system, so I've added a Makefile.config-opts into lib/ and lib/tests/. A make -f Makefile.config-opts in lib/ will create the library object file. If you install libtap (there are some instructions on http:// tinderbox.altinity.org) and go into lib/tests/ and run make, it will create a ./test_ini executable. Run this to run some tests. At the moment, there are failures re: whitespace at the end of lines. There are some extra tests as well commented out in test_ini.c, but these are segfaulting for me. A few comments: - I've removed the main() section in parse_ini.c since we can test in test_ini.c now - the section name cannot contain "@". I think this is fair enough, so will add into RFC - Config::Tiny removes leading and trailing whitespace in the stanza name for legibility reasons - good idea? I've got some tests for those, but they are segfaulting - Config::Tiny allows parameter/values before any stanzas. We have reserved the stanza name "default" in the RFC - is it better to just have that first part as reserved? - your routine allows comments after a parameter/value, but Config::Tiny doesn't. Should we recommend not using this or patch Config::Tiny? I'll merge the RFC into the dev guidelines since I think we're all in agreement to do this. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From traxplayer at gmail.com Wed Feb 7 17:01:22 2007 From: traxplayer at gmail.com (=?ISO-8859-1?Q?Martin_M=F8ller_Pedersen?=) Date: Wed, 7 Feb 2007 17:01:22 +0100 Subject: [Nagiosplug-devel] (no subject) Message-ID: -- "All general statements are false." "If atheism is a religion, then not collecting stamps is a hobby." A: Fordi det ?ndrer r?kkef?lgen folk normalt kommunikerer p?. Q: Hvorfor er top-svar en d?rlig ting? A: Top-svar. Q: Hvad er det mest irriterende i e-mail? "We are all atheists about most of the gods that humanity has ever believed in. Some of us just go one god further." From traxplayer at gmail.com Wed Feb 7 17:14:22 2007 From: traxplayer at gmail.com (=?ISO-8859-1?Q?Martin_M=F8ller_Pedersen?=) Date: Wed, 7 Feb 2007 17:14:22 +0100 Subject: [Nagiosplug-devel] wctype.h error-report Message-ID: Hi, I am trying to compile nagios-plugins on my AIX box using gcc and the configure-script ask me to send a report to nagios-plugins list. Regards Martin # uname -Mprs AIX 2 powerpc IBM,7026-6H1 # gcc --version gcc (GCC) 4.0.0 I tried with both plugin version 1.4.5 and version 1.4.6 checking wchar.h usability... no checking wchar.h presence... yes configure: WARNING: wchar.h: present but cannot be compiled configure: WARNING: wchar.h: check for missing prerequisite headers? configure: WARNING: wchar.h: see the Autoconf documentation configure: WARNING: wchar.h: section "Present But Cannot Be Compiled" configure: WARNING: wchar.h: proceeding with the preprocessor's result configure: WARNING: wchar.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------------- ## configure: WARNING: ## Report this to the nagios-plugins lists. ## configure: WARNING: ## ----------------------------------------- ## checking for wchar.h... yes checking wctype.h usability... no checking wctype.h presence... yes configure: WARNING: wctype.h: present but cannot be compiled configure: WARNING: wctype.h: check for missing prerequisite headers? configure: WARNING: wctype.h: see the Autoconf documentation configure: WARNING: wctype.h: section "Present But Cannot Be Compiled" configure: WARNING: wctype.h: proceeding with the preprocessor's result configure: WARNING: wctype.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------------- ## configure: WARNING: ## Report this to the nagios-plugins lists. ## configure: WARNING: ## ----------------------------------------- ## checking for wctype.h... yes From noreply at sourceforge.net Wed Feb 7 19:14:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 10:14:51 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1654430 ] unsubstituted macro in po/Makefile Message-ID: Bugs item #1654430, was opened at 2007-02-07 19:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1654430&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: unsubstituted macro in po/Makefile Initial Comment: After running configure, @MKINSTALLDIRS@ is not substituted in po/Makefile thus 'make install' will fail in po/. This is with 1.4.6 on OpenBSD 4.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1654430&group_id=29880 From noreply at sourceforge.net Wed Feb 7 19:16:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Feb 2007 10:16:15 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1654430 ] unsubstituted macro in po/Makefile Message-ID: Bugs item #1654430, was opened at 2007-02-07 19:14 Message generated for change (Comment added) made by nsturm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1654430&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: nsturm (nsturm) Assigned to: Nobody/Anonymous (nobody) Summary: unsubstituted macro in po/Makefile Initial Comment: After running configure, @MKINSTALLDIRS@ is not substituted in po/Makefile thus 'make install' will fail in po/. This is with 1.4.6 on OpenBSD 4.0. ---------------------------------------------------------------------- >Comment By: nsturm (nsturm) Date: 2007-02-07 19:16 Message: Logged In: YES user_id=1323236 Originator: YES dup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1654430&group_id=29880 From seanius at seanius.net Wed Feb 7 19:44:55 2007 From: seanius at seanius.net (sean finney) Date: Wed, 07 Feb 2007 19:44:55 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <1170256799.5612.23.camel@localhost> <8B367280-1E95-4F56-A321-77B2A58F80C6@altinity.com> <1170686952.6749.45.camel@localhost> <3D0647BE-DE1E-44BC-BBEF-C82CA4A573FA@altinity.com> <1170791456.24813.11.camel@localhost> Message-ID: <1170873895.25062.19.camel@localhost> hey ton, On Wed, 2007-02-07 at 14:47 +0000, Ton Voon wrote: > - the section name cannot contain "@". I think this is fair > enough, so will add into RFC either that or we need to define how to properly escape such characters. similarly for quotes and leading/trailing spaces. > - Config::Tiny removes leading and trailing whitespace in the > stanza name for legibility reasons - good idea? I've got some tests > for those, but they are segfaulting oh, in the [foo] label? i don't see why we shouldn't support that. and in any case, segfaulting is bad, m'kay. especially since this could potentially be used by a setuid program :) > - Config::Tiny allows parameter/values before any stanzas. We have > reserved the stanza name "default" in the RFC - is it better to just > have that first part as reserved? i could go either way on that. shouldn't be too hard to implement anyway. > - your routine allows comments after a parameter/value, but > Config::Tiny doesn't. Should we recommend not using this or patch > Config::Tiny? i guess this was just because i was looking at a different ini implementation when i did that part. i'm fairly ambivalent about it, since removing the support would mean less code :) anyway, i'll go take a look at those tests and see if i can fix the segfaulting. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From gavin at openfusion.com.au Thu Feb 8 00:21:58 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 8 Feb 2007 10:21:58 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <20070207232158.GA21297@openfusion.com.au> Hi Ton et al, I've made a start on implementing this within Nagios::Plugin. Should have first-pass code in CVS today. A few questions as I work through the RFC: On Wed, Jan 31, 2007 at 12:50:02PM +0000, Ton Voon wrote: > PROPOSED SOLUTION > > The --default-opts parameter will take a value in the format: > > --default-opts=[stanza_name][@config_filename] > > If stanza_name is missed out, will assume stanza_name = plugin name. > > If @config_filename is missed out, will search for the configuration > file in default locations. And the default configuration file name is .... plugins.cfg? > IMPLEMENTATION DETAILS > > The C routine is to be called np_getopt_long and has the same > interface as getopt_long (from gnulib). > > The perl routine in Nagios::Plugin will not require any changes at > the plugin level. > > Both the C and the perl routines do not require specification of -- > default-opts to process that option - it is implicitly checked and > processed. Ok. Three things: - for packages, we probably want to make sure we ship with an empty (or all commented out) config file, because otherwise I imagine we'll get some very confused people wondering where these 'magic' extra options come from - does a --default-opts=foobar override this implicit check? i.e. we don't check --default-opts=plugin_name if --defauult-opts=foobar is set? - how do we turn this off? e.g. if I've got some default options defined for a random plugin in the [plugin_name] stanza, how do I do a special invocation _without_ those options? I can't do --default-opts=bogus, because that's an error. Do we need a --no-default-opts? > When processing options, there needs to be a first pass to extract > all the --default-opts options and process the config files. > Duplicate config options are removed, last one wins. Any options on > command line will remove the default. > > Duplicates removal would include equivalent short and long options. > For instance, a default config file of username=manager with a -u > admin on command line would produce the equivalent of -u admin. I'm not sure about this duplicate removal stuff, on two fronts: 1. I think duplicate arguments might be useful sometimes. e.g. how about a plugin that takes a --path argument, indicating places to search for some file. Allowing multiple paths do be defined additively (some default, some test-specific) seems very nice behaviour. 2. It significantly complicates the processing, and it requires that the we _understand_ the arguments (especially the shortname/longname equivalence). I think it's cleaner if the default-opts handler can just be dumb, load all the arguments from the config files, and dump them on the front of the argv list to be processed. It's then handled by the conventional argument processing as defined by the plugin, rather than removed by fiat. i.e. if your plugin says multiple usernames are okay, you get them all; if it says username is single, the argument processing only gives you the last one. Is that sufficient/acceptable? > The order of the options is not guaranteed - defaults maybe added at > beginning or the end of processing. If you want to use options that > could be positional dependant (such as check_disk's -p), it is > recommended to avoid --default-opts. Again, I'm arguing for a simpler approach here. I'd like to just say something like: Groups of default options are prepended to the argument list in the order in which they are defined i.e. using '--default-opts=A --default-opts=B' will cause all options in A to occur first, then all options in B, and then all other options. The order of options _within_ a config file stanza is not defined, and should not be relied upon. > If default-opts is not found, return state unknown with appropriate > message. I think you mean 'config file' rather than 'default-opts' here. Cheers, Gavin From gavin at openfusion.com.au Thu Feb 8 05:59:19 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 8 Feb 2007 15:59:19 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> Message-ID: <20070208045919.GB23363@openfusion.com.au> A couple more clarifications/corrections to the RFC: On Wed, Jan 31, 2007 at 12:50:02PM +0000, Ton Voon wrote: > If default-opts is not found, return state unknown with appropriate > message. > > If stanza is not found, return state unknown with appropriate message. Presumably this applies iff there is an explicit --default-opts specified? i.e. --default-opts=section or --defaults-opts= Otherwise you might get one or two complaints from users when all their plugins stop working. :-) > EXAMPLES > > An invocation of: > > ./check_disk --default-opts=funny_stuff -p=/home -p=/users > > is effectively: > > ./check_disk --username "Ton Voon" -p "" --expect=" space in front" > > (-p has a value associated, but null. Space retained in username. > Space in front retained in expect) > The invocation here should be: ./check_disk --default-opts=funny_stuff right? > An invocation of: > > ./check_disk --default-opts=@/non/existant/file > > returns UNKNOWN, with error message > > > An invocation of: > > ./check_disk --default-opts=unknown-stanza > > returns UNKNOWN, with error message So we should probably add at least (assuming I'm correct above): An invocation of: ./check_no_section --default-opts= returns UNKNOWN, with error message An invocation of: ./check_no_section -H localhost where no plugin section exists does NOT return UNKNOWN, and is not expanded at all. Cheers, Gavin From dermoth at aei.ca Thu Feb 8 06:10:50 2007 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 08 Feb 2007 00:10:50 -0500 Subject: [Nagiosplug-devel] doc/makefile Message-ID: <45CAB0DA.2050402@aei.ca> Looking at an error message, I realized that in doc/makefile there's some shell code that seems useless... It's: if [[ -e developer-guidelines/developer-guidelines.html ]] ; then \ mv developer-guidelines/developer-guidelines.html . ;\ rm -f developer-guidelines ;\ fi [[ is BASH syntax. Since it's getting run by /bin/sh, and on my system (latest Ubuntu) /bin/sh is the BSD SHell, [[ return an error. I don't see any reason to use [[ instead of [. The other weird thing there is the: rm -f developer-guidelines Since developer-guidelines is supposed to be a directory it doesn't remove it and print an error instead. I'm not sure if other UNIX implementations of rm would remove it, but since /bin/sh needs to be GNU BASH it would be odd that the rest even runs on a non-GNU system :/ Should I fix that code or remove it? On my system it's creating the html file in the same directory; I'm wondering if it's different on other systems... Thomas From gavin at openfusion.com.au Thu Feb 8 06:34:50 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Thu, 8 Feb 2007 16:34:50 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070207232158.GA21297@openfusion.com.au> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> Message-ID: <20070208053449.GC23363@openfusion.com.au> On Thu, Feb 08, 2007 at 10:21:58AM +1100, Gavin Carr wrote: > I've made a start on implementing this within Nagios::Plugin. Should > have first-pass code in CVS today. In CVS now. This is my dumb version rather than Ton's slightly-smarter duplicate-removing version though - I figured I'd wait to have that confirmed before doing the extra. I've also implemented Ton's test suite, and all tests pass except for the 2 where the dumb/dup-removing distinction makes a difference. No stdin or environment variable foo yet either. Cheers, Gavin From seanius at seanius.net Thu Feb 8 08:43:33 2007 From: seanius at seanius.net (sean finney) Date: Thu, 08 Feb 2007 08:43:33 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070207232158.GA21297@openfusion.com.au> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> Message-ID: <1170920613.5213.3.camel@localhost> hi gavin, On Thu, 2007-02-08 at 10:21 +1100, Gavin Carr wrote: > > If @config_filename is missed out, will search for the configuration > > file in default locations. > > And the default configuration file name is .... > > plugins.cfg? i would suggest using a different file suffix than cfg, to (a) make it clear to nagios users that it's a different file format and (b) prevent nagios from attempting to read it if the file happens to be laying in a directory that's one of nagios cfg_dir entries. as for the location, i'd suggest ${config_prefix}/nagios-plugins/plugins.ini, but it's not something i feel horrible about (as long as it's an absolute pathname and easy to change) sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ton.voon at altinity.com Thu Feb 8 09:07:14 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 8 Feb 2007 08:07:14 +0000 Subject: [Nagiosplug-devel] doc/makefile In-Reply-To: <45CAB0DA.2050402@aei.ca> References: <45CAB0DA.2050402@aei.ca> Message-ID: <1ED45D28-D241-42EC-8907-B5CA2F07F2F0@altinity.com> Hi Thomas, On 8 Feb 2007, at 05:10, Thomas Guyot-Sionnest wrote: > Looking at an error message, I realized that in doc/makefile there's > some shell code that seems useless... It's: > > if [[ -e developer-guidelines/developer-guidelines.html ]] ; then \ > mv developer-guidelines/developer-guidelines.html . ;\ > rm -f developer-guidelines ;\ > fi > I think I put this in. The reason is that the docbook generation sometimes (*) creates lots of sections under developer-guidelines/, rather than putting the *.html in the current directory. This is just to move it up a level. * IIRC, this is on the sourceforge server where I have a script to checkout the latest CVS code and run docbook before publishing on http://nagiosplug.sourceforge.net/developer-guidelines.html. The better fix is to tell docbook not to do that, but I couldn't work out how. > [[ is BASH syntax. Since it's getting run by /bin/sh, and on my system > (latest Ubuntu) /bin/sh is the BSD SHell, [[ return an error. I don't > see any reason to use [[ instead of [. The other weird thing there > is the: > > rm -f developer-guidelines > > Since developer-guidelines is supposed to be a directory it doesn't > remove it and print an error instead. I'm not sure if other UNIX > implementations of rm would remove it, but since /bin/sh needs to > be GNU > BASH it would be odd that the rest even runs on a non-GNU system :/ > > Should I fix that code or remove it? On my system it's creating the > html > file in the same directory; I'm wondering if it's different on other > systems... Shell compatible [ is fine. Yes, fixing the rm would be good too. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From njharman at knoggin.com Thu Feb 8 08:32:31 2007 From: njharman at knoggin.com (Norman J Harman Jr.) Date: Wed, 07 Feb 2007 23:32:31 -0800 Subject: [Nagiosplug-devel] bug? in perl Plugin::Range.pm Message-ID: <45CAD20F.8060900@knoggin.com> $VERSION = "0.15"; I'm fairly certain that the first if/else in check_range should be swapped. Correct code: sub check_range { ... if ($self->end_infinity == 0 && $self->start_infinity == 0) { if ($self->start <= $value && $value <= $self->end) { return $true; } else { return $false; ... From ton.voon at altinity.com Thu Feb 8 10:20:36 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 8 Feb 2007 09:20:36 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070207232158.GA21297@openfusion.com.au> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> Message-ID: Hi all, On 7 Feb 2007, at 23:21, Gavin Carr wrote: > And the default configuration file name is .... > > plugins.cfg? I agree with Sean that the suffix should be .ini to distinguish from Nagios type files. I'm not too fussed about location. ${config-prefix}/nagios-plugins/ plugins.ini sounds as good as any. >> IMPLEMENTATION DETAILS >> >> The C routine is to be called np_getopt_long and has the same >> interface as getopt_long (from gnulib). >> >> The perl routine in Nagios::Plugin will not require any changes at >> the plugin level. >> >> Both the C and the perl routines do not require specification of -- >> default-opts to process that option - it is implicitly checked and >> processed. > > Ok. Three things: > > - for packages, we probably want to make sure we ship with an empty > (or all commented out) config file, because otherwise I imagine > we'll > get some very confused people wondering where these 'magic' extra > options come from Agreed. A commented out initial config file with some sensible examples is a good idea. > - does a --default-opts=foobar override this implicit check? i.e. > we don't check --default-opts=plugin_name if --defauult-opts=foobar > is set? Sorry, this is my bad wording in the RFC. The idea of the text is that a plugin developer does not have to define --default-opts using getopt_long or Nagios::Plugin::Getopts to have that option available - it should come for free, such as with --version and --help. I can see this being okay with Nagios::Plugin, but I'm not sure if it is best if the C implementation does it transparently (it is technically possible because if you are calling np_getopt_long, this routine could tack on the required information). Sean? You still need to explicitly say --default-opts= to kick the default options in. This provides backwards compatibility with current syntax. > - how do we turn this off? e.g. if I've got some default options > defined for a random plugin in the [plugin_name] stanza, how do I > do a special invocation _without_ those options? I can't do > --default-opts=bogus, because that's an error. Do we need a > --no-default-opts? So, by the above, no --default-opts= on the command line will stay the same with current behaviour. >> When processing options, there needs to be a first pass to extract >> all the --default-opts options and process the config files. >> Duplicate config options are removed, last one wins. Any options on >> command line will remove the default. >> >> Duplicates removal would include equivalent short and long options. >> For instance, a default config file of username=manager with a -u >> admin on command line would produce the equivalent of -u admin. > > I'm not sure about this duplicate removal stuff, on two fronts: > > 1. I think duplicate arguments might be useful sometimes. e.g. how > about a plugin that takes a --path argument, indicating places > to search for some file. Allowing multiple paths do be defined > additively (some default, some test-specific) seems very nice > behaviour. > 2. It significantly complicates the processing, and it requires that > the we _understand_ the arguments (especially the shortname/ > longname > equivalence). I think it's cleaner if the default-opts handler can > just be dumb, load all the arguments from the config files, and > dump them on the front of the argv list to be processed. It's then > handled by the conventional argument processing as defined by the > plugin, rather than removed by fiat. i.e. if your plugin says > multiple usernames are okay, you get them all; if it says username > is single, the argument processing only gives you the last one. > Is that sufficient/acceptable? Firstly, Config::Tiny will not allow duplicate options. I guess we can overcome this with a different module, or we write our own. Secondly, this is the difference between my initial "replacement options" (1) idea versus the current "overrideable options" (2). I think you're advocating a variation of "replacement options", which is "replacement options, default-opts moved to front" (3). Consider this: [check_disk] path=/var path=/home units=GB ./check_disk --warning=10% --critical=5% --default-opts= --path=/usr (1) would give: ./check_disk --warning=10% --critical=5% --path=/ var --path=/home --units=GB --path=/usr (2) would give: ./check_disk --warning=10% --critical=5% --path=/ usr --units=GB (order not necessarily preserved) (3) would give: ./check_disk --path=/var --path=/home --units=GB -- warning=10% --critical=5% --path=/usr (order not necessarily preserved) With (2) where there is extra processing to remove options, I don't think there is a way of retaining order information. Obviously, you cannot preserve duplications. With (3), duplications can be retained, but order is not currently. This could be done with a different ini parsing routine that pulls out duplicates and order. Another, more likely, example: [check_snmp] username=root password=secret ./check_mysql --username=fred --default-opts= --warning=10 --critical=20 (1) would give: ./check_mysql --username=fred --username=root -- password=secret --warning=10 --critical=20 (2) would give: ./check_mysql --username=fred --password=secret -- warning=10 --critical=20 (order not necessarily preserved) (3) would give: ./check_mysql --username=root --password=secret -- username=fred --warning=10 --critical=20 (order not necessarily preserved) Note, (1) and (3) will cause different behaviour in the plugin. Gavin, I personally agree with you that we should retain duplicates and pass responsibility over to the plugins. However, I also think we should retain order (an additional rule of moving default-opts to front is fine). In the end, I don't mind which one we do. The initial use is for secure username/passwords, which would work in any of the implementations. But we do have to agree and make it consistent. I thought the consensus was to do (2). However, I think it is fair to revisit a design if there are implementation difficulties, so I'd like any other views on this. > >> If default-opts is not found, return state unknown with appropriate >> message. > > I think you mean 'config file' rather than 'default-opts' here. Yes. Thanks. I haven't updated the dev guidelines yet and I'll hold back due to this. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Thu Feb 8 10:27:43 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 8 Feb 2007 09:27:43 +0000 Subject: [Nagiosplug-devel] bug? in perl Plugin::Range.pm In-Reply-To: <45CAD20F.8060900@knoggin.com> References: <45CAD20F.8060900@knoggin.com> Message-ID: On 8 Feb 2007, at 07:32, Norman J Harman Jr. wrote: > $VERSION = "0.15"; > > I'm fairly certain that the first if/else in check_range should be > swapped. > > Correct code: > > sub check_range { > ... > if ($self->end_infinity == 0 && $self->start_infinity == 0) { > if ($self->start <= $value && $value <= $self->end) { > return $true; > } else { > return $false; > ... > Hi Norman, Good news: the code is right. Bad news: the design is wrong. According to the developer guidelines (http:// nagiosplug.sourceforge.net/developer-guidelines.html), a range of 5:10 will alert on 12, but not 7. This goes against "conventional" thinking, where you would expect a range to alert inside. Nagios::Plugin has been coded in accordance with the design. There is a discussion re: new style range setting, to try and fix this, but the thread has stalled (http://thread.gmane.org/ gmane.network.nagios.plugins.devel/4461). I plan on tackling this when the other RFC re: plugins config files is completed. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From seanius at seanius.net Thu Feb 8 10:44:18 2007 From: seanius at seanius.net (sean finney) Date: Thu, 08 Feb 2007 10:44:18 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> Message-ID: <1170927858.14170.17.camel@localhost> On Thu, 2007-02-08 at 09:20 +0000, Ton Voon wrote: > > Ok. Three things: > > > > - for packages, we probably want to make sure we ship with an empty > > (or all commented out) config file, because otherwise I imagine > > we'll > > get some very confused people wondering where these 'magic' extra > > options come from > > Agreed. A commented out initial config file with some sensible > examples is a good idea. +1. > > - does a --default-opts=foobar override this implicit check? i.e. > > we don't check --default-opts=plugin_name if --defauult-opts=foobar > > is set? > > Sorry, this is my bad wording in the RFC. The idea of the text is > that a plugin developer does not have to define --default-opts using > getopt_long or Nagios::Plugin::Getopts to have that option available > - it should come for free, such as with --version and --help. this will make a requirement on the c programs that progname is accessible as an extern char *, just fyi. when i implemented the ini routines i wasn't sure if that was acceptable so i coded around it (the default section name is passed allong with the --default-opts option value). > I can see this being okay with Nagios::Plugin, but I'm not sure if it > is best if the C implementation does it transparently (it is > technically possible because if you are calling np_getopt_long, this > routine could tack on the required information). Sean? see above. if it's acceptable then i see no reason not to do all the processing "for free" as part of np_getopt_long. > You still need to explicitly say --default-opts= to kick the default > options in. This provides backwards compatibility with current syntax. when i wrote the routines i assumed the opposite: that the defaults would be read by, well, default :). so in the current parse_ini code you would disable default option reading by specifying an empty string for the defaults location. personally i'm more in favor of this because "defaults should on by default". if we're shipping a blank/commented ini file, it won't cause that much confusion. oh, btw a minor detail: we should make sure that "make install" doesn't override the default file if it already exists. but in any event i'll acquiesce to the majority opinion if you guys disagree. however in that case i'd suggest "--default-opts" without the "=" (making it an optional argument). sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ton.voon at altinity.com Thu Feb 8 16:30:47 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 8 Feb 2007 15:30:47 +0000 Subject: [Nagiosplug-devel] Nagios::Plugin suggestions Message-ID: <3067C011-D884-4483-9AB8-A1BBE986928F@altinity.com> Hi! I've just started using Nagios::Plugin in earnest because I am going to do a public demo of this soon (hush, hush details, but I will let you all know soon :) ). I had a couple of suggestions. Firstly, good job Gavin and Nathan! I can see the framework is coming along nicely and is amazing how little needs to be coded to get a lot of support for extraneous stuff. ADD_ARG METHOD For $np->add_arg(), one thing I've noticed myself repeating is the help output. The syntax output is effectively already defined in the spec. Plus, to get the output lined up correctly with the default args in --help, you need to add a linefeed and extra spaces. What about: $np->add_arg( spec => "warning|w=s", type => "RANGE", help => "Warning if time is outside RANGE", ); The idea is that the spec line will print "-w, --warning=RANGE", with a new line and the appropriate number of spaces before printing $help. This should also make it a bit easier to internationalisation as the help line is the only portion that needs translating. I'm also thinking ahead to new threshold formats, so that if type is THRESHOLD, some other processing can happen (validation of threshold values?). We can be backwards compatible so that the old behaviour happens if type is not specified (though mark this as deprecated behaviour). Also, I'd like to add default => "5" to the add_arg, if you wish to set a default value. HELP OUTPUT Currently this is sent to stderr. This should be stdout with respects to the C plugins, though I can't find it documented in the dev guidelines. Agreed? MAX_STATE I've added a max_state function into N::P::Functions that mimics the C version, but not sure how to add into the N::P object. It seems that the object itself doesn't have the idea of a current state - would that be a good idea or not? If the object does know state, then $np->max_state( $new_state ) could do a $self->state( new_state ( $self->state || "", $new_state) ) ? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From gavin at openfusion.com.au Thu Feb 8 23:25:27 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 9 Feb 2007 09:25:27 +1100 Subject: [Nagiosplug-devel] Nagios::Plugin suggestions In-Reply-To: <3067C011-D884-4483-9AB8-A1BBE986928F@altinity.com> References: <3067C011-D884-4483-9AB8-A1BBE986928F@altinity.com> Message-ID: <20070208222527.GA29260@openfusion.com.au> Hi Ton, On Thu, Feb 08, 2007 at 03:30:47PM +0000, Ton Voon wrote: > ADD_ARG METHOD > > For $np->add_arg(), one thing I've noticed myself repeating is the > help output. The syntax output is effectively already defined in the > spec. Plus, to get the output lined up correctly with the default > args in --help, you need to add a linefeed and extra spaces. What about: > > $np->add_arg( > spec => "warning|w=s", > type => "RANGE", > help => "Warning if time is outside RANGE", > ); > > The idea is that the spec line will print "-w, --warning=RANGE", with > a new line and the appropriate number of spaces before printing $help. > > This should also make it a bit easier to internationalisation as the > help line is the only portion that needs translating. That's a good suggestion; in fact, I wonder whether it's worth doing even if 'type' isn't specified e.g. spec => 'timeout|t=i' could still automagically prepend '-t, --timeout=INTEGER\n ' in much the same way, and 'query|q=s' could become '-q, --query=STRING\n '. We can handle backward compatibility simply be checking whether the help begins with -X or --LONG, and not munging it if so. That work? Type would then be purely optional, but replaces the default INTEGER/STRING label if specified? Next question: can types be arbitrary, or only pre-defined? If they're primarily labels, perhaps they can be arbitrary e.g. query, type => 'SQL'; pattern, type => 'REGEX'; username, type => 'USERNAME'. If we're adding behaviors to them, though (RANGE, THRESHOLD, etc.), then they should perhaps be restricted. Hmmm. > I'm also thinking ahead to new threshold formats, so that if type is > THRESHOLD, some other processing can happen (validation of threshold > values?). > > We can be backwards compatible so that the old behaviour happens if > type is not specified (though mark this as deprecated behaviour). > > Also, I'd like to add default => "5" to the add_arg, if you wish to > set a default value. Already there. :-) Although this may well be a documentation bug. The Nagios::Plugin::Getopt docs should be reasonably comprehensive, but the Nagios::Plugin ones may not include stuff they should. There's also a 'required => 1' option for mandatory args. > HELP OUTPUT > > Currently this is sent to stderr. This should be stdout with respects > to the C plugins, though I can't find it documented in the dev > guidelines. Agreed? Happy either way. > MAX_STATE > > I've added a max_state function into N::P::Functions that mimics the > C version, but not sure how to add into the N::P object. It seems > that the object itself doesn't have the idea of a current state - > would that be a good idea or not? If the object does know state, then > $np->max_state( $new_state ) could do a $self->state( new_state > ( $self->state || "", $new_state) ) ? No, N::P is stateless at the moment. I take it you're thinking of being able to do a few check_thresholds, for instance, and then dying if the max_state so far is critical or warning or something? You might also want to look at the add_message / check_message interface too, which is the closest thing to statefulness right now. Cheers, Gavin -- Gavin Carr - http://www.openfusion.com.au - Linux, Perl, and Web Consulting - http://www.xool.com.au - Xool, Australian property search engine * Fashion is a variable, but style is a constant - Programming Perl From gavin at openfusion.com.au Fri Feb 9 00:09:04 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 9 Feb 2007 10:09:04 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> Message-ID: <20070208230904.GB29260@openfusion.com.au> On Thu, Feb 08, 2007 at 09:20:36AM +0000, Ton Voon wrote: > On 7 Feb 2007, at 23:21, Gavin Carr wrote: > > > And the default configuration file name is .... > > > > plugins.cfg? > > I agree with Sean that the suffix should be .ini to distinguish from > Nagios type files. Okay, sounds reasonable. > I'm not too fussed about location. ${config-prefix}/nagios-plugins/ > plugins.ini sounds as good as any. What are some typical ${config-prefix}-es? i.e. what would a full-path look like? And as an aside, how do I source ${config-prefix} on the perl side? > >> IMPLEMENTATION DETAILS > >> > >> The C routine is to be called np_getopt_long and has the same > >> interface as getopt_long (from gnulib). > >> > >> The perl routine in Nagios::Plugin will not require any changes at > >> the plugin level. > >> > >> Both the C and the perl routines do not require specification of -- > >> default-opts to process that option - it is implicitly checked and > >> processed. > > > > Ok. Three things: > > > > - for packages, we probably want to make sure we ship with an empty > > (or all commented out) config file, because otherwise I imagine > > we'll > > get some very confused people wondering where these 'magic' extra > > options come from > > Agreed. A commented out initial config file with some sensible > examples is a good idea. > > > - does a --default-opts=foobar override this implicit check? i.e. > > we don't check --default-opts=plugin_name if --defauult-opts=foobar > > is set? > > Sorry, this is my bad wording in the RFC. The idea of the text is > that a plugin developer does not have to define --default-opts using > getopt_long or Nagios::Plugin::Getopts to have that option available > - it should come for free, such as with --version and --help. > > I can see this being okay with Nagios::Plugin, but I'm not sure if it > is best if the C implementation does it transparently (it is > technically possible because if you are calling np_getopt_long, this > routine could tack on the required information). Sean? > > You still need to explicitly say --default-opts= to kick the default > options in. This provides backwards compatibility with current syntax. Ah, ok. I read it like Sean, and have coded things so far to always load the defaults if a [plugin] section exists. I think with Sean I slightly prefer that reading, but it does mean you need a way of turning that off. I don't much mind though - which way do you want to go? > >> When processing options, there needs to be a first pass to extract > >> all the --default-opts options and process the config files. > >> Duplicate config options are removed, last one wins. Any options on > >> command line will remove the default. > >> > >> Duplicates removal would include equivalent short and long options. > >> For instance, a default config file of username=manager with a -u > >> admin on command line would produce the equivalent of -u admin. > > > > I'm not sure about this duplicate removal stuff, on two fronts: > > > > 1. I think duplicate arguments might be useful sometimes. e.g. how > > about a plugin that takes a --path argument, indicating places > > to search for some file. Allowing multiple paths do be defined > > additively (some default, some test-specific) seems very nice > > behaviour. > > > 2. It significantly complicates the processing, and it requires that > > the we _understand_ the arguments (especially the shortname/ > > longname > > equivalence). I think it's cleaner if the default-opts handler can > > just be dumb, load all the arguments from the config files, and > > dump them on the front of the argv list to be processed. It's then > > handled by the conventional argument processing as defined by the > > plugin, rather than removed by fiat. i.e. if your plugin says > > multiple usernames are okay, you get them all; if it says username > > is single, the argument processing only gives you the last one. > > Is that sufficient/acceptable? > > Firstly, Config::Tiny will not allow duplicate options. I guess we > can overcome this with a different module, or we write our own. > > Secondly, this is the difference between my initial "replacement > options" (1) idea versus the current "overrideable options" (2). > > I think you're advocating a variation of "replacement options", which > is "replacement options, default-opts moved to front" (3). I'm certainly advocating 'move-to-front' - that was the main thing I didn't like with your (1). > Consider this: > > [check_disk] > path=/var > path=/home > units=GB > > ./check_disk --warning=10% --critical=5% --default-opts= --path=/usr > > (1) would give: ./check_disk --warning=10% --critical=5% --path=/ > var --path=/home --units=GB --path=/usr > (2) would give: ./check_disk --warning=10% --critical=5% --path=/ > usr --units=GB (order not necessarily preserved) > (3) would give: ./check_disk --path=/var --path=/home --units=GB -- > warning=10% --critical=5% --path=/usr (order not necessarily preserved) > > With (2) where there is extra processing to remove options, I don't > think there is a way of retaining order information. Obviously, you > cannot preserve duplications. > > With (3), duplications can be retained, but order is not currently. > This could be done with a different ini parsing routine that pulls > out duplicates and order. Yes, I like (3). > Another, more likely, example: > > [check_snmp] > username=root > password=secret > > ./check_mysql --username=fred --default-opts= --warning=10 --critical=20 > > (1) would give: ./check_mysql --username=fred --username=root -- > password=secret --warning=10 --critical=20 > (2) would give: ./check_mysql --username=fred --password=secret -- > warning=10 --critical=20 (order not necessarily preserved) > (3) would give: ./check_mysql --username=root --password=secret -- > username=fred --warning=10 --critical=20 (order not necessarily > preserved) > > Note, (1) and (3) will cause different behaviour in the plugin. > > Gavin, I personally agree with you that we should retain duplicates > and pass responsibility over to the plugins. However, I also think we > should retain order (an additional rule of moving default-opts to > front is fine). Yes, I agree with you. I'm fine with order preservation, as long as we do move-defaults-to-front first. So +1 from me for (3) + order preservation. > In the end, I don't mind which one we do. The initial use is for > secure username/passwords, which would work in any of the > implementations. But we do have to agree and make it consistent. I > thought the consensus was to do (2). > > However, I think it is fair to revisit a design if there are > implementation difficulties, so I'd like any other views on this. Other opinions? Cheers, Gavin From gavin at openfusion.com.au Fri Feb 9 00:21:50 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 9 Feb 2007 10:21:50 +1100 Subject: [Nagiosplug-devel] bug? in perl Plugin::Range.pm In-Reply-To: References: <45CAD20F.8060900@knoggin.com> Message-ID: <20070208232150.GC29260@openfusion.com.au> On Thu, Feb 08, 2007 at 09:27:43AM +0000, Ton Voon wrote: > > On 8 Feb 2007, at 07:32, Norman J Harman Jr. wrote: > > > $VERSION = "0.15"; > > > > I'm fairly certain that the first if/else in check_range should be > > swapped. > > > > Correct code: > > > > sub check_range { > > ... > > if ($self->end_infinity == 0 && $self->start_infinity == 0) { > > if ($self->start <= $value && $value <= $self->end) { > > return $true; > > } else { > > return $false; > > ... > > > > Good news: the code is right. Bad news: the design is wrong. > > According to the developer guidelines (http:// > nagiosplug.sourceforge.net/developer-guidelines.html), a range of > 5:10 will alert on 12, but not 7. This goes against "conventional" > thinking, where you would expect a range to alert inside. > Nagios::Plugin has been coded in accordance with the design. Blech - this is so broken, isn't it? > There is a discussion re: new style range setting, to try and fix > this, but the thread has stalled (http://thread.gmane.org/ > gmane.network.nagios.plugins.devel/4461). I plan on tackling this > when the other RFC re: plugins config files is completed. How are you thinking of doing this on the backend Ton? Do we want a flag on N::P::Range to designate whether a range is inclusive or exclusive, and support in N::P::Threshold for that? That might allow plugins to explicitly designate which way they want their ranges to be interpreted. I've got current plugins in the wild with inclusive ranges that I can't migrate to N::P::Range because of this. Cheers, Gavin From seanius at seanius.net Fri Feb 9 01:10:53 2007 From: seanius at seanius.net (sean finney) Date: Fri, 09 Feb 2007 01:10:53 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070208230904.GB29260@openfusion.com.au> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <20070208230904.GB29260@openfusion.com.au> Message-ID: <1170979853.5996.7.camel@localhost> hey gavin, On Fri, 2007-02-09 at 10:09 +1100, Gavin Carr wrote: > > I'm not too fussed about location. ${config-prefix}/nagios-plugins/ > > plugins.ini sounds as good as any. > > What are some typical ${config-prefix}-es? i.e. what would a full-path > look like? $config_prefix is autoconf-speak for $prefix/etc. for prepackaged distros that'd probably be straight /etc, and for those who do configure --prefix=/usr/local it'd be /usr/local/etc. > And as an aside, how do I source ${config-prefix} on the perl side? it would be built-in at build time. if you were building from the nagios tarball you could just use autofoo substitutions, but if it's being done outside i'd probably just deafult to whatever the ./configure script would default to (one of the two directories i mentioned above, i forget which). and of course provide a way to override it at build time as well. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From gavin at openfusion.com.au Fri Feb 9 01:28:07 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Fri, 9 Feb 2007 11:28:07 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170979853.5996.7.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <20070208230904.GB29260@openfusion.com.au> <1170979853.5996.7.camel@localhost> Message-ID: <20070209002807.GD29260@openfusion.com.au> Hey Sean, On Fri, Feb 09, 2007 at 01:10:53AM +0100, sean finney wrote: > On Fri, 2007-02-09 at 10:09 +1100, Gavin Carr wrote: > > > I'm not too fussed about location. ${config-prefix}/nagios-plugins/ > > > plugins.ini sounds as good as any. > > > > What are some typical ${config-prefix}-es? i.e. what would a full-path > > look like? > > $config_prefix is autoconf-speak for $prefix/etc. for prepackaged > distros that'd probably be straight /etc, and for those who do > configure --prefix=/usr/local it'd be /usr/local/etc. Ah okay, thanks. So you'd prefer a separate $config_prefix/nagios-plugins directory to re-using $config_prefix/nagios? I wonder if to users the two projects are so interlinked that two directories is confusing? I kind of prefer $config_prefix/nagios/plugins/plugins.ini, or even just $config_prefix/nagios/plugins.ini (perhaps anything starting with plugins* could be reserved?) ... > > And as an aside, how do I source ${config-prefix} on the perl side? > > it would be built-in at build time. if you were building from the > nagios tarball you could just use autofoo substitutions, but if it's > being done outside i'd probably just deafult to whatever the ./configure > script would default to (one of the two directories i mentioned > above, i forget which). and of course provide a way to override it > at build time as well. The issue with Nagios::Plugin is that it's distributed via CPAN as well as (?) via tarball/packages i.e. it won't necessarily be installed at regular 'build time'. So it probably needs to be a run-time thing for N::P - is $config-prefix available anywhere post-install at the moment? Cheers, Gavin From ton.voon at altinity.com Fri Feb 9 10:19:47 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 9 Feb 2007 09:19:47 +0000 Subject: [Nagiosplug-devel] Nagios::Plugin suggestions In-Reply-To: <20070208222527.GA29260@openfusion.com.au> References: <3067C011-D884-4483-9AB8-A1BBE986928F@altinity.com> <20070208222527.GA29260@openfusion.com.au> Message-ID: <02781CA0-546D-4A54-A3D3-95F3036F3BB0@altinity.com> Hi Gavin, On 8 Feb 2007, at 22:25, Gavin Carr wrote: > On Thu, Feb 08, 2007 at 03:30:47PM +0000, Ton Voon wrote: >> ADD_ARG METHOD >> >> For $np->add_arg(), one thing I've noticed myself repeating is the >> help output. The syntax output is effectively already defined in the >> spec. Plus, to get the output lined up correctly with the default >> args in --help, you need to add a linefeed and extra spaces. What >> about: >> >> $np->add_arg( >> spec => "warning|w=s", >> type => "RANGE", >> help => "Warning if time is outside RANGE", >> ); >> >> The idea is that the spec line will print "-w, --warning=RANGE", with >> a new line and the appropriate number of spaces before printing >> $help. >> >> This should also make it a bit easier to internationalisation as the >> help line is the only portion that needs translating. > > That's a good suggestion; in fact, I wonder whether it's worth doing > even if 'type' isn't specified e.g. spec => 'timeout|t=i' could still > automagically prepend '-t, --timeout=INTEGER\n ' in much the same > way, > and 'query|q=s' could become '-q, --query=STRING\n '. > > We can handle backward compatibility simply be checking whether the > help begins with -X or --LONG, and not munging it if so. That work? > > Type would then be purely optional, but replaces the default > INTEGER/STRING label if specified? Yes, that sounds fine. I'll have a go at that. > Next question: can types be arbitrary, or only pre-defined? If they're > primarily labels, perhaps they can be arbitrary e.g. query, type => > 'SQL'; > pattern, type => 'REGEX'; username, type => 'USERNAME'. If we're > adding > behaviors to them, though (RANGE, THRESHOLD, etc.), then they should > perhaps be restricted. Hmmm. What about type and label? Label is completely arbitrary. Type is a restricted list. Label defaults to type. We'll document only label for now, but idea is type = THRESHOLD or RANGE would trigger some validation. Future stuff :) >> I'm also thinking ahead to new threshold formats, so that if type is >> THRESHOLD, some other processing can happen (validation of threshold >> values?). >> >> We can be backwards compatible so that the old behaviour happens if >> type is not specified (though mark this as deprecated behaviour). >> >> Also, I'd like to add default => "5" to the add_arg, if you wish to >> set a default value. > > Already there. :-) Although this may well be a documentation bug. The > Nagios::Plugin::Getopt docs should be reasonably comprehensive, but > the Nagios::Plugin ones may not include stuff they should. There's > also > a 'required => 1' option for mandatory args. Sorry, should have checked. Was working only from the Nagios::Plugin documentation. I will make some clean ups there and add in the default option too. >> HELP OUTPUT >> >> Currently this is sent to stderr. This should be stdout with respects >> to the C plugins, though I can't find it documented in the dev >> guidelines. Agreed? > > Happy either way. OK, I'll make the change here and document in dev guidelines too. >> MAX_STATE >> >> I've added a max_state function into N::P::Functions that mimics the >> C version, but not sure how to add into the N::P object. It seems >> that the object itself doesn't have the idea of a current state - >> would that be a good idea or not? If the object does know state, then >> $np->max_state( $new_state ) could do a $self->state( new_state >> ( $self->state || "", $new_state) ) ? > > No, N::P is stateless at the moment. I take it you're thinking of > being > able to do a few check_thresholds, for instance, and then dying if the > max_state so far is critical or warning or something? > > You might also want to look at the add_message / check_message > interface > too, which is the closest thing to statefulness right now. OK. To be honest, I haven't got a need for the object holding state yet. I'll revisit when I get a more concrete example. I'll look into the add_message interface too. Ta Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Fri Feb 9 10:33:17 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 9 Feb 2007 09:33:17 +0000 Subject: [Nagiosplug-devel] bug? in perl Plugin::Range.pm In-Reply-To: <20070208232150.GC29260@openfusion.com.au> References: <45CAD20F.8060900@knoggin.com> <20070208232150.GC29260@openfusion.com.au> Message-ID: <7F834EAD-324E-4332-AAB5-701382A93234@altinity.com> On 8 Feb 2007, at 23:21, Gavin Carr wrote: > On Thu, Feb 08, 2007 at 09:27:43AM +0000, Ton Voon wrote: >> >> On 8 Feb 2007, at 07:32, Norman J Harman Jr. wrote: >> >>> $VERSION = "0.15"; >>> >>> I'm fairly certain that the first if/else in check_range should be >>> swapped. >>> >>> Correct code: >>> >>> sub check_range { >>> ... >>> if ($self->end_infinity == 0 && $self->start_infinity == 0) { >>> if ($self->start <= $value && $value <= $self->end) { >>> return $true; >>> } else { >>> return $false; >>> ... >>> >> >> Good news: the code is right. Bad news: the design is wrong. >> >> According to the developer guidelines (http:// >> nagiosplug.sourceforge.net/developer-guidelines.html), a range of >> 5:10 will alert on 12, but not 7. This goes against "conventional" >> thinking, where you would expect a range to alert inside. >> Nagios::Plugin has been coded in accordance with the design. > > Blech - this is so broken, isn't it? Yes. I can't even blame anyone about it as I helped set the design :( >> There is a discussion re: new style range setting, to try and fix >> this, but the thread has stalled (http://thread.gmane.org/ >> gmane.network.nagios.plugins.devel/4461). I plan on tackling this >> when the other RFC re: plugins config files is completed. > > How are you thinking of doing this on the backend Ton? Do we want a > flag on N::P::Range to designate whether a range is inclusive or > exclusive, and support in N::P::Threshold for that? > > That might allow plugins to explicitly designate which way they want > their ranges to be interpreted. I've got current plugins in the wild > with inclusive ranges that I can't migrate to N::P::Range because of > this. I'm thinking there should be some "hidden" functions that calculate ranges in the reverse order. This will need to be done in the C apis too, as we move to a new threshold specification, since we have to support the current syntax. Thinking about it, there's two levels of public APIs: current and deprecated. Feel free to add in one for calculating the ranges in the inverted order, but mark as deprecated (though we may use internally). Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri Feb 9 17:10:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Feb 2007 08:10:58 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1652625 ] po/Makefile broken Message-ID: Bugs item #1652625, was opened at 2007-02-05 19:20 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1652625&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: jspilon (jspilon) Assigned to: Nobody/Anonymous (nobody) Summary: po/Makefile broken Initial Comment: Version: 1.4.6 O/S: debian sarge 3.1 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.6/plugins-root' Making install in po make[1]: Entering directory `/tmp/nagios-plugins-1.4.6/po' /bin/sh @MKINSTALLDIRS@ /var/nagios/share @MKINSTALLDIRS@: @MKINSTALLDIRS@: No such file or directory make[1]: *** [install-data-yes] Error 127 make[1]: Leaving directory `/tmp/nagios-plugins-1.4.6/po' make: *** [install-recursive] Error 1 The problem appeared to be in po/Makefile I changed the following to get it working. 33c33 < MKINSTALLDIRS = ../mkinstalldirs --- > MKINSTALLDIRS = @MKINSTALLDIRS@ ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2007-02-09 17:10 Message: Logged In: YES user_id=759506 Originator: NO Yes, I've seen the same thing (on Debian Sarge). Ton has fixed this in CVS today. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1652625&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Sat Feb 10 23:05:30 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Sat, 10 Feb 2007 23:05:30 +0100 Subject: [Nagiosplug-devel] patches for new features of check_disk Message-ID: <45CE41AA.8000301@mailing.kaufland-informationssysteme.com> Hi list, I made a few patches fot check_disk that add some functionality we need. They apply cleanly to latest cvs and 1.4.6 if following order is kept: check_disk-clearfix.patch, check_disk-grouping.patch, check_disk-regex.patch. So here are the descriptions what they do.. Patch #1: To me the -C flag was not flexible enough. check_disk -w 10% -c 5% -p /tmp -p /var -C -w 100000 -c 50000 -p / from the examples is quite a nice feature but -p can't be omitted - so not all available partions are checked necessarily. The clearfix patch lets following work as supposed: check_disk -w 10% -c 5% -C -w 5% -c 3% -p /tmp Prior versions only select /tmp. Now all Partitions except /tmp got 10%/5%. Patch #1.1: Is a testcase for the clearfix patch. It hopefully increases the probability of an inclusion into cvs :) Patch #2: Larger (in our case Oracle) databases have multiple data partitions. That means that the disk status is fine if there are eg 10 data partitions and only two of them are full. check_disk couldn't handle this up to now. The patch adds a -g/--group=NAME option which enables partitions/pathes to be grouped so that the thresholds of a group apply to the freespace of all partitions together. ./check_disk -w 10% -c 5% -g mygroup -p /oracle/ETL/sapdata1/ -p /oracle/ETL/sapdata2/ DISK OK - free space: mygroup 22912 MB (29% inode=99%);| mygroup=53626MB;72570;76602;0;80634 Patch #3: The third patch adds regex functionality to check_disk. It makes that partitions/pathes can be specified using regular expressions (-r/-R). This makes check_disk meet all our demands in a flexible way leading to this example showing all patch features together: ./check_disk -w 10% -c 5% -C -w 10G -c 5G -g mygroup -r '^/oracle/ETL/sapdata.*' DISK OK - free space: / 751 MB (78% inode=87%);... mygroup 69068 MB (44% inode=99%); .. Regular expressions can also be used to specify thresholds for matching partitions/pathes without grouping. I'd be really glad to see the patches or at least the functionality they provide in cvs or one of the next releases. To me they are essential, if admins (like me) want to limit disk checks to one nagios service. Please send any kind of feedback to me. I'm interested, what people think about it. regards matthias -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_disk-regex.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_disk-clearfix.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_disk-grouping.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_disk.t-clearfix.patch URL: From noreply at sourceforge.net Sun Feb 11 13:49:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Feb 2007 04:49:08 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1657280 ] Fix option handling for check_http Message-ID: Patches item #1657280, was opened at 2007-02-11 21:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1657280&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: Fix option handling for check_http Initial Comment: check_http does not recognize some long options. I read the source file, and found longopts[] was * Missing: --port --authorization --expect, * Dup: --verbose, * Not-used: -F --file, and `-L' option takes no argument but help-message says that it takes one argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1657280&group_id=29880 From noreply at sourceforge.net Sun Feb 11 13:58:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Feb 2007 04:58:24 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1657280 ] Fix option handling for check_http Message-ID: Patches item #1657280, was opened at 2007-02-11 21:49 Message generated for change (Comment added) made by ban_nobuhiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1657280&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobuhiro Ban (ban_nobuhiro) Assigned to: Nobody/Anonymous (nobody) Summary: Fix option handling for check_http Initial Comment: check_http does not recognize some long options. I read the source file, and found longopts[] was * Missing: --port --authorization --expect, * Dup: --verbose, * Not-used: -F --file, and `-L' option takes no argument but help-message says that it takes one argument. ---------------------------------------------------------------------- >Comment By: Nobuhiro Ban (ban_nobuhiro) Date: 2007-02-11 21:58 Message: Logged In: YES user_id=1699577 Originator: YES File Added: check_http.c.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1657280&group_id=29880 From noreply at sourceforge.net Mon Feb 12 10:41:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Feb 2007 01:41:15 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1657828 ] check_sybase v1.0 Message-ID: Patches item #1657828, was opened at 2007-02-12 10:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1657828&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Bellwood (sb-netman) Assigned to: Nobody/Anonymous (nobody) Summary: check_sybase v1.0 Initial Comment: This release adds several new options: * Added initial performance data support. * Added support for NUMLOGINS checktype. * Added --fallback option. * Added --no-mixed-devices-warning to suppress new warning about mixed devices. * Added charset support. The download is available from: http://www.net-man.at/software/check_sybase-1.0.zip The latest version is always available from: http://www.net-man.at/software/check_sybase-LATEST.zip Will patch against 0.6 if needed. Simon Bellwood NetMan Network Management and IT Services GmbH ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1657828&group_id=29880 From ton.voon at altinity.com Thu Feb 15 14:47:02 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 15 Feb 2007 13:47:02 +0000 Subject: [Nagiosplug-devel] patches for new features of check_disk In-Reply-To: <45CE41AA.8000301@mailing.kaufland-informationssysteme.com> References: <45CE41AA.8000301@mailing.kaufland-informationssysteme.com> Message-ID: Hi Matthias, On 10 Feb 2007, at 22:05, Matthias Eble wrote: > I made a few patches fot check_disk that add some functionality we > need. > They apply cleanly to latest cvs and 1.4.6 if following order is > kept: check_disk-clearfix.patch, check_disk-grouping.patch, > check_disk-regex.patch. I've had a think about these patches and I think the functionality is great. I'd like some test cases for the grouping patch. It should be possible to take the two already defined mount points and get it to alert below and above a threshold which is for the group rather than per filesystem, proving the thresholds work at the group level. I found the patches a bit hard to apply because the email had all of them together. Can you send me 3 separate attachments please? It will take some time to work through these because there does seem to be quite a lot of changes, but in principle, I think this is a good move. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Thu Feb 15 15:34:04 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 15 Feb 2007 14:34:04 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1170927858.14170.17.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <1170927858.14170.17.camel@localhost> Message-ID: <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> Hi! Gavin wrote: >> Secondly, this is the difference between my initial "replacement >> options" (1) idea versus the current "overrideable options" (2). >> >> I think you're advocating a variation of "replacement options", which >> is "replacement options, default-opts moved to front" (3). >> > [snipped] > So +1 from me for (3) + order preservation. No objections in the last few days, so I think we're going with (3). I'll have to re-word the RFC (again) :( I'll adapt the test cases to reflect. On 8 Feb 2007, at 09:44, sean finney wrote: >> You still need to explicitly say --default-opts= to kick the default >> options in. This provides backwards compatibility with current >> syntax. > > when i wrote the routines i assumed the opposite: that the defaults > would be read by, well, default :). so in the current parse_ini code > you would disable default option reading by specifying an empty > string for the defaults location. personally i'm more in favor of > this because "defaults should on by default". > > if we're shipping a blank/commented ini file, it won't cause that > much confusion. oh, btw a minor detail: we should make sure that > "make > install" doesn't override the default file if it already exists. but > in any event i'll acquiesce to the majority opinion if you guys > disagree. however in that case i'd suggest "--default-opts" without > the "=" (making it an optional argument). If we're doing (3) instead of (2), can I suggest we change the name back to --extra-opts? I thought --default-opts was a better name for (2) because of the "remove duplicates" logic, but since we changing to (3), --extra-opts makes sense again. I'm thinking that this functionality is an advanced feature so reading of the config file should be done on demand, as opposed to every time. Agree with --extra-opts without the "=" to trigger using the config file. Gavin wrote: >>> And as an aside, how do I source ${config-prefix} on the perl side? >>> >> >> it would be built-in at build time. if you were building from the >> nagios tarball you could just use autofoo substitutions, but if it's >> being done outside i'd probably just deafult to whatever the ./ >> configure >> script would default to (one of the two directories i mentioned >> above, i forget which). and of course provide a way to override it >> at build time as well. >> > > The issue with Nagios::Plugin is that it's distributed via CPAN as > well > as (?) via tarball/packages i.e. it won't necessarily be installed at > regular 'build time'. So it probably needs to be a run-time thing for > N::P - is $config-prefix available anywhere post-install at the > moment? That old chicken-egg thing again :(. Looking at DBD::Oracle (http:// search.cpan.org/dist/DBD-Oracle/ Oracle.pm#Oracle_Environment_Variables), it seems they use environment variables to find the location of Oracle libraries. What about using an environment variable if set. Otherwise look in a set of "common" locations. Given that we use the same prefix as nagios (/usr/local/nagios), maybe /usr/local/nagios/etc/plugins.ini is a decent default. I guess other common locations are: /etc/plugins.ini /etc/nagios/plugins.ini /usr/local/etc/nagios/plugins.ini /usr/local/etc/plugins.ini Or we could say you have to set the env var, otherwise fully specify the filename on command line. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Thu Feb 15 18:38:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Feb 2007 09:38:25 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1660802 ] check_hpjd: added JetReady support Message-ID: Patches item #1660802, was opened at 2007-02-15 12:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1660802&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: Unstable (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Karl Grindley (karlg100) Assigned to: Nobody/Anonymous (nobody) Summary: check_hpjd: added JetReady support Initial Comment: HP (in their infinite wisdom) flipped logic in snmp for "online" and "offline" status on the "JetReady" slimmed down embedded print server. With the unpatched check_hpjd, logic is backwards. Added a -A/--jetready command line argument to tell check_hpjd to flip the logic for this snmp mib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1660802&group_id=29880 From noreply at sourceforge.net Thu Feb 15 22:50:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Feb 2007 13:50:14 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1660953 ] check_disk.t - test 36 exiting non ok but should be ok Message-ID: Bugs item #1660953, was opened at 2007-02-15 22:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1660953&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Eble (psychotrahe) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk.t - test 36 exiting non ok but should be ok Initial Comment: hi all, I was just setting up a testing environment for the nagios plugins when I noticed a false positive. check_disk claims / 4641 MB (75% inode=97%); /var 2369 MB (57% inode=93%) which is right. but test case #36 exits non ok executing ./check_disk -e -W 95% -K 0% -p /var -W 95% -K 95% -p / not ok 36 - Has ignored / as not a problem # Failed test 'Has ignored / as not a problem' # at t/check_disk.t line 201. # 'DISK WARNING - free space: /var 2485 MB (60% inode=93%);' # matches '(?-xism:/)' imo because /var matches /. Finding / means there's a problem with the test. Everything works fine if / has less free inodes than /var. changing unlike( $result->only_output, qr/$more_inode_free/, "Has ignored $more_inode_free as not a problem"); to unlike( $result->only_output, qr/$more_inode_free\s/, "Has ignored $more_inode_free as not a problem"); helps. Maybe there are more expressions like this in check_disk.t. I did no further examinations. matthias P.S. The test can't be executed using Reiser filesystems since check_disk can't determine inode usage on reiserfs (at least on my notebook) and exits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1660953&group_id=29880 From matthias.eble at mailing.kaufland-informationssysteme.com Thu Feb 15 23:58:48 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Thu, 15 Feb 2007 23:58:48 +0100 Subject: [Nagiosplug-devel] patches for new features of check_disk In-Reply-To: References: <45CE41AA.8000301@mailing.kaufland-informationssysteme.com> Message-ID: <45D4E5A8.2010800@mailing.kaufland-informationssysteme.com> Hi ton, hi list > > On 10 Feb 2007, at 22:05, Matthias Eble wrote: > >> I made a few patches for check_disk that add some functionality we >> need. >> They apply cleanly to latest cvs and 1.4.6 if following order is >> kept: check_disk-clearfix.patch, check_disk-grouping.patch, >> check_disk-regex.patch. > > I've had a think about these patches and I think the functionality is > great. nice to hear > I'd like some test cases for the grouping patch. It should be > possible to take the two already defined mount points and get it to > alert below and above a threshold which is for the group rather than > per filesystem, proving the thresholds work at the group level. Are you thinking of tests like 0% and 100% and check if the plugin exits critical/ok or do you think of sth more in depth? I could imagine a test using actual data as a threshold would be better, but that would require a percent-calculation-routine - and I'm not sure if there should be that much logic in the tests. > I found the patches a bit hard to apply because the email had all of > them together. Can you send me 3 separate attachments please? Sorry for that.. no problem. I guess a tar/gz (attached) should be alright. Please contact me if not. > It will take some time to work through these because there does seem > to be quite a lot of changes, but in principle, I think this is a > good move. I tried to change as few as possible. Thank you matthias P.S I found two minor errors in the initially sent regex patch. They are fixed in the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_disk-patches.tar.gz Type: application/x-gzip Size: 50367 bytes Desc: not available URL: From matthias.eble at mailing.kaufland-informationssysteme.com Fri Feb 16 00:24:25 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Fri, 16 Feb 2007 00:24:25 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <1170927858.14170.17.camel@localhost> <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> Message-ID: <45D4EBA9.3070909@mailing.kaufland-informationssysteme.com> Hi all, > What about using an environment variable if set. Otherwise look in a > set of "common" locations. Given that we use the same prefix as > nagios (/usr/local/nagios), maybe /usr/local/nagios/etc/plugins.ini > is a decent default. I guess other common locations are: > /etc/plugins.ini > /etc/nagios/plugins.ini > /usr/local/etc/nagios/plugins.ini > /usr/local/etc/plugins.ini perhaps the FHS way should be considered, too: /etc/opt/(nagiosplug|nagios-plugins)/plugins.ini Btw: the filename /etc/plugins.ini is too general in my opinion. I'd prefer nagios-plugins.ini or nagiosplug.ini From seanius at seanius.net Fri Feb 16 08:07:43 2007 From: seanius at seanius.net (sean finney) Date: Fri, 16 Feb 2007 08:07:43 +0100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <45D4EBA9.3070909@mailing.kaufland-informationssysteme.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <1170927858.14170.17.camel@localhost> <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> <45D4EBA9.3070909@mailing.kaufland-informationssysteme.com> Message-ID: <1171609663.5205.9.camel@localhost> On Fri, 2007-02-16 at 00:24 +0100, Matthias Eble wrote: > Hi all, > > > What about using an environment variable if set. Otherwise look in a > > set of "common" locations. Given that we use the same prefix as > > nagios (/usr/local/nagios), maybe /usr/local/nagios/etc/plugins.ini > > is a decent default. I guess other common locations are: > > /etc/plugins.ini > > /etc/nagios/plugins.ini > > /usr/local/etc/nagios/plugins.ini > > /usr/local/etc/plugins.ini > > perhaps the FHS way should be considered, too: > /etc/opt/(nagiosplug|nagios-plugins)/plugins.ini i would say that both the plugins and Nagios::Plugin should have a single default location, which equates to the same config root where the rest of the files would go in a default "make install", with a sensible filename. as long as both of the above provide a way to override this setting (i.e. by setting passing some cmdline option when building/installing or having the location in an easily patchable location), i don't see there being any problem. plus, one will always be able to override it at runtime too. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ton.voon at altinity.com Fri Feb 16 10:14:06 2007 From: ton.voon at altinity.com (Ton Voon) Date: Fri, 16 Feb 2007 09:14:06 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <1171609663.5205.9.camel@localhost> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <1170927858.14170.17.camel@localhost> <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> <45D4EBA9.3070909@mailing.kaufland-informationssysteme.com> <1171609663.5205.9.camel@localhost> Message-ID: <7596A286-485A-4A50-985F-2A7DB2876131@altinity.com> Hi! Matthias wrote: > > Btw: the filename /etc/plugins.ini is too general in my opinion. > I'd prefer nagios-plugins.ini or nagiosplug.ini Fair point. I like nagios-plugins.ini as this matches the tarball distribution. On 16 Feb 2007, at 07:07, sean finney wrote: > On Fri, 2007-02-16 at 00:24 +0100, Matthias Eble wrote: >>> What about using an environment variable if set. Otherwise look in a >>> set of "common" locations. Given that we use the same prefix as >>> nagios (/usr/local/nagios), maybe /usr/local/nagios/etc/plugins.ini >>> is a decent default. I guess other common locations are: >>> /etc/plugins.ini >>> /etc/nagios/plugins.ini >>> /usr/local/etc/nagios/plugins.ini >>> /usr/local/etc/plugins.ini >> >> perhaps the FHS way should be considered, too: >> /etc/opt/(nagiosplug|nagios-plugins)/plugins.ini > > i would say that both the plugins and Nagios::Plugin should have > a single default location, which equates to the same config root > where the rest of the files would go in a default "make install", > with a sensible filename. > > as long as both of the above provide a way to override this setting > (i.e. by setting passing some cmdline option when building/installing > or having the location in an easily patchable location), i don't see > there being any problem. plus, one will always be able to override > it at runtime too. OK. So if $DEFAULT_INI_FILE=/usr/local/nagios/etc/nagios-plugins.ini is somewhere in Nagios::Plugin.pm, then when the Debian maintainer packages it, they can patch just this one line? Sounds fair. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri Feb 16 13:41:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Feb 2007 04:41:23 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1595449 ] check_procs bus error, ... on Solaris 8, 9 & 10 Message-ID: Bugs item #1595449, was opened at 2006-11-13 02:23 Message generated for change (Comment added) made by msbenjamin12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs bus error, ... on Solaris 8, 9 & 10 Initial Comment: check_procs bus error, segmentation fault or wrong output on Solaris 8, 9 & 10 Do first the next configure! ---------------------------- ./configure --with-ps_command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" --with-ps_format='%s %d %d %d %d %d %f %s %s %n' --with-ps_cols=10 --with-ps_varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' --with-trusted-path=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin To solve the bus error and /or segmentation fault on Solaris 8: -------------------------------------------------- replace into check_procs.c if ( cols >= expected_cols ) { resultsum = 0; - asprintf (&procargs, "%s", input_line + pos); strip (procargs); with if ( cols >= expected_cols ) { resultsum = 0; + asprintf (&procargs, "%s", input_line); strip (procargs); To solve the wrong output on Solaris 8, 9 & 10: ----------------------------------------------- change into common.h MAX_INPUT_BUFFER 1024 to MAX_INPUT_BUFFER 4096 ---------------------------------------------------------------------- Comment By: msB (msbenjamin12) Date: 2007-02-16 06:41 Message: Logged In: YES user_id=1097533 Originator: NO Where is the original code, I need to fix this I get the wrong output on Solaris 9. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-16 23:37 Message: Logged In: YES user_id=375623 Originator: NO The wrong output bug should be fixed (1630970). I (or somebody else) will have to look further for the bus error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 From noreply at sourceforge.net Sat Feb 17 04:20:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Feb 2007 19:20:08 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1592574 ] Plugin compilation fails in check_ntp.c Message-ID: <200702170320.l1H3K8UP032009@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1592574, was opened at 2006-11-08 03:29 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1592574&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Deon Ramsey (dramsey) Assigned to: Ton Voon (tonvoon) Summary: Plugin compilation fails in check_ntp.c Initial Comment: I am trying to get Nagios 2.5 running on a RedHat Linux release 7.3 (Valhalla) . I have compiled Nagios itself with no problem, then went on to compile nagios-plugins-1.4.5 . The compiler dies with the following messages: nagios-host# make make all-recursive make[1]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5' Making all in lib make[2]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make all-recursive make[3]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib' Making all in tests make[4]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib/tests' make[4]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make[3]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib' make[2]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/lib' Making all in plugins make[2]: Entering directory `/u/root/incoming/nagios-plugins-1.4.5/plugins' if /usr/local/bin/gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl -I/usr/include -g -O2 -MT check_ntp.o -MD -MP -MF ".deps/check_ntp.Tpo" -c -o check_ntp.o check_ntp.c; \ then mv -f ".deps/check_ntp.Tpo" ".deps/check_ntp.Po"; else rm -f ".deps/check_ntp.Tpo"; exit 1; fi check_ntp.c: In function 'setup_request': check_ntp.c:295: error: invalid operands to binary & check_ntp.c:295: error: invalid operands to binary & check_ntp.c:295: error: invalid operands to binary & check_ntp.c:295: error: invalid operands to binary & make[2]: *** [check_ntp.o] Error 1 make[2]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/u/root/incoming/nagios-plugins-1.4.5' make: *** [all] Error 2 nagios-host# At first, I suspected this to be a compiler error because I was using the gcc-2.96 installed by default in the OS, so I compiled and installed gcc-4.1.1 and tried again, but this didn't change anything. On an aside, I don't even *need* the ntp plugin, is there any support for telling the system not to build it in the first place ? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-02-16 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-02-02 08:57 Message: Logged In: YES user_id=664364 Originator: NO Hi Deon, This should be fixed in CVS now. Please confirm with the snapshot at http://nagiosplug.sf.net/snapshot. This call will auto close after 7 days if there are no updates. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1592574&group_id=29880 From noreply at sourceforge.net Sat Feb 17 04:20:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Feb 2007 19:20:08 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1484825 ] check_dhcp fails to link on Solaris 2.6 Message-ID: <200702170320.l1H3K8ca032074@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1484825, was opened at 2006-05-09 09:35 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Ethan Galstad (egalstad) Summary: check_dhcp fails to link on Solaris 2.6 Initial Comment: /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib/libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a -liconv -lgen -lnsl gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/tmp/nagios-plugins-1.4.3/plugins-root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket -lresolv ../intl/libintl.a /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/openwin/lib -L/usr/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -lgen -lnsl -R/usr/local/lib -R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 ===== Modifying the Makefile EXTRA_NETOBJS = getaddrinfo.o gethostbyname.o to EXTRA_NETOBJS = ../plugins/getaddrinfo.o ../plugins/gethostbyname.o fixes it ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-02-16 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2007-02-02 09:04 Message: Logged In: YES user_id=664364 Originator: NO Hi Duncan, This should be fixed in CVS now. Please can you try the snapshot at http://nagiosplug.sf.net/snapshot. This call with autoclose in 7 days if no updates are applied. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2006-06-20 11:43 Message: Logged In: YES user_id=664364 Ethan, Can I take this? I want to move the substitute getaddinfo library into lib/. This should fix various other tracker items as well. Ton ---------------------------------------------------------------------- Comment By: Jason Kau (bubbafat) Date: 2006-05-11 22:19 Message: Logged In: YES user_id=1495257 Same thing occurs on Solaris 7 using gcc version egcs- 2.91.66 19990314 (egcs-1.1.2 release): source='check_dhcp.c' object='check_dhcp.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/ksh ../depcomp \ gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -c check_dhcp.c /bin/ksh ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a getaddrinfo.o gethostbyname.o -lnsl -lsocket -lresolv ../intl/libintl.a - lgen -lnsl -lssl -lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o getaddrinfo.o gethostbyname.o -L/home/jkau/build/nagios- plugins/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lsocket - lresolv ../intl/libintl.a -lgen -lnsl -lssl -lcrypto - R/usr/local/lib gcc: getaddrinfo.o: No such file or directory gcc: gethostbyname.o: No such file or directory make: *** [check_dhcp] Error 1 However on Solaris 8 using gcc version 3.3.2 this problem does not occurr: if gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" - DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../lib -I../intl - I../plugins -I/usr/local/include -I/usr/local/include -g - O2 -MT check_dhcp.o -MD -MP -MF ".deps/check_dhcp.Tpo" -c - o check_dhcp.o check_dhcp.c; \ then mv -f ".deps/check_dhcp.Tpo" ".deps/check_dhcp.Po"; else rm -f ".deps/check_dhcp.Tpo"; exit 1; fi /bin/bash ../libtool --mode=link --tag=CC gcc -g -O2 -L. - R/usr/local/lib -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o ../lib /libnagiosplug.a ../lib/libcoreutils.a -lnsl -lsocket - lresolv ../intl/libintl.a -liconv -lgen -lsocket -lssl - lcrypto mkdir .libs gcc -g -O2 -o check_dhcp check_dhcp.o ../plugins/netutils.o ../plugins/utils.o - L/home/gtri/nagios/nagios-plugins-1.4.3/plugins- root ../lib/libnagiosplug.a ../lib/libcoreutils.a -lnsl - lresolv ../intl/libintl.a /usr/local/lib/libiconv.so - L/usr/lib -L/usr/openwin/lib -L/usr/local/lib - L/usr/local/ssl/lib -lgen -lsocket -lssl -lcrypto - R/usr/local/lib -R/usr/local/lib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1484825&group_id=29880 From noreply at sourceforge.net Sat Feb 17 15:05:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Feb 2007 06:05:39 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1595449 ] check_procs bus error, ... on Solaris 8, 9 & 10 Message-ID: Bugs item #1595449, was opened at 2006-11-13 03:23 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs bus error, ... on Solaris 8, 9 & 10 Initial Comment: check_procs bus error, segmentation fault or wrong output on Solaris 8, 9 & 10 Do first the next configure! ---------------------------- ./configure --with-ps_command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime comm args'" --with-ps_format='%s %d %d %d %d %d %f %s %s %n' --with-ps_cols=10 --with-ps_varlist='procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos' --with-trusted-path=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin To solve the bus error and /or segmentation fault on Solaris 8: -------------------------------------------------- replace into check_procs.c if ( cols >= expected_cols ) { resultsum = 0; - asprintf (&procargs, "%s", input_line + pos); strip (procargs); with if ( cols >= expected_cols ) { resultsum = 0; + asprintf (&procargs, "%s", input_line); strip (procargs); To solve the wrong output on Solaris 8, 9 & 10: ----------------------------------------------- change into common.h MAX_INPUT_BUFFER 1024 to MAX_INPUT_BUFFER 4096 ---------------------------------------------------------------------- >Comment By: Thomas Guyot (dermoth) Date: 2007-02-17 09:05 Message: Logged In: YES user_id=375623 Originator: NO The patch can be found on bug #1630970. It is also fixed in the latest release, 1.4.6 https://sourceforge.net/tracker/index.php?func=detail&aid=1630970&group_id=29880&atid=397597 ---------------------------------------------------------------------- Comment By: msB (msbenjamin12) Date: 2007-02-16 07:41 Message: Logged In: YES user_id=1097533 Originator: NO Where is the original code, I need to fix this I get the wrong output on Solaris 9. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-01-17 00:37 Message: Logged In: YES user_id=375623 Originator: NO The wrong output bug should be fixed (1630970). I (or somebody else) will have to look further for the bus error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1595449&group_id=29880 From noreply at sourceforge.net Sat Feb 17 23:29:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Feb 2007 14:29:04 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1662550 ] check_ntp: stratum level alerting Message-ID: Patches item #1662550, was opened at 2007-02-17 17:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1662550&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Larry Low (llow) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp: stratum level alerting Initial Comment: This patch adds -s and -S for alerting when a ntp server stratum level reaches or exceeds a set value. I also notice jitter options were missing from the help command line and added help comments for them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1662550&group_id=29880 From gavin at openfusion.com.au Sun Feb 18 05:11:40 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Sun, 18 Feb 2007 15:11:40 +1100 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <7596A286-485A-4A50-985F-2A7DB2876131@altinity.com> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <1170927858.14170.17.camel@localhost> <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> <45D4EBA9.3070909@mailing.kaufland-informationssysteme.com> <1171609663.5205.9.camel@localhost> <7596A286-485A-4A50-985F-2A7DB2876131@altinity.com> Message-ID: <20070218041140.GA24266@openfusion.com.au> On Fri, Feb 16, 2007 at 09:14:06AM +0000, Ton Voon wrote: > Hi! > > Matthias wrote: > > > > Btw: the filename /etc/plugins.ini is too general in my opinion. > > I'd prefer nagios-plugins.ini or nagiosplug.ini > > Fair point. I like nagios-plugins.ini as this matches the tarball > distribution. It's too general in a general-purpose directory like /etc. It's just right in a nagios directory like /etc/nagios. IMO it's okay to support both. > On 16 Feb 2007, at 07:07, sean finney wrote: > > > On Fri, 2007-02-16 at 00:24 +0100, Matthias Eble wrote: > >>> What about using an environment variable if set. Otherwise look in a > >>> set of "common" locations. Given that we use the same prefix as > >>> nagios (/usr/local/nagios), maybe /usr/local/nagios/etc/plugins.ini > >>> is a decent default. I guess other common locations are: > >>> /etc/plugins.ini > >>> /etc/nagios/plugins.ini > >>> /usr/local/etc/nagios/plugins.ini > >>> /usr/local/etc/plugins.ini > >> > >> perhaps the FHS way should be considered, too: > >> /etc/opt/(nagiosplug|nagios-plugins)/plugins.ini > > > > i would say that both the plugins and Nagios::Plugin should have > > a single default location, which equates to the same config root > > where the rest of the files would go in a default "make install", > > with a sensible filename. > > > > as long as both of the above provide a way to override this setting > > (i.e. by setting passing some cmdline option when building/installing > > or having the location in an easily patchable location), i don't see > > there being any problem. plus, one will always be able to override > > it at runtime too. > > OK. So if $DEFAULT_INI_FILE=/usr/local/nagios/etc/nagios-plugins.ini > is somewhere in Nagios::Plugin.pm, then when the Debian maintainer > packages it, they can patch just this one line? Sounds fair. But that doesn't solve the install from CPAN problem though, right? I think we're probably going to have add install-time code there too to search for likely directories and get explicit confirmation from the user, if possible ... Cheers, Gavin From noreply at sourceforge.net Sun Feb 18 09:34:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Feb 2007 00:34:26 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1662706 ] Mac OSX support for check_dhcp Message-ID: Patches item #1662706, was opened at 2007-02-18 08:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1662706&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Grim (cgrim) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OSX support for check_dhcp Initial Comment: Running check_dhcp on Mac OSX currently gives the error: Error: can't get MAC address for this architecture. The attached patch enables Mac OSX versions of the plugin to find the MAC address of an interface using the existing BSD code. This was enough to get the plugin working on an Intel Mac running Mac OSX 10.4.8. Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1662706&group_id=29880 From noreply at sourceforge.net Thu Feb 22 04:20:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Feb 2007 19:20:09 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1650176 ] check_snmp: Passing -Pu to snmpget command Message-ID: <200702220320.l1M3K9FE025772@sc8-sf-db2-new-b.sourceforge.net> Feature Requests item #1650176, was opened at 2007-02-01 13:58 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Private: No Submitted By: Andrew Elwell (elwell2000) Assigned to: Thomas Guyot (dermoth) Summary: check_snmp: Passing -Pu to snmpget command Initial Comment: Using a (Badly written) vendor supplied MIB from Areca for a raid card (see http://www.areca.us/support/download/RaidCards/AP_Driver/SNMP_MIBs.zip ) snmpget is only happy if we pass the "-Pu" (ignore underscores) flag to it. I have made a workaround by permanently patching the source of check_snmp.c PROBLEM: # snmpget -v1 -c public hostname ARECA-SNMP-MIB::raidState.0 Bad operator (_): At line 20 in /usr/share/snmp/mibs/ARECA-SNMP-MIB.txt ARECA-SNMP-MIB::raidState.0: Unknown Object Identifier # snmpget -v1 -c public -Pu hostname ARECA-SNMP-MIB::raidState.0 ARECA-SNMP-MIB::raidState.0 = STRING: "Normal" WORKAROUND: /* asprintf (&command_line, "%s -t %d -r %d -m %s -v %s %s %s:%s %s", */ /* Hack below to accept underscores as areca mib broken */ asprintf (&command_line, "%s -Pu -t %d -r %d -m %s -v %s %s %s:%s %s", But it'd be nice to be able to pass this flag to the check_snmp if needed Andrew ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-02-21 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-02-07 05:43 Message: Logged In: YES user_id=375623 Originator: NO This feature request will auto-close in 14 days of inactivity. ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2007-02-02 06:07 Message: Logged In: YES user_id=375623 Originator: NO Have you tried: mibAllowUnderline true in snmp.conf (not snmpD.conf!) This should fix your problem. You can also specify numeric OIDs to avoid the need to parse mibs. If you need to specify multiple OIDs be sure to get the latest CVS (or upcoming nagios-plugins release) as it fixes a bug where multiple numeric OIDs would cause check_snmp to load the MIBs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1650176&group_id=29880 From ton.voon at altinity.com Thu Feb 22 12:38:37 2007 From: ton.voon at altinity.com (Ton Voon) Date: Thu, 22 Feb 2007 11:38:37 +0000 Subject: [Nagiosplug-devel] RFC: Plugins config file (final proposal) In-Reply-To: <20070218041140.GA24266@openfusion.com.au> References: <8CF3E17D-4692-4AFB-9EBC-27C3C15C23FD@altinity.com> <20070207232158.GA21297@openfusion.com.au> <1170927858.14170.17.camel@localhost> <90DE36B5-E6CD-4FF9-93B8-A056DD97BB78@altinity.com> <45D4EBA9.3070909@mailing.kaufland-informationssysteme.com> <1171609663.5205.9.camel@localhost> <7596A286-485A-4A50-985F-2A7DB2876131@altinity.com> <20070218041140.GA24266@openfusion.com.au> Message-ID: On 18 Feb 2007, at 04:11, Gavin Carr wrote: > On Fri, Feb 16, 2007 at 09:14:06AM +0000, Ton Voon wrote: >> On 16 Feb 2007, at 07:07, sean finney wrote: >> >>> i would say that both the plugins and Nagios::Plugin should have >>> a single default location, which equates to the same config root >>> where the rest of the files would go in a default "make install", >>> with a sensible filename. >>> >>> as long as both of the above provide a way to override this setting >>> (i.e. by setting passing some cmdline option when building/ >>> installing >>> or having the location in an easily patchable location), i don't see >>> there being any problem. plus, one will always be able to override >>> it at runtime too. >> >> OK. So if $DEFAULT_INI_FILE=/usr/local/nagios/etc/nagios-plugins.ini >> is somewhere in Nagios::Plugin.pm, then when the Debian maintainer >> packages it, they can patch just this one line? Sounds fair. > > But that doesn't solve the install from CPAN problem though, right? I > think we're probably going to have add install-time code there too to > search for likely directories and get explicit confirmation from the > user, if possible ... What about this? Have NP_DEFAULT_INI_FILE as an environment variable. If this is set at runtime for Nagios::Plugin, use that location. Otherwise default "/ usr/local/nagios/etc/nagios-plugins.ini". I notice for XML::SAX::Expat that you can set some "compile time environment variables" to specify where the expat libs are. So if NP_DEFAULT_INI_FILE environment variable is set at "perl Makefile.PL" time, switch the default to that file. So we'd have a way of overriding at build time and at runtime, with a reasonable default value. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri Feb 23 00:33:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Feb 2007 15:33:45 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1666601 ] Solaris 8 check_procs plugin hangs until timeout Message-ID: Bugs item #1666601, was opened at 2007-02-22 23:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1666601&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John R. Taisto (jtaisto) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 8 check_procs plugin hangs until timeout Initial Comment: check_procs (nagios-plugins 1.4.6) 1.57 Always exits with a timeout no matter how long it's given. Example 1: $plugins/check_procs -w 10 -c 20 --metric=CPU -t 10 CRITICAL - Plugin timed out after 10 seconds Example 2: plugins/check_procs -w 10 -c 20 --metric=CPU -t 60 CRITICAL - Plugin timed out after 60 seconds Solaris 8 (Generic kernel -44) Compiled with gcc 3.4.6 (SPARC) (-O2 -m64) No errors reported and binary gets created: Other plugins seem to work fine: No missing libraries: $ ldd plugins/check_procs libnsl.so.1 => /usr/lib/64/libnsl.so.1 libsocket.so.1 => /usr/lib/64/libsocket.so.1 libc.so.1 => /usr/lib/64/libc.so.1 libdl.so.1 => /usr/lib/64/libdl.so.1 libmp.so.2 => /usr/lib/64/libmp.so.2 /usr/platform/SUNW,Sun-Blade-100/lib/sparcv9/libc_psr.so.1 Truss output: truss -c ./plugins/check_procs -w 10 -c 20 --metric=CPU -t 10 CRITICAL - Plugin timed out after 10 seconds signals ------------ SIGALRM 1 total: 1 syscall seconds calls errors _exit .00 1 fork .00 1 read 2.04 138822 write .00 1 open .00 12 1 close .00 13 brk .00 4 stat .00 40 29 lseek .00 3 2 getpid .00 1 alarm .00 1 fstat .00 1 kill .01 1 pipe .00 2 ioctl .00 2 1 execve .00 1 sigaction .00 1 mmap .00 32 munmap .00 5 setrlimit .00 1 getrlimit .00 1 memcntl .00 4 resolvepath .00 12 ------- ------ ---- sys totals: 2.05 138962 33 usr time: .53 elapsed: 10.04 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1666601&group_id=29880 From jon.sundfjord at smartnet.no Fri Feb 23 11:24:35 2007 From: jon.sundfjord at smartnet.no (Jon Sundfjord) Date: Fri, 23 Feb 2007 11:24:35 +0100 Subject: [Nagiosplug-devel] ndoutils 1.4b2 with PostgreSQL support Message-ID: <1172226276.12331.4.camel@jsundfjo-laptop> Hi We have added PostgreSQL support to ndoutils 1.4b2. Is anyone interested in trying this version ? Regards, Jon Sundfjord Smartnet AS From Thomas at zango.com Fri Feb 23 20:26:34 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Fri, 23 Feb 2007 11:26:34 -0800 Subject: [Nagiosplug-devel] check_file_age thresholds Message-ID: <804160344192334BB21922E8082EA6C05DB9CA@seaex01.180solutions.com> Hey, I was looking at using check_file_age to monitor file size, but the current threshold format doesn't give much flexibility... Since there's no threshold functions in utils.pm should we copy them from Narios::Plugins to utils.pm, or rather start moving the perl plugins from using utils.pm to using Nagios::Plugins (and maybe bundling a specific Nagios::Plugins by installing it in @libexecdir@, although I think this can cause problem with ePN if Nagios::Plugins is already in @INC); Also considering that check_file_age is misleading as it can check file size as well, and also that using the standard threshold format would break backwards-compatibility, I was thinking about renaming it to check_file if we make it use standard thresholds formats. Any though? Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From noreply at sourceforge.net Fri Feb 23 22:54:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Feb 2007 13:54:12 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1667488 ] support for server identifier (54) as offerer/siaddr Message-ID: Patches item #1667488, was opened at 2007-02-23 22:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: denis knauf (deac-) Assigned to: Nobody/Anonymous (nobody) Summary: support for server identifier (54) as offerer/siaddr Initial Comment: check_dhcp doesn't use server identifier (54) as server (siaddr), but this is the real serveraddresse. source is only the address of the relay-dhcp (giaddr). this patch adds the server_identifier as siaddr. btw. please "ident" your code. it's so terrible to patch this files, if somebody wrotes such unreadable code. thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 From gavin at openfusion.com.au Sat Feb 24 02:09:50 2007 From: gavin at openfusion.com.au (Gavin Carr) Date: Sat, 24 Feb 2007 12:09:50 +1100 Subject: [Nagiosplug-devel] check_file_age thresholds In-Reply-To: <804160344192334BB21922E8082EA6C05DB9CA@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C05DB9CA@seaex01.180solutions.com> Message-ID: <20070224010950.GA4504@openfusion.com.au> Hi Thomas, On Fri, Feb 23, 2007 at 11:26:34AM -0800, Thomas Guyot-Sionnest wrote: > I was looking at using check_file_age to monitor file size, but the current > threshold format doesn't give much flexibility... Since there's no threshold > functions in utils.pm should we copy them from Narios::Plugins to utils.pm, > or rather start moving the perl plugins from using utils.pm to using > Nagios::Plugins (and maybe bundling a specific Nagios::Plugins by installing > it in @libexecdir@, although I think this can cause problem with ePN if > Nagios::Plugins is already in @INC); I think it's time to start migrating the utils.pm plugins to Nagios::Plugin. > Also considering that check_file_age is misleading as it can check file size > as well, and also that using the standard threshold format would break > backwards-compatibility, I was thinking about renaming it to check_file if > we make it use standard thresholds formats. I've also get a check_file perl plugin here: http://www.openfusion.com.au/labs/nagios/check_file that does mtime, size, and regex / error_regex checking using Nagios::Plugin. It doesn't use standardised Nagios thresholds, though (when I originally wrote it I wasn't aware of the dev standards on threshold syntax). I'm happy if you want to use that name, though, or if you want to take code from that plugin, or if we'd like to include that plugin instead of check_file_age, and standardise the threshold behaviour. Thoughts? Cheers, Gavin -- Gavin Carr - http://www.openfusion.com.au - Linux, Perl, and Web Consulting - http://www.xool.com.au - Xool, Australian property search engine * Fashion is a variable, but style is a constant - Programming Perl From noreply at sourceforge.net Sat Feb 24 07:30:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Feb 2007 22:30:50 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1667488 ] check_dhcp: server identifier(54) as offerer/siaddr Message-ID: Patches item #1667488, was opened at 2007-02-23 22:54 Message generated for change (Settings changed) made by deac- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: denis knauf (deac-) Assigned to: Nobody/Anonymous (nobody) >Summary: check_dhcp: server identifier(54) as offerer/siaddr Initial Comment: check_dhcp doesn't use server identifier (54) as server (siaddr), but this is the real serveraddresse. source is only the address of the relay-dhcp (giaddr). this patch adds the server_identifier as siaddr. btw. please "ident" your code. it's so terrible to patch this files, if somebody wrotes such unreadable code. thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1667488&group_id=29880 From ext-christian.1.roche at nokia.com Mon Feb 26 12:03:48 2007 From: ext-christian.1.roche at nokia.com (ext-christian.1.roche at nokia.com) Date: Mon, 26 Feb 2007 12:03:48 +0100 Subject: [Nagiosplug-devel] Nagios check_disk_smb plugin patch Message-ID: Hi there, may I suggest the following change to the option handling in the check_disk_smb plugin, so that it conforms to the usage message and doesn't break in case some options with no default values are missing ? Thanks, Christian Roche -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_disk_smb.patch Type: application/octet-stream Size: 2019 bytes Desc: check_disk_smb.patch URL: From matthias.eble at mailing.kaufland-informationssysteme.com Mon Feb 26 12:59:34 2007 From: matthias.eble at mailing.kaufland-informationssysteme.com (Matthias Eble) Date: Mon, 26 Feb 2007 12:59:34 +0100 Subject: [Nagiosplug-devel] check_file_age thresholds In-Reply-To: <20070224010950.GA4504@openfusion.com.au> References: <804160344192334BB21922E8082EA6C05DB9CA@seaex01.180solutions.com> <20070224010950.GA4504@openfusion.com.au> Message-ID: <45E2CBA6.8000307@mailing.kaufland-informationssysteme.com> >> or rather start moving the perl plugins from using utils.pm to using >> Nagios::Plugins (and maybe bundling a specific Nagios::Plugins by installing >> it in @libexecdir@ .. > > I think it's time to start migrating the utils.pm plugins to > Nagios::Plugin. have there been any thoughts whether Nagios::Plugin will be bundled or not? I like the libexec approach because we distribute the plugins independently from a central system since most plugins work out of the box without requiring any OS package-dependencies. >> Also considering that check_file_age is misleading as it can check file size >> as well, and also that using the standard threshold format would break >> backwards-compatibility, I was thinking about renaming it to check_file if >> we make it use standard thresholds formats. maybe check_file_age could stay as a symlink to check_file. --help could contain a warning message that check_file_age is deprecated and could be removed in the future. From Thomas at zango.com Mon Feb 26 17:02:33 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 26 Feb 2007 08:02:33 -0800 Subject: [Nagiosplug-devel] check_file_age thresholds In-Reply-To: <45E2CBA6.8000307@mailing.kaufland-informationssysteme.com> References: <804160344192334BB21922E8082EA6C05DB9CA@seaex01.180solutions.com><20070224010950.GA4504@openfusion.com.au> <45E2CBA6.8000307@mailing.kaufland-informationssysteme.com> Message-ID: <804160344192334BB21922E8082EA6C05DBB95@seaex01.180solutions.com> > -----Original Message----- > From: nagiosplug-devel-bounces at lists.sourceforge.net > [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On > Behalf Of Matthias Eble > Sent: February 26, 2007 7:00 > To: Nagios Plugin Development Mailing List > Subject: Re: [Nagiosplug-devel] check_file_age thresholds > > > > I think it's time to start migrating the utils.pm plugins to > > Nagios::Plugin. > > have there been any thoughts whether Nagios::Plugin will be > bundled or > not? I like the libexec approach because we distribute the plugins > independently from a central system since most plugins work > out of the > box without requiring any OS package-dependencies. What I'm worried about is that AFAIK Perl complains when it finds duplicate packages in different lib dirs. I especially fear that this could break ePN... Maybe a workaround would be to slightly change the name for Nagios::Plugin, so you can use the system Nagios::Plugin (ex if Mr. Doe writes his own plugin) and Nagiosplug would use something like: use lib @libexecdir@; Use Nagiosplug::Plugin Since the name is slightly different Perl shouldn't complain. Also there's no risk of unexpected interactions between the Nagios-plugins and any newer version of the system Nagios::Plugin (Which IMHO should be avoided at all costs, this could give ppl a lot of trouble). > maybe check_file_age could stay as a symlink to check_file. > --help could > contain a warning message that check_file_age is deprecated > and could be > removed in the future. I'd go with this option only if it doesn't break backwards-compatibility (the thresholds will be reversed!). i.e. if basename($0) eq 'check_file_age', do something so that the thresholds gets rewritten properly. We must first settle the Nagios::Plugin issue, then if everyone's ok with that I'll work on the check_file_age replacement. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From Thomas at zango.com Mon Feb 26 18:59:27 2007 From: Thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 26 Feb 2007 09:59:27 -0800 Subject: [Nagiosplug-devel] Check for available entropy? Message-ID: <804160344192334BB21922E8082EA6C05DBC3D@seaex01.180solutions.com> Guys, Would you be interested for a ckeck plugin for available entropy? In the past years I often had server performance problems caused by running out of entropy (uften fixed by using urandom instead of random). I was going to make a quick one for our systems, but if it's going to be included in Nagios-plugins I'd rather write a C one integrated to Nagios-plugins. Also, I know ho to check this on linux (/proc/sys/kernel/random/entropy_avail), what about FreeBSD (*BSD), Solaris and OS-X? I believe that by adding this check we'll encourage people to check this which is a GoodThing(tm) Thanks, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3076 bytes Desc: not available URL: From benoit.mortier at opensides.be Mon Feb 26 20:15:45 2007 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Mon, 26 Feb 2007 20:15:45 +0100 Subject: [Nagiosplug-devel] Check for available entropy? In-Reply-To: <804160344192334BB21922E8082EA6C05DBC3D@seaex01.180solutions.com> References: <804160344192334BB21922E8082EA6C05DBC3D@seaex01.180solutions.com> Message-ID: <200702262015.46814.benoit.mortier@opensides.be> Le Lundi 26 F?vrier 2007 18:59, Thomas Guyot-Sionnest a ?crit?: > Guys, > > Would you be interested for a ckeck plugin for available entropy? In the > past years I often had server performance problems caused by running out > of entropy (uften fixed by using urandom instead of random). I was going > to make a quick one for our systems, but if it's going to be included in > Nagios-plugins I'd rather write a C one integrated to Nagios-plugins. > > Also, I know ho to check this on linux > (/proc/sys/kernel/random/entropy_avail), what about FreeBSD (*BSD), > Solaris and OS-X? > > I believe that by adding this check we'll encourage people to check this > which is a GoodThing(tm) Hello, i'am interested in this check go ahead ;-) Cheers -- Benoit Mortier CEO www.opensides.be Contributor to Gosa Project : http://gosa.gonicus.de/ Contributeur to Nagios Plugins : http://nagiosplug.sourceforge.net/ From noreply at sourceforge.net Tue Feb 27 20:03:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Feb 2007 11:03:20 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1670261 ] SNMP: general child_process = spopen (command_line); problem Message-ID: Bugs item #1670261, was opened at 2007-02-27 20:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1670261&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Nobody/Anonymous (nobody) Summary: SNMP: general child_process = spopen (command_line); problem Initial Comment: SNMP problem - No data received from host check_snmp.c for testing purpose i did replace - child_process = spopen (command_line); with - child_process = spopen ("/usr/bin/ldd /opt/changed_root/bin/snmpget"); and then you can see the problem manual test: export LD_LIBRARY_PATH=/opt/changed_root/lib:/opt/changed_root/ssl/lib ldd /opt/changed_root/bin/snmpget libnetsnmp.so.15 => /opt/changed_root/lib/libnetsnmp.so.15 libgen.so.1 => /usr/lib/libgen.so.1 libcrypto.so.0.9.8 => /opt/changed_root/ssl/lib/libcrypto.so.0.9.8 libkstat.so.1 => /usr/lib/libkstat.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libm.so.1 => /usr/lib/libm.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libadm.so.1 => /usr/lib/libadm.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 where the generated command from check_snmp.c works fine /opt/changed_root/bin/snmpget -t 1 -r 5 -m '' -v 2c -c gn1r0t1n0m at notsoc1 10.1.100.50:8196 .1.3.6.1.4.1.140 ./check_snmp -P 2c -C gn1r0t1n0m at notsoc1 -H 10.1.100.50 -p 8196 -o .1.3.6.1.4.1.140 -v /opt/changed_root/bin/snmpget -t 1 -r 5 -m '' -v 2c -c gn1r0t1n0m at notsoc1 10.1.100.50:8196 .1.3.6.1.4.1.140 libnetsnmp.so.15 => (file not found) must be /opt/changed_root/lib libgen.so.1 => /usr/lib/libgen.so.1 libkstat.so.1 => /usr/lib/libkstat.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libm.so.1 => /usr/lib/libm.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libadm.so.1 => /usr/lib/libadm.so.1 libcrypto.so.0.9.8 => (file not found) must be /opt/changed_root/ssl/lib libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1670261&group_id=29880 From noreply at sourceforge.net Tue Feb 27 21:17:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Feb 2007 12:17:43 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1670261 ] SNMP: general child_process = spopen (command_line); problem Message-ID: Bugs item #1670261, was opened at 2007-02-27 20:03 Message generated for change (Comment added) made by zxr750 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1670261&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Peeters (zxr750) Assigned to: Nobody/Anonymous (nobody) Summary: SNMP: general child_process = spopen (command_line); problem Initial Comment: SNMP problem - No data received from host check_snmp.c for testing purpose i did replace - child_process = spopen (command_line); with - child_process = spopen ("/usr/bin/ldd /opt/changed_root/bin/snmpget"); and then you can see the problem manual test: export LD_LIBRARY_PATH=/opt/changed_root/lib:/opt/changed_root/ssl/lib ldd /opt/changed_root/bin/snmpget libnetsnmp.so.15 => /opt/changed_root/lib/libnetsnmp.so.15 libgen.so.1 => /usr/lib/libgen.so.1 libcrypto.so.0.9.8 => /opt/changed_root/ssl/lib/libcrypto.so.0.9.8 libkstat.so.1 => /usr/lib/libkstat.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libm.so.1 => /usr/lib/libm.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libadm.so.1 => /usr/lib/libadm.so.1 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 where the generated command from check_snmp.c works fine /opt/changed_root/bin/snmpget -t 1 -r 5 -m '' -v 2c -c gn1r0t1n0m at notsoc1 10.1.100.50:8196 .1.3.6.1.4.1.140 ./check_snmp -P 2c -C gn1r0t1n0m at notsoc1 -H 10.1.100.50 -p 8196 -o .1.3.6.1.4.1.140 -v /opt/changed_root/bin/snmpget -t 1 -r 5 -m '' -v 2c -c gn1r0t1n0m at notsoc1 10.1.100.50:8196 .1.3.6.1.4.1.140 libnetsnmp.so.15 => (file not found) must be /opt/changed_root/lib libgen.so.1 => /usr/lib/libgen.so.1 libkstat.so.1 => /usr/lib/libkstat.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libm.so.1 => /usr/lib/libm.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libadm.so.1 => /usr/lib/libadm.so.1 libcrypto.so.0.9.8 => (file not found) must be /opt/changed_root/ssl/lib libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1 ---------------------------------------------------------------------- >Comment By: Alex Peeters (zxr750) Date: 2007-02-27 21:17 Message: Logged In: YES user_id=590764 Originator: YES Solution added: Is it possible change the code so that ./configure has a parrameter LD_LIBRARY_PATH that then is passed in popen.c please Ohterwise we need everytime change again your code. Thanks in advance popen.c FILE * spopen (const char *cmdstring) { - char *env[2]; + char *env[3]; env[0] = strdup("LC_ALL=C"); - env[1] = '\0'; + env[1] = strdup("LD_LIBRARY_PATH=/opt/changed_root/lib:/opt/changed_root/ssl/lib:/usr/local/lib"); + env[2] = '\0'; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1670261&group_id=29880 From noreply at sourceforge.net Wed Feb 28 20:00:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Feb 2007 11:00:25 -0800 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1671141 ] scaling for check_nt Message-ID: Feature Requests item #1671141, was opened at 2007-02-28 19:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1671141&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Le Loup (le_loup) Assigned to: Nobody/Anonymous (nobody) Summary: scaling for check_nt Initial Comment: check_nt permits to access counters which may have inapproriate sizes. On nagios-portal.de someone asked how to access the system up time and produce a warning if it exceeds a certain value. The time is returned in seconds which is a bit difficult to handle for humans if you want to know the days. So I added two more optional parameters, a factor and a divisor. The changes were made on revision 1.46: 708c printf ("%s -H host -v variable [-p port] [-w warning] [-c critical] [-f factor] [-D divisor]",progname); . 646a printf (" %s\n", "-f, --factor=INTEGER"); printf (" %s", _("Optional factor (default: ")); printf ("%f)\n", factor); printf (" %s\n", "-D, --divisor=INTEGER"); printf (" %s", _("Optional divisor (default: ")); printf ("%f)\n", divisor); . 557a case 'f': /* factor */ factor=atof(optarg); break; case 'D': /* divisor */ divisor=atof(optarg); break; . 487c c = getopt_long(argc,argv,"+hVH:t:c:w:p:v:l:s:d:f:D:",longopts,&option); . 460a {"factor", required_argument,0,'f'}, {"divisor", required_argument,0,'D'}, . 326a counter_value *= factor; counter_value /= divisor; . 77a double factor=1.0; double divisor=1.0; . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1671141&group_id=29880