From linuxoid at gmail.com Thu Jun 6 09:17:43 2013 From: linuxoid at gmail.com (Ruslan Valiyev) Date: Thu, 6 Jun 2013 09:17:43 +0200 Subject: [Nagiosplug-devel] rpmbuild of latest nagios-plugins fails Message-ID: Hi all, I'm getting an error during rpmbuild when trying to build rpm from latest nagios-plugins-HEAD.tar.gz Looks like this library is shipped with the plugins package(?) Any hints on how to get rid of the error? + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: nagios-plugins-1.4.16-1.x86_64 error: File not found: /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/lib/nagios/plugins/libnpcommon.a Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.hZvPb5 + umask 022 + cd /root/rpmbuild/BUILD + cd nagios-plugins-1.4.16 + DOCDIR=/root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/share/doc/nagios-plugins-1.4.16 + export DOCDIR + rm -rf /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/share/doc/nagios-plugins-1.4.16 + /bin/mkdir -p /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/share/doc/nagios-plugins-1.4.16 + cp -pr CODING COPYING FAQ INSTALL LEGAL README REQUIREMENTS SUPPORT THANKS /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/share/doc/nagios-plugins-1.4.16 + cp -pr ChangeLog command.cfg /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/share/doc/nagios-plugins-1.4.16 + exit 0 RPM build errors: File not found: /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/lib/nagios/plugins/libnpcommon.a Thanks. Ruslan -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at cis.fu-berlin.de Thu Jun 6 09:43:15 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 6 Jun 2013 09:43:15 +0200 Subject: [Nagiosplug-devel] rpmbuild of latest nagios-plugins fails In-Reply-To: References: Message-ID: <20130606074315.GH3086@zedat.fu-berlin.de> * Ruslan Valiyev [2013-06-06 09:17]: > error: File not found: /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/lib/nagios/plugins/libnpcommon.a The culprit is probably commit eeca6e0f: https://github.com/nagios-plugins/nagios-plugins/commit/eeca6e0f05ce Does a plain "./configure && make" work on the same box? I'm I afraid I won't be of much help when it comes to the RPM-specific foo ... Holger From donkishoot at neuf.fr Thu Jun 6 13:50:44 2013 From: donkishoot at neuf.fr (DonKiShoot) Date: Thu, 06 Jun 2013 13:50:44 +0200 Subject: [Nagiosplug-devel] check_snmp bug on some strings Message-ID: <51B07794.8090809@neuf.fr> Hi list, check_snmp bug on some strings while snmpget has no problem Client version : net-snmp-5.3.2.2-20.el5 Server version : net-snmp-5.3.2.2-20.el5 To describe a minimum, i'm trying to retreive two oids. The first oid correspond to a number who represent the exit code from a command. The second oid correspond to the result string of the same command. For more information see 'extend' parameter from snmpd.conf Now the bug ... Example OK : /usr/lib64/nagios/plugins/check_snmp -H 192.168.1.1 -P 2c -C public -o .1.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101,.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1 -w 1 -c 2 SNMP CRITICAL - *3* "Usage: check_oracle --tns check_oracle --db check_oracle --login check_oracle --cache check_oracle --tablespace check_oracle --oranames check_oracle --help check_oracle --version" | iso.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101=3 Example KO : /usr/lib64/nagios/plugins/check_snmp -H 192.168.1.1 -P 2c -C public -o .1.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101,.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1 -w 1 -c 2 SNMP WARNING - *2* 43 52 49 54 49 43 41 4C 20 2D 20 4F 52 41 2D 31| iso.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101=2 iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1=43 check_snmp return hexa characters "43 52 49 54 49 43 41 4C 20 2D 20 4F 52 41 2D 31 ..." instead of a string like on the first check With snmpget the string is ok : snmpget -v2c -c altaread 10.2.50.111 iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1 NET-SNMP-EXTEND-MIB::nsExtendOutLine."TableSpace".1 = STRING: CRITICAL - ORA-12154: TNS : l'identificateur de connexion indiqu? n'a pas pu ?tre r?solu What can i do to receive the string instead of Hexa characters ??? PS: Sorry for my poor english Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxoid at gmail.com Mon Jun 10 17:26:28 2013 From: linuxoid at gmail.com (Ruslan Valiyev) Date: Mon, 10 Jun 2013 17:26:28 +0200 Subject: [Nagiosplug-devel] rpmbuild of latest nagios-plugins fails In-Reply-To: <20130606074315.GH3086@zedat.fu-berlin.de> References: <20130606074315.GH3086@zedat.fu-berlin.de> Message-ID: <602F35C6-0197-43B8-A836-FDF696AA7BD9@gmail.com> Thank you for your reply and sorry for the late answer. Manual configure && make works without errors. Ruslan On Jun 6, 2013, at 9:43 AM, Holger Wei? wrote: > * Ruslan Valiyev [2013-06-06 09:17]: >> error: File not found: /root/rpmbuild/BUILDROOT/nagios-plugins-1.4.16-1.x86_64/usr/lib/nagios/plugins/libnpcommon.a > > The culprit is probably commit eeca6e0f: > > https://github.com/nagios-plugins/nagios-plugins/commit/eeca6e0f05ce > > Does a plain "./configure && make" work on the same box? I'm I afraid I > won't be of much help when it comes to the RPM-specific foo ... > > Holger > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From rummandba at gmail.com Fri Jun 14 23:06:05 2013 From: rummandba at gmail.com (AI Rumman) Date: Fri, 14 Jun 2013 17:06:05 -0400 Subject: [Nagiosplug-devel] nagios plugin for postgresql unused db Message-ID: Hi, I created a nagios plugin to check-postgres-unused-db. http://www.rummandba.com/2013/06/nagios-script-to-find-unused-databases.html May I add it to "http://nagiosplugins.org/mailinglists"? Please let me know. Thanks, AI -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at leibzon.org Fri Jun 14 23:09:13 2013 From: william at leibzon.org (William Leibzon) Date: Fri, 14 Jun 2013 14:09:13 -0700 Subject: [Nagiosplug-devel] nagios plugin for postgresql unused db In-Reply-To: References: Message-ID: Upload it to exchange.nagios.org On Fri, Jun 14, 2013 at 2:06 PM, AI Rumman wrote: > Hi, > > I created a nagios plugin to check-postgres-unused-db. > http://www.rummandba.com/2013/06/nagios-script-to-find-unused-databases.html > > May I add it to "http://nagiosplugins.org/mailinglists"? > Please let me know. > > Thanks, > AI > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From noreply at sourceforge.net Tue Jun 18 17:40:50 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jun 2013 08:40:50 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3314686 ] check_ntp_time and check_ntp_peers cannot find offset Message-ID: Bugs item #3314686, was opened at 2011-06-10 05:56 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&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-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Douglas E. Warner (silfreed) >Assigned to: Holger Weiss (hweiss) Summary: check_ntp_time and check_ntp_peers cannot find offset Initial Comment: I'm having a similar problem with the "offset unknown" that others have had in the past, although I'm running 1.4.14 of the plugins using check_ntp_time and check_ntp_peer. Below is the output of some of the commands. For some reason check_ntp_peer doesn't even seem to be able to find the peers, although check_ntp_time seems fine, but doesn't get the correct offset. # ntpdc -n -s localhost remote local st poll reach delay offset disp ======================================================================= 208.53.158.34 10.128.0.45 2 64 3 0.02493 -0.088040 1.98438 204.9.54.119 10.128.0.45 1 64 3 0.00943 -0.035220 1.98444 199.4.29.166 10.128.0.45 2 64 3 0.02950 -0.021567 1.98444 216.129.110.22 10.128.0.45 2 64 3 0.01813 -0.027695 1.98444 # /usr/lib/nagios/plugins/check_ntp_peer -H 127.0.0.1 -w 5 -c 10 -v 0 candiate peers available warning: no synchronization source found warning: LI_ALARM bit is set NTP CRITICAL: Server not synchronized, Offset unknown| # /usr/lib/nagios/plugins/check_ntp_time -H 127.0.0.1 -w 5 -c 10 -v sending request to peer 0 response from peer 0: offset 2.74181366e-06 sending request to peer 0 response from peer 0: offset -4.291534424e-06 sending request to peer 0 response from peer 0: offset -3.457069397e-06 sending request to peer 0 response from peer 0: offset -3.576278687e-06 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-05-21 22:32 Message: Any progress on this one? I have the latest plugin, yet the problem is still there. ---------------------------------------------------------------------- Comment By: Douglas E. Warner (silfreed) Date: 2011-06-27 10:57 Message: Confirmed this also exists w/ 1.4.15. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&group_id=29880 From rummandba at gmail.com Tue Jun 18 18:16:46 2013 From: rummandba at gmail.com (AI Rumman) Date: Tue, 18 Jun 2013 12:16:46 -0400 Subject: [Nagiosplug-devel] nagios plugin for postgresql unused db In-Reply-To: References: Message-ID: Hi, I submit the project in Nagios Exhcange Postgresql plugin department. This is the first plugin I submitted. Please let me know if I follow all the guidelines. If not, I'll do the required modifications to be a part of such wonderful project. Thanks. On Fri, Jun 14, 2013 at 5:09 PM, William Leibzon wrote: > Upload it to exchange.nagios.org > > On Fri, Jun 14, 2013 at 2:06 PM, AI Rumman wrote: > > Hi, > > > > I created a nagios plugin to check-postgres-unused-db. > > > http://www.rummandba.com/2013/06/nagios-script-to-find-unused-databases.html > > > > May I add it to "http://nagiosplugins.org/mailinglists"? > > Please let me know. > > > > Thanks, > > AI > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________________ > > Nagios Plugin Development Mailing List > > Nagiosplug-devel at lists.sourceforge.net > > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Jun 19 10:23:40 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Jun 2013 01:23:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3314686 ] check_ntp_time and check_ntp_peers cannot find offset Message-ID: Bugs item #3314686, was opened at 2011-06-10 05:56 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&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-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Douglas E. Warner (silfreed) Assigned to: Holger Weiss (hweiss) Summary: check_ntp_time and check_ntp_peers cannot find offset Initial Comment: I'm having a similar problem with the "offset unknown" that others have had in the past, although I'm running 1.4.14 of the plugins using check_ntp_time and check_ntp_peer. Below is the output of some of the commands. For some reason check_ntp_peer doesn't even seem to be able to find the peers, although check_ntp_time seems fine, but doesn't get the correct offset. # ntpdc -n -s localhost remote local st poll reach delay offset disp ======================================================================= 208.53.158.34 10.128.0.45 2 64 3 0.02493 -0.088040 1.98438 204.9.54.119 10.128.0.45 1 64 3 0.00943 -0.035220 1.98444 199.4.29.166 10.128.0.45 2 64 3 0.02950 -0.021567 1.98444 216.129.110.22 10.128.0.45 2 64 3 0.01813 -0.027695 1.98444 # /usr/lib/nagios/plugins/check_ntp_peer -H 127.0.0.1 -w 5 -c 10 -v 0 candiate peers available warning: no synchronization source found warning: LI_ALARM bit is set NTP CRITICAL: Server not synchronized, Offset unknown| # /usr/lib/nagios/plugins/check_ntp_time -H 127.0.0.1 -w 5 -c 10 -v sending request to peer 0 response from peer 0: offset 2.74181366e-06 sending request to peer 0 response from peer 0: offset -4.291534424e-06 sending request to peer 0 response from peer 0: offset -3.457069397e-06 sending request to peer 0 response from peer 0: offset -3.576278687e-06 discarding peer 0: stratum=0 overall average offset: 0 NTP CRITICAL: Offset unknown| ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-06-19 01:23 Message: Sorry for the late response, Could you please run "ntpq -c rv" when this happens and post the output? ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2012-05-21 22:32 Message: Any progress on this one? I have the latest plugin, yet the problem is still there. ---------------------------------------------------------------------- Comment By: Douglas E. Warner (silfreed) Date: 2011-06-27 10:57 Message: Confirmed this also exists w/ 1.4.15. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3314686&group_id=29880 From alex.hha at gmail.com Mon Jun 24 13:17:59 2013 From: alex.hha at gmail.com (Alex Domoradov) Date: Mon, 24 Jun 2013 14:17:59 +0300 Subject: [Nagiosplug-devel] smart check_ping Message-ID: Hello all, is it possible to add interface name to the command check_ping? It's will be very useful on system with multiple network interfaces. Something like $ check_ping -H 8.8.8.8 -w 50,20% -c 100,40% -I xxx.xxx.xxx.xxx From holger at cis.fu-berlin.de Mon Jun 24 13:42:45 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Mon, 24 Jun 2013 13:42:45 +0200 Subject: [Nagiosplug-devel] smart check_ping In-Reply-To: References: Message-ID: <20130624114245.GA3795@zedat.fu-berlin.de> * Alex Domoradov [2013-06-24 14:17]: > is it possible to add interface name to the command check_ping? FWIW, you can specify the source IP address (or interface) when using check_icmp instead of check_ping. Holger From noreply at sourceforge.net Tue Jun 25 15:25:58 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jun 2013 06:25:58 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1614553 ] no perf-data check_apt Message-ID: Patches item #1614553, was opened at 2006-12-12 23:16 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614553&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: Accepted Priority: 5 Private: No Submitted By: FliTTi (flitti) Assigned to: Nobody/Anonymous (nobody) Summary: no perf-data check_apt Initial Comment: The plugin check_apt doens't return perfdata. This patch will enable perf data. Please put it into the next release. Best regards, FliTTi ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-06-25 06:25 Message: Sorry for the long delay, The patch is now in Git, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1614553&group_id=29880 From noreply at sourceforge.net Tue Jun 25 21:16:52 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jun 2013 12:16:52 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3614581 ] check_http.c does not compile without SSL Message-ID: Patches item #3614581, was opened at 2013-06-25 12:16 Message generated for change (Tracker Item Submitted) made by lorens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3614581&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: release-1.4.16 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lorens Kockum (lorens) Assigned to: Nobody/Anonymous (nobody) Summary: check_http.c does not compile without SSL Initial Comment: The ssl_version variable is defined inside the HAVE_SSL define, but it is referenced outside, and so the code does not compile in the absence of of an ssl library even if configure correctly concludes that no ssl library is present. The patch is trivial. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3614581&group_id=29880 From noreply at sourceforge.net Tue Jun 25 21:24:50 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jun 2013 12:24:50 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3614581 ] check_http.c does not compile without SSL Message-ID: Patches item #3614581, was opened at 2013-06-25 12:16 Message generated for change (Comment added) made by lorens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3614581&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: release-1.4.16 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Lorens Kockum (lorens) Assigned to: Nobody/Anonymous (nobody) Summary: check_http.c does not compile without SSL Initial Comment: The ssl_version variable is defined inside the HAVE_SSL define, but it is referenced outside, and so the code does not compile in the absence of of an ssl library even if configure correctly concludes that no ssl library is present. The patch is trivial. ---------------------------------------------------------------------- >Comment By: Lorens Kockum (lorens) Date: 2013-06-25 12:24 Message: Sorry, I see it was corrected in git 11 months ago ---------------------------------------------------------------------- Comment By: Lorens Kockum (lorens) Date: 2013-06-25 12:24 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3614581&group_id=29880 From noreply at sourceforge.net Fri Jun 28 15:06:14 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jun 2013 06:06:14 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614595 ] check_apt fails to see security updates as critical on Ubunt Message-ID: Bugs item #3614595, was opened at 2013-06-28 06:06 Message generated for change (Tracker Item Submitted) made by rbasak2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614595&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: Robie Basak (rbasak2) Assigned to: Nobody/Anonymous (nobody) Summary: check_apt fails to see security updates as critical on Ubunt Initial Comment: Downstream bug: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1031680 A combination of: 1) check_apt's approach to run an apt-get simulation 2) check_apt's approach to parse the apt-get simulation output to detect critical updates 3) Ubuntu placing security updates in the -updates pocket as well Means that if apt-get chooses, in its simulation, to download a security update from -updates and not -security, then this is correct behaviour for apt (the security update will still be applied) but check_apt will not detect the update as critical from the upgrade simulation. IMHO, check_apt is taking the wrong approach to detect critical updates here. Parsing apt-get is fragile, and is broken in this case. Instead, in an ideal world it would be able to examine the apt cache programmatically. I realise that this may not have been possible at the time that check_apt was written. On Ubuntu, it is necessary for the desktop to prompt the user too, so there is an infrastructure for this now. If you run /usr/lib/update-notifier/apt-check, then you'll get an output like "419;0" - on my system this is telling me that I have 419 normal updates, and 0 security updates. I suggest that if /usr/lib/update-notifier/apt-check exists then you should use this instead. This will hook into the same infrastructure that the server MOTD and the Ubuntu Desktop use for security updates, so should remain reliable. On both Ubuntu Server and Ubuntu Desktop, update-notifier-common provides /usr/lib/update-notifier/apt-check and is installed by default now. I think it would be sufficient for the nagios-plugins package to Recommend the update-notifier-common package for other users. If you check that /usr/lib/update-notifier/apt-check exists before using it, and falling back to the existing behaviour if it doesn't exist, then it shouldn't anyone who doesn't have it installed. An alternative method might be to run "apt-cache policy" for every package that you detected was downloaded in the simulation, and checking if it is available from a security repository. It looks like "apt-cache policy" will handle multiple packages at once, so this would work, but is just as fragile as the parsing of apt-get's output was in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614595&group_id=29880 From noreply at sourceforge.net Fri Jun 28 15:12:01 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jun 2013 06:12:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614595 ] check_apt fails to see security updates as critical on Ubunt Message-ID: Bugs item #3614595, was opened at 2013-06-28 06:06 Message generated for change (Comment added) made by rbasak2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614595&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: Robie Basak (rbasak2) Assigned to: Nobody/Anonymous (nobody) Summary: check_apt fails to see security updates as critical on Ubunt Initial Comment: Downstream bug: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1031680 A combination of: 1) check_apt's approach to run an apt-get simulation 2) check_apt's approach to parse the apt-get simulation output to detect critical updates 3) Ubuntu placing security updates in the -updates pocket as well Means that if apt-get chooses, in its simulation, to download a security update from -updates and not -security, then this is correct behaviour for apt (the security update will still be applied) but check_apt will not detect the update as critical from the upgrade simulation. IMHO, check_apt is taking the wrong approach to detect critical updates here. Parsing apt-get is fragile, and is broken in this case. Instead, in an ideal world it would be able to examine the apt cache programmatically. I realise that this may not have been possible at the time that check_apt was written. On Ubuntu, it is necessary for the desktop to prompt the user too, so there is an infrastructure for this now. If you run /usr/lib/update-notifier/apt-check, then you'll get an output like "419;0" - on my system this is telling me that I have 419 normal updates, and 0 security updates. I suggest that if /usr/lib/update-notifier/apt-check exists then you should use this instead. This will hook into the same infrastructure that the server MOTD and the Ubuntu Desktop use for security updates, so should remain reliable. On both Ubuntu Server and Ubuntu Desktop, update-notifier-common provides /usr/lib/update-notifier/apt-check and is installed by default now. I think it would be sufficient for the nagios-plugins package to Recommend the update-notifier-common package for other users. If you check that /usr/lib/update-notifier/apt-check exists before using it, and falling back to the existing behaviour if it doesn't exist, then it shouldn't anyone who doesn't have it installed. An alternative method might be to run "apt-cache policy" for every package that you detected was downloaded in the simulation, and checking if it is available from a security repository. It looks like "apt-cache policy" will handle multiple packages at once, so this would work, but is just as fragile as the parsing of apt-get's output was in the first place. ---------------------------------------------------------------------- >Comment By: Robie Basak (rbasak2) Date: 2013-06-28 06:12 Message: Alternatively, how about an entirely separate plugin that just calls /usr/lib/update-notifier/apt-check? That could be the easiest path forward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614595&group_id=29880 From massimiliano.ziccardi at gmail.com Fri Jun 28 18:17:07 2013 From: massimiliano.ziccardi at gmail.com (Massimiliano Ziccardi) Date: Fri, 28 Jun 2013 18:17:07 +0200 Subject: [Nagiosplug-devel] Nagios and JAVA plugins In-Reply-To: References: Message-ID: Hi Palli. Thank you for your suggestion. I followed your suggestion and implemented the threshold evaluation in both way. Now JNRPE plugins can easily support both the 'legacy' and the new specification format (even together). Since the new threshold format is very descriptive, the plugin developer do not need to write any code to support it; gathering the metric is enough: the evaluation is done by the JNRPE library. Thank you again, Massimiliano On Tue, May 28, 2013 at 1:19 PM, P?ll Gu?j?n Sigur?sson wrote: > My two cents, > > The new_threshold_syntax is just a proposal. And to my knowledge no one is > working on making it 'official'. We support the new syntax for the new > syntax, but the legacy (and inferior) syntax is currently our main one. > > Note, however that they are not mutually exclusive. You can have your > plugins understand both :) > > Cheers, > Palli > > > ----- Original Message ----- > From: "Massimiliano Ziccardi" > To: nagiosplug-devel at lists.sourceforge.net > Sent: Tuesday, May 28, 2013 9:53:57 AM > Subject: [Nagiosplug-devel] Nagios and JAVA plugins > > > > Hi all. > > > I write here to ask you all for a suggestion. Some year ago I started an > open source project called JNRPE ( http://jnrpe.sourceforge.net ) that > allows to easily write Nagios plugins using JAVA and is fully compatible > with check_nrpe. > > > JNRPE is bundled with some plugin : at the moment all the plugins use the > old range format ([@]start:end). > > > Since I'm in the process of releasing version 2.x, my question is: do you > think it would be better to keep using the old range format or would be > better to use the new threshold specification ( > http://nagiosplugins.org/rfc/new_threshold_syntax )? > > > I've already implemented all the classes needed to parse the new syntax, > but I'm not sure that it would be a good idea (most Nagios plugin uses the > old format and I didn't want to diverge too much!). > > > Thank you, > Massimiliano > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________________ > Nagios Plugin Development Mailing List > Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at leibzon.org Fri Jun 28 20:24:35 2013 From: william at leibzon.org (William Leibzon) Date: Fri, 28 Jun 2013 11:24:35 -0700 Subject: [Nagiosplug-devel] Nagios and JAVA plugins In-Reply-To: References: Message-ID: > Since I'm in the process of releasing version 2.x, my question is: do you think it would be better to keep using the old range format or would be better to use the new threshold specification ( http://nagiosplugins.org/rfc/new_threshold_syntax )? The library I'm slowly working on (https://github.com/willixix/WL-NagiosPlugins/blob/master/Naglio.pm) which is currently incorporated inside check_memcached.pl and check_redis.pl plugins is using the following syntax for long options for thresholds: --option=WARN:threshold,CRIT:threshold,ABSENT:OK|WARNING|CRITICAL|UNKNOWN,DISPLAY:YES|NO,PERF:YES|NO And it supports few other keywords too - ZERO:OK|WARNING|CRITICAL,NAME:string,PATTERN:string,UOM:char The meanings are: ABSENT specifies if there should be alert at the absence of what you're checking for (i.e. specified network interface does not exist on a device), ZERO is special case when result is numerical 0 (common enough special case), DISPLAY tells if the data should be in included in nagios status line output and PERF if it should be included in performance output. UOM is symbol to be added at the end of perf output ('c' or '%'), NAME allows to specify custom name for perfout and PATTERN only has meaning for my library (used for regex matching of data as I allow to specify one option that would match multiple data). I added all of that entirely independent of the nagiosplugins proposal but it seems similar and compatible. My library does not entirely support proposed syntax as it doesn't understand 'inf' and doesn't allow multiple WARN, CRIT and doesn't support 'OK'. But I'll probably extend it to support all that as it seems simple enough to add given what I've already written to support and parse this. And perhaps my special keywords (ABSENT, DISPLAY, PERF) should be considered or inclusion into proposed syntax. William From noreply at sourceforge.net Fri Jun 28 20:54:09 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jun 2013 11:54:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614595 ] check_apt fails to see security updates as critical on Ubunt Message-ID: Bugs item #3614595, was opened at 2013-06-28 06:06 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614595&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: Robie Basak (rbasak2) Assigned to: Nobody/Anonymous (nobody) Summary: check_apt fails to see security updates as critical on Ubunt Initial Comment: Downstream bug: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1031680 A combination of: 1) check_apt's approach to run an apt-get simulation 2) check_apt's approach to parse the apt-get simulation output to detect critical updates 3) Ubuntu placing security updates in the -updates pocket as well Means that if apt-get chooses, in its simulation, to download a security update from -updates and not -security, then this is correct behaviour for apt (the security update will still be applied) but check_apt will not detect the update as critical from the upgrade simulation. IMHO, check_apt is taking the wrong approach to detect critical updates here. Parsing apt-get is fragile, and is broken in this case. Instead, in an ideal world it would be able to examine the apt cache programmatically. I realise that this may not have been possible at the time that check_apt was written. On Ubuntu, it is necessary for the desktop to prompt the user too, so there is an infrastructure for this now. If you run /usr/lib/update-notifier/apt-check, then you'll get an output like "419;0" - on my system this is telling me that I have 419 normal updates, and 0 security updates. I suggest that if /usr/lib/update-notifier/apt-check exists then you should use this instead. This will hook into the same infrastructure that the server MOTD and the Ubuntu Desktop use for security updates, so should remain reliable. On both Ubuntu Server and Ubuntu Desktop, update-notifier-common provides /usr/lib/update-notifier/apt-check and is installed by default now. I think it would be sufficient for the nagios-plugins package to Recommend the update-notifier-common package for other users. If you check that /usr/lib/update-notifier/apt-check exists before using it, and falling back to the existing behaviour if it doesn't exist, then it shouldn't anyone who doesn't have it installed. An alternative method might be to run "apt-cache policy" for every package that you detected was downloaded in the simulation, and checking if it is available from a security repository. It looks like "apt-cache policy" will handle multiple packages at once, so this would work, but is just as fragile as the parsing of apt-get's output was in the first place. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-06-28 11:54 Message: I agree with your stance on parsing apt-get output, and I'd love to see a replacement that does the job using an APT API. I'm less keen on having the behaviour depend on whether or not some tool is available, though; as that's problematic with respect to maintenance and support. And I guess update-notifier is a bit too Ubuntu-ish to add a hard dependency on apt-check ... ---------------------------------------------------------------------- Comment By: Robie Basak (rbasak2) Date: 2013-06-28 06:12 Message: Alternatively, how about an entirely separate plugin that just calls /usr/lib/update-notifier/apt-check? That could be the easiest path forward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614595&group_id=29880 From william at leibzon.org Sat Jun 29 13:11:21 2013 From: william at leibzon.org (William Leibzon) Date: Sat, 29 Jun 2013 04:11:21 -0700 Subject: [Nagiosplug-devel] New Threshold Syntax Message-ID: The current proposal for new syntax is at http://nagiosplugins.org/rfc/new_threshold_syntax I'd like to make some extensions to it before implementing this in the library I'm working on (https://github.com/willixix/WL-NagiosPlugins/blob/master/Naglio.pm). And it seems coordination is indeed needed as we have at least 3 different people willing to use this or alike syntax in entirely independent implementations in different languages (C,Perl, Java). The proposed additions I'd like to have discussed are: 1) Extending WARN and CRIT to have special specifiers so that multiple types of thresholds for same metric could be specified together. One use I'd have of this is "rate" of change which my library currently implements as a "virtual" metric (name is suffixed as -rate). Also it' be used at some distance future for check_netint to allow combined thresholds based on traffic as percent as interface speed, based on long average and based on total, etc. And I think there are many other applications where one metric could have different types of thresholds. The proposed optional extended format would be: WARN=[specifier:]threshold Example would be: --threshold METRIC=evictions,WARN=rate:2..9,CRIT=rate:10..inf 2) Allow ":" to be used in place and equivalent to "'=" with preference that both are supported by libraries. This character ":" is what my library use to separate "CRIT" from numeric level. The reason I chose is that long options to commands are often specified in unix as "--option=data". This makes for a few issues when using external libraries for processing options if the data were to have "=". The proposal would therefore be to consider: --threshold METRIC:errors,WARN:2..5,CRIT:6..inf --threshold METRIC:evictions,WARN:rate:2..9,CRIT:rate:10..inf as equivalent to --threshold METRIC=errors,WARN=2..5,CRIT=6..inf --threshold METRIC=evictions,WARN=rate:2..9,CRIT=rate:10..inf 3) As you probably noticed I prefer upper case for keywords like WARN, CRIT. I want to make certain plugin writers know these are case-insensitive and both lowercase and upper case are to be supported. 4) I've used a few additional keywords in my implementation that I think would be useful to make part of the spec: ABSENT=OK|WARNING|CRITICAL|UNKNOWN this specifies type of alert and exit code if metric is not available at all on the device. often plugin writers chose to exist with UNKNOWN but people maybe ok with it or want CRITICAL. this would override default plugin behavior DISPLAY=YES|NO or STATUS=YES|NO this specifies if metric and data should be added to plugiin status output. overrides default plugin behavior if any PERF=YES|NO this specifies if metric data should be part of performance data. overrides default plugin behavior if any 5) Currently CRIT and WARN threshold levels are added to perf output so that these could be displayed on a graph. i.e. load_1_min=5.17;20;30 load_5_min=5.37;18;24 load_15_min=5.79;16;20 The problem is going to be how to add this for our new syntax that allows multiple WARN and CRIT and complex ranges. My proposal is that if it is possible to translate new threshold range to old format that is to be done i.e warn=5..inf is just 5. For cases where translation to something simple is not possible the syntax or perf output is extended to be: 'label'=value[UOM];[warn threshold if single value only];[crit threshold if single value only];[min];[max];[warn ranges];[crit ranges];[ok ranges] where multiple WARN and CRIT ranges are to be specified as a list start..end,start..end and -inf and inf are just not specified i.e. -inf..5 becomes ..5 and 5..inf is 5.. or just 5 Additionally I'd like to reserve a special UOM string of NOGRAPH for what is put in performance data but is not expected to be automatically graphed. Graphing programs are to ignore everything after that. That is all for my proposed extensions. Hopefully we can have some comments on this now. William From Stephan at quantentunnel.de Sat Jun 29 15:14:11 2013 From: Stephan at quantentunnel.de (Stephan) Date: Sat, 29 Jun 2013 15:14:11 +0200 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: References: Message-ID: <51CEDDA3.6020406@quantentunnel.de> Am 29.06.13 13:11, schrieb William Leibzon: > The current proposal for new syntax is at > http://nagiosplugins.org/rfc/new_threshold_syntax I'd like to add to this: > Complex range > endpoints are excluded from the range if () are used, otherwise endpoints are included in the range Why not use the "mathematical syntax"? For this we need [] instead of () Examples: [1..5] means 1 ? x ? 5 [1..5[ means 1 ? x < 5 ]1..5] means 1 < x ? 5 ]1..5[ means 1 < x < 5 And instead of specifying ^ before the bracket, let's put it inside like we have it in regular expression ranges: [^1..5] means x < 1 or x > 5 [^1..5[ means x < 1 or x ? 5 ]^1..5] means x ? 1 or x > 5 ]^1..5[ means x ? 1 or x ? 5 From Stephan at quantentunnel.de Sat Jun 29 22:10:32 2013 From: Stephan at quantentunnel.de (Stephan) Date: Sat, 29 Jun 2013 22:10:32 +0200 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: <51CEDDA3.6020406@quantentunnel.de> References: <51CEDDA3.6020406@quantentunnel.de> Message-ID: <51CF3F38.2050100@quantentunnel.de> Strange? Somehow I got superscripted ones. Anyhow? I found a link describing the notation: https://en.wikipedia.org/wiki/Interval_(mathematics) Am 29.06.13 15:14, schrieb Stephan: > Am 29.06.13 13:11, schrieb William Leibzon: >> The current proposal for new syntax is at >> http://nagiosplugins.org/rfc/new_threshold_syntax > I'd like to add to this: > >> Complex range >> endpoints are excluded from the range if () are used, otherwise > endpoints are included in the range > > Why not use the "mathematical syntax"? For this we need [] instead of () > > Examples: > [1..5] means 1 ? x ? 5 > [1..5[ means 1 ? x < 5 > ]1..5] means 1 < x ? 5 > ]1..5[ means 1 < x < 5 > And instead of specifying ^ before the bracket, let's put it inside like > we have it in regular expression ranges: > [^1..5] means x < 1 or x > 5 > [^1..5[ means x < 1 or x ? 5 > ]^1..5] means x ? 1 or x > 5 > ]^1..5[ means x ? 1 or x ? 5 > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From Jochen.Bern at LINworks.de Sun Jun 30 19:08:59 2013 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Sun, 30 Jun 2013 19:08:59 +0200 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: <51CF3F38.2050100@quantentunnel.de> References: <51CEDDA3.6020406@quantentunnel.de> <51CF3F38.2050100@quantentunnel.de> Message-ID: <51D0662B.8070909@LINworks.de> On 29.06.2013 22:10, Stephan wrote: > Anyhow? I found a link describing the notation: > https://en.wikipedia.org/wiki/Interval_(mathematics) > > Am 29.06.13 15:14, schrieb Stephan: >> Am 29.06.13 13:11, schrieb William Leibzon: >>> The current proposal for new syntax is at >>> http://nagiosplugins.org/rfc/new_threshold_syntax >> I'd like to add to this: >> >>> Complex range >>> endpoints are excluded from the range if () are used, otherwise >> endpoints are included in the range >> >> Why not use the "mathematical syntax"? For this we need [] instead of () >> >> Examples: >> [1..5] means 1 ? x ? 5 >> [1..5[ means 1 ? x < 5 >> ]1..5] means 1 < x ? 5 >> ]1..5[ means 1 < x < 5 >> And instead of specifying ^ before the bracket, let's put it inside like >> we have it in regular expression ranges: >> [^1..5] means x < 1 or x > 5 >> [^1..5[ means x < 1 or x ? 5 >> ]^1..5] means x ? 1 or x > 5 >> ]^1..5[ means x ? 1 or x ? 5 Folks, you're spending a lot of mental effort over something that won't get you noticeable appreciation. The thing that will win users and other plugin authors over to a new syntax is not that it looks nicer or more similar to existing notation conventions in whatever field, it's that it allows them to do the things they need to do now and in the upcoming years and that they had to *hack* with the former standard. In other words, *functionality* (that the syntax is bound to have to adapt to to a certain degree, anyway). I the wrote the comment under http://nagiosplugins.org/rfc/new_threshold_syntax , and I'm *STILL* waiting for a check_disk (to reuse the example) that I can tell to consider the minfree part of the available diskspace for /var/log, but not /tmp, I'm *still* squinting at PNP graphs of its performance data to see the usage meander between a WARN and a MAX line that are two or three pixels apart because I can't tell check_disk to put the amount of *free* space into the perfdata instead, yadda yadda. And while we're on the subject of "proper" notation involving characters that *happen* to be special chars to 90+% of all shells out there, and since we're talking about providing a *library* to plugin authors: No amount of exegesis on the parameter syntax will ever solve as many problems as the simple sentence "for every valid option '--foo bar', the plugin will accept '--64-foo baz' and '--url-foo org' to the same effect, where 'baz'=base64('bar') and 'org'=urlencode('bar')." (Extra points to whoever manages to put matching *EN*coding functionality into transport-providing plugins like check_by_ssh. ;-) Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel