From egalstad at nagios.org Wed Jun 2 17:20:35 2010 From: egalstad at nagios.org (Ethan Galstad) Date: Wed, 02 Jun 2010 10:20:35 -0500 Subject: [Nagiosplug-devel] check_log patches Message-ID: <4C0676C3.3020702@nagios.org> Here's a patch from Chris Pepper for the check_log plugin that may be of interest. He asked that I forward the patch, as he isn't a subscriber. Best regards, - Ethan -------- Original Message -------- Subject: [Fwd: check_log syntax change?] --- check_log.sh 2008-11-30 16:23:18.000000000 -0500 +++ check_log.sh.pepper 2010-05-10 14:16:12.000000000 -0400 @@ -4,7 +4,7 @@ # Written by Ethan Galstad (nagios at nagios.org) # Last Modified: 07-31-1999 # -# Usage: ./check_log +# Usage: ./check_log -F -O -q # # Description: # @@ -29,14 +29,14 @@ # # If you use this plugin make sure to keep the following in mind: # -# 1. The "max_attempts" value for the service should be 1, as this -# will prevent Nagios from retrying the service check (the +# 1. The "max_check_attempts" value for the service should be 1, to +# prevent Nagios from retrying the service check (the # next time the check is run it will not produce the same results). # -# 2. The "notify_recovery" value for the service should be 0, so that -# Nagios does not notify you of "recoveries" for the check. Since -# pattern matches in the log file will only be reported once and not -# the next time, there will always be "recoveries" for the service, even +# 2. The "notification_options" value for the service must not include 'r', +# so Nagios does not notify you of "recoveries" for the check. Since +# pattern matches in the log file will only be reported once, +# the service would always appear to 'recover', even # though recoveries really don't apply to this type of check. # # 3. You *must* supply a different for each service that @@ -57,7 +57,7 @@ # Paths to commands used in this script. These # may have to be modified to match your system setup. -# TV: removed PATH restriction. Need to think more about what this means overall +# TV: removed PATH restriction. Need to think more about what this means overall. #PATH="" ECHO="/bin/echo" -------- Original Message -------- Subject: check_log syntax change? Date: Mon, 10 May 2010 12:21:16 -0400 From: Chris Pepper To: Ethan Galstad Ethan, I couldn't find a documentation web page for check_log, but the script contains this comment: > # Usage: ./check_log Unfortunately, that syntax doesn't actually work -- it requires -F -O & -q. The usage message needs an update, or (better) the program needs to understand the simpler syntax shown on the Usage line. Regards, Chris > -bash-3.2$ /usr/local/nagios/libexec/check_log /var/log/messages messages.cache WARN > Unknown argument: /var/log/messages > Usage: check_log -F logfile -O oldlog -q query > Usage: check_log --help > Usage: check_log --version > -bash-3.2$ /usr/local/nagios/libexec/check_log -F /var/log/messages -O messages.cache -q WARN > Log check data initialized... > -bash-3.2$ -- Chris Pepper: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_log.sh.pepper URL: From mikedawg at gmail.com Wed Jun 2 19:14:13 2010 From: mikedawg at gmail.com (Mike Harris) Date: Wed, 2 Jun 2010 10:14:13 -0700 Subject: [Nagiosplug-devel] Enhancement Request for check_http Message-ID: Enhancement Request for check_http I have an enhancement request for check_http. What I'm looking to do, is to a) View the https certificate (using the --ssl flag) on a server that is secured up to FIPS 140-2 compliance ; and or b) Verify that the server is running in FIPS 140-2 compliance; and or c) Have an additional flag to check for sslv2, sslv3, and/or tlsv1. The error I'm getting when I run the check_http --ssl -H localhost is stating that it can't connect to the SSL port: CRITICAL - Cannot make SSL connection 7422:error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message:s23_clnt.c:578: CRITICAL - Cannot retrieve server certificate. The problem is that the server is listening using TLSv1 only, and the script is unable to connect using TLSv1. Thanks -- Mike Harris From listen2007 at lantschner.name Wed Jun 9 13:19:15 2010 From: listen2007 at lantschner.name (Ingo Lantschner) Date: Wed, 09 Jun 2010 13:19:15 +0200 Subject: [Nagiosplug-devel] New specification method for thresholds - still a valid vison? In-Reply-To: <4BC56814.7010301@aei.ca> References: <4BC538AE.50900@lantschner.name> <4BC56814.7010301@aei.ca> Message-ID: <4C0F78B3.5090105@lantschner.name> Hi Thomas, I am again at the point where implementing this new format by writing a Perl module is an option. But I am stuck at this point: The perf-data will change in way, that is most likely not compatible with addons like PnP. Following an example: check_netapp.pl Usage (?) -o aggr --th metric=%,ok=0..70,warn=70..90 --th metric=GiB ==> OK ?. | aggr0=52%;0..70;?????? ^^^^^^^^^^^^^ here is the problem?!?!? instead of: check_netapp.pl Usage (?) -o aggr -w 70% -c 90% --perf_uom=GB ==> OK ?. | aggr0=52%;70;90 Any ideas how this can be solved? Thanks, Ingo Thomas Guyot-Sionnest schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 13/04/10 11:38 PM, Ingo Lantschner wrote: >> Hi, >> I am working on a quiet complex problem of a multiple-instance-check >> regarding the thresholds. (The complexity comes from the fact, that the >> thresholds are relative in % whereas the perfdata and thresholds in the >> perf-output are absolute values.) >> >> I started by programming around Nagios::Plugin::Threshold which now led >> to some thoughts about patching it. Then I found this document: >> >> http://nagiosplugins.org/rfc/new_threshold_syntax >> >> Although not being directly related to the concrete problem, it is >> addressing some important aspects of it. >> >> Is this still a valid vision? Are there any plans in enhancing >> Nagios::Plugin 0.33 into this direction? > > Absolutely. I think there may be some additional notes elsewhere but > this page explains is pretty much the plan. Now we'll need to start > coding this in C and Perl. > > Our development effort is led by volunteers so any help coding this will > be greatly appreciated... Further down the road the new thresholds > library should be part of official C an Perl libraries to make writing > plugins in both languages much easier. Those libraries will handle other > aspects like argument passing, output, etc. > > Thank you, > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFLxWgT6dZ+Kt5BchYRArcaAKD9QfdfIoWZirAbjp8nKBacNGo30wCfbZwJ > PjbGwqq2+ngKK2hF7DOXljQ= > =yshN > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________________ > 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 dermoth at aei.ca Wed Jun 9 13:51:03 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 09 Jun 2010 07:51:03 -0400 Subject: [Nagiosplug-devel] New specification method for thresholds - still a valid vison? In-Reply-To: <4C0F78B3.5090105@lantschner.name> References: <4BC538AE.50900@lantschner.name> <4BC56814.7010301@aei.ca> <4C0F78B3.5090105@lantschner.name> Message-ID: <4C0F8027.9080905@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-09 07:19 AM, Ingo Lantschner wrote: > > Hi Thomas, > I am again at the point where implementing this new format by writing a > Perl module is an option. But I am stuck at this point: > > The perf-data will change in way, that is most likely not compatible > with addons like PnP. > > Following an example: > > check_netapp.pl Usage (?) -o aggr --th metric=%,ok=0..70,warn=70..90 > --th metric=GiB > ==> OK ?. | aggr0=52%;0..70;?????? > ^^^^^^^^^^^^^ > here is the problem?!?!? > > instead of: > > check_netapp.pl Usage (?) -o aggr -w 70% -c 90% --perf_uom=GB > ==> OK ?. | aggr0=52%;70;90 > > Any ideas how this can be solved? Hi Ingo, The performance data will eventually have to change as even right now there isn't much flexibility to represent anything fancy even with the current thresholds. You can try to see what current plugins using standard perfdata functions return when specifying a full range and mimic that, or just leave the fields empty (i.e. aggr0=52%;;;) until a new format is used. Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwPgCEACgkQ6dZ+Kt5Bchb+FwCg3q8hddy1UllGSbq9W142NNLR nm8AniDpiTC4aVyWS5H0nCuqSyFnowqg =lGjB -----END PGP SIGNATURE----- From noreply at sourceforge.net Wed Jun 9 17:26:04 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jun 2010 15:26:04 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2999924 ] check_http: add search string into 'string not found' msg Message-ID: Patches item #2999924, was opened at 2010-05-11 11:23 Message generated for change (Comment added) made by duncan_ferguson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2999924&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_http: add search string into 'string not found' msg Initial Comment: Is very useful to show the search string in the 'string not found' message when it isn't found in the web page. Patch attached to provide this functionality when using '-o' switch (so is backwards compatible). Patch is against git as of timestamp in patch. ---------------------------------------------------------------------- >Comment By: Duncan Ferguson (duncan_ferguson) Date: 2010-06-09 15:26 Message: Patch updated to include hostname and URL in 'string not found' message ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2999924&group_id=29880 From jdoeconsulting at gmail.com Sat Jun 12 14:02:00 2010 From: jdoeconsulting at gmail.com (John Doe) Date: Sat, 12 Jun 2010 14:02:00 +0200 Subject: [Nagiosplug-devel] RFE check_dig to support reverse lookups Message-ID: I'd really like to see check_dig support reverse lookups. That way I can guarantee my customers DNS are working 100% >From what I can tell from the documentation check_dig already in v 1.4.14 should be able to do reverse lookups as one can pass additional options with -A and specify the type PTR with -T. But I just can't get it to work. >From what I can find on the Internet, check_dig doesn't support reverse lookups? -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Jun 15 09:50:42 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Jun 2010 07:50:42 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3016334 ] check_mysql_query: No perfdata in output Message-ID: Bugs item #3016334, was opened at 2010-06-15 07:50 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3016334&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: check_mysql_query: No perfdata in output Initial Comment: The check_mysql_query plugin doesn't supply any perfdata, would be really nice to have for some graphing plugins that could get numbers automatically then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3016334&group_id=29880 From nagiosplug-devel at spidalinx.co.uk Tue Jun 15 11:39:56 2010 From: nagiosplug-devel at spidalinx.co.uk (William Preston) Date: Tue, 15 Jun 2010 11:39:56 +0200 Subject: [Nagiosplug-devel] Patch for check_http NTLM support References: <4648DCA6-14B6-4A57-B196-6A4D82A842A5@spidalinx.co.uk> Message-ID: <140B6D64-C5E2-43F3-8A20-FA83BF04EE1A@spidalinx.co.uk> Oh, there's a 40KB limit -> sending again, with the patches zipped... Begin forwarded message: > From: William Preston > Date: June 14, 2010 4:36:57 PM GMT+02:00 > To: nagiosplug-devel at lists.sourceforge.net > Subject: Patch for check_http NTLM support > > > Hi list, > > Here's a rather large patch we created to add support for NTLM authentication. > I'm sending it to the list because I know that many people have asked for NTLM support. > > * SSL Bug fixed > * Binary data supported > * Chunk support (1st chunk only) > * proxy on different port > * ntlm authentication for hosts / proxies > * Expected size logic fixed to work with -N > > > I've also included the small SSL fix as a separate standalone patch. > > > > William > -------------- next part -------------- A non-text attachment was scrubbed... Name: ntlm_patch.diff.gz Type: application/x-gzip Size: 13484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch1_ssl_fix.diff.gz Type: application/x-gzip Size: 1159 bytes Desc: not available URL: From tonvoon at gmail.com Wed Jun 16 17:29:08 2010 From: tonvoon at gmail.com (Ton Voon) Date: Wed, 16 Jun 2010 16:29:08 +0100 Subject: [Nagiosplug-devel] State retention functionality Message-ID: Hi! I have a need to enhance check_snmp to provide support for differences between counters and so I'm going to create some library functions for handling state between invocations of a plugin. I've been working with Holger on the design and we're happy with this: http://nagiosplugins.org/rfc/state_retention This is based on the email threads some time ago started by Alain. I've taken all the comments and tried to get something small and neat. Any comments welcome. I'm planning on starting to code this tomorrow. Ton From nagiosplug-devel at spidalinx.co.uk Wed Jun 16 18:27:48 2010 From: nagiosplug-devel at spidalinx.co.uk (William Preston) Date: Wed, 16 Jun 2010 18:27:48 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: References: Message-ID: On Jun 16, 2010, at 5:29 PM, Ton Voon wrote: > I have a need to enhance check_snmp to provide support for differences > between counters and so I'm going to create some library functions for > handling state between invocations of a plugin. I've been working with > Holger on the design and we're happy with this: > http://nagiosplugins.org/rfc/state_retention > > This is based on the email threads some time ago started by Alain. > I've taken all the comments and tried to get something small and neat. > > Any comments welcome. I'm planning on starting to code this tomorrow. I realise I've come a bit late to the party here, but have you considered memcached? It seems to me to be a tried and trusted mechanism that many admins are already familiar with, is distributed, cached, scaleable etc. And it should be less work to implement than building something new :-) William From holger at CIS.FU-Berlin.DE Wed Jun 16 19:16:38 2010 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Wed, 16 Jun 2010 19:16:38 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: References: Message-ID: <20100616171637.GF21104317@CIS.FU-Berlin.DE> * William Preston [2010-06-16 18:27]: > On Jun 16, 2010, at 5:29 PM, Ton Voon wrote: > > I have a need to enhance check_snmp to provide support for differences > > between counters and so I'm going to create some library functions for > > handling state between invocations of a plugin. I've been working with > > Holger on the design and we're happy with this: > > http://nagiosplugins.org/rfc/state_retention > > > > This is based on the email threads some time ago started by Alain. > > I've taken all the comments and tried to get something small and neat. > > > > Any comments welcome. I'm planning on starting to code this tomorrow. > > I realise I've come a bit late to the party here, but > have you considered memcached? > > It seems to me to be a tried and trusted mechanism that many > admins are already familiar with, is distributed, cached, scaleable etc. While I'm all for reusing code, memcached really solves a different problem. We just need a simple solution to store and retrieve trivial amounts of data in a specific way. Admins shouldn't be bothered with setting up and maintaining the storage at all. So a "distributed, cached, scaleable etc." client-server solution seems to be overkill to me. > And it should be less work to implement than building something new :-) In this case, I think the opposite is true. Holger From eduardowillame at yahoo.com.br Wed Jun 16 20:22:14 2010 From: eduardowillame at yahoo.com.br (Eduardo Willame (Valentim)) Date: Wed, 16 Jun 2010 11:22:14 -0700 (PDT) Subject: [Nagiosplug-devel] Enc: Suggest Improvement plugin "check_oracle" Message-ID: <403965.37492.qm@web52902.mail.re2.yahoo.com> Dear Dev Team, I have noticed that the plugin "check_oracle" on "nagios-plugins package" doesn't monitor Oracle Temporary Tablespaces and I put this resource on new script "check_oracle". Please consider this on future nagios-plugins releases, because it is very important for DBAs monitor Temporary Tablespaces TOO. Thanks, Eduardo Valentim DBA Oracle 10g Fortaleza-CE Brazil -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_oracle Type: application/octet-stream Size: 9156 bytes Desc: not available URL: From nagiosplug-devel at spidalinx.co.uk Wed Jun 16 20:53:31 2010 From: nagiosplug-devel at spidalinx.co.uk (William Preston) Date: Wed, 16 Jun 2010 20:53:31 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <20100616171637.GF21104317@CIS.FU-Berlin.DE> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> Message-ID: <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> On Jun 16, 2010, at 7:16 PM, Holger Wei? wrote: > While I'm all for reusing code, memcached really solves a different > problem. We just need a simple solution to store and retrieve trivial > amounts of data in a specific way. Admins shouldn't be bothered with > setting up and maintaining the storage at all. So a "distributed, > cached, scaleable etc." client-server solution seems to be overkill to > me. I think we may be coming at this from opposite ends of the spectrum! I'm thinking of large setups with hundreds of thousands of checks and clustered nagios servers. I suspect the DNX people would also have a problem with state data being stored on a particular node. The current solution of storing state data in the perfdata field and passing it as an option may not be pretty, but at least it works in such situations. Some concerns I have are; * Will you be supplying bindings for perl, shell, python etc.? * In what format will the data be stored? I'm not keen on binary data being stored without knowing if it is 32/64bit, big or little endian * Unique identifier: I would offer the user a key option (e.g. --statekey '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last resort because it may change with on-demand macros. * Performance -> file I/O is a problem in large setups * What about plugins that want to share state data? * Validity: I can think of a few situations where a check is costly and a cacheing mechanism with a "valid till" field would really help. Don't misunderstand me - I agree with you that we need this functionality - but I fear the "simple solution" may be worse than the current workaround using SERVICEPERFDATA. William From flyinvap at orange.fr Wed Jun 16 22:20:36 2010 From: flyinvap at orange.fr (Flyinvap) Date: Wed, 16 Jun 2010 22:20:36 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> Message-ID: <4C193214.1020608@orange.fr> Le 16/06/2010 20:53, William Preston a ?crit : > The current solution of storing state data in the perfdata field and passing it as > an option may not be pretty, but at least it works in such situations. I agree but you can always use that way ;-) > * Will you be supplying bindings for perl, shell, python etc.? Very important. > * Unique identifier: I would offer the user a key option (e.g. --statekey '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last resort because it may change with on-demand macros. Yes. > * Performance -> file I/O is a problem in large setups Nagios use too many I/O, with this system would not improve performance. We can always put thoses files in a ramdisk. > Don't misunderstand me - I agree with you that we need this functionality - but I fear > the "simple solution" may be worse than the current workaround using SERVICEPERFDATA. I agree. I use SERVICEPERFDATA because I do not have many plugins using it. In the futur I would try memcached for that, it's not too hard to install and maintain. -- Flyinvap From Matthias.Weiss at weiss-system.de Wed Jun 16 23:27:52 2010 From: Matthias.Weiss at weiss-system.de (Matthias =?ISO-8859-1?B?V2Vp3w==?=) Date: Wed, 16 Jun 2010 23:27:52 +0200 Subject: [Nagiosplug-devel] Nagiosplug-devel Digest, Vol 49, Issue 3 In-Reply-To: Message-ID: Am 16.06.10 22:36 schrieb "nagiosplug-devel-request at lists.sourceforge.net" unter : > Send Nagiosplug-devel mailing list submissions to > nagiosplug-devel at lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > or, via email, send a message with subject or body 'help' to > nagiosplug-devel-request at lists.sourceforge.net > > You can reach the person managing the list at > nagiosplug-devel-owner at lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nagiosplug-devel digest..." > > > Today's Topics: > > 1. Re: State retention functionality (William Preston) > 2. Re: State retention functionality (Holger Wei?) > 3. Enc: Suggest Improvement plugin "check_oracle" > (Eduardo Willame (Valentim)) > 4. Re: State retention functionality (William Preston) > 5. Re: State retention functionality (Flyinvap) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Jun 2010 18:27:48 +0200 > From: William Preston > Subject: Re: [Nagiosplug-devel] State retention functionality > To: Nagios Plugin Development Mailing List > > Message-ID: > Content-Type: text/plain; charset=us-ascii > > On Jun 16, 2010, at 5:29 PM, Ton Voon wrote: >> I have a need to enhance check_snmp to provide support for differences >> between counters and so I'm going to create some library functions for >> handling state between invocations of a plugin. I've been working with >> Holger on the design and we're happy with this: >> http://nagiosplugins.org/rfc/state_retention >> >> This is based on the email threads some time ago started by Alain. >> I've taken all the comments and tried to get something small and neat. >> >> Any comments welcome. I'm planning on starting to code this tomorrow. > > I realise I've come a bit late to the party here, but > have you considered memcached? > > It seems to me to be a tried and trusted mechanism that many > admins are already familiar with, is distributed, cached, scaleable etc. > And it should be less work to implement than building something new :-) > > William > > > > ------------------------------ > > Message: 2 > Date: Wed, 16 Jun 2010 19:16:38 +0200 > From: Holger Wei? > Subject: Re: [Nagiosplug-devel] State retention functionality > To: Nagios Plugin Development > Message-ID: <20100616171637.GF21104317 at CIS.FU-Berlin.DE> > Content-Type: text/plain; charset=us-ascii > > * William Preston [2010-06-16 18:27]: >> On Jun 16, 2010, at 5:29 PM, Ton Voon wrote: >>> I have a need to enhance check_snmp to provide support for differences >>> between counters and so I'm going to create some library functions for >>> handling state between invocations of a plugin. I've been working with >>> Holger on the design and we're happy with this: >>> http://nagiosplugins.org/rfc/state_retention >>> >>> This is based on the email threads some time ago started by Alain. >>> I've taken all the comments and tried to get something small and neat. >>> >>> Any comments welcome. I'm planning on starting to code this tomorrow. >> >> I realise I've come a bit late to the party here, but >> have you considered memcached? >> >> It seems to me to be a tried and trusted mechanism that many >> admins are already familiar with, is distributed, cached, scaleable etc. > > While I'm all for reusing code, memcached really solves a different > problem. We just need a simple solution to store and retrieve trivial > amounts of data in a specific way. Admins shouldn't be bothered with > setting up and maintaining the storage at all. So a "distributed, > cached, scaleable etc." client-server solution seems to be overkill to > me. > >> And it should be less work to implement than building something new :-) > > In this case, I think the opposite is true. > > Holger > > > > ------------------------------ > > Message: 3 > Date: Wed, 16 Jun 2010 11:22:14 -0700 (PDT) > From: "Eduardo Willame \(Valentim\)" > Subject: [Nagiosplug-devel] Enc: Suggest Improvement plugin > "check_oracle" > To: Nagios Development Team > Message-ID: <403965.37492.qm at web52902.mail.re2.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > Dear Dev Team, > > > I have noticed that the plugin "check_oracle" on "nagios-plugins package" > doesn't monitor Oracle Temporary Tablespaces and I put this resource on new > script "check_oracle". > > Please consider this on future nagios-plugins releases, because it is very > important for DBAs monitor Temporary Tablespaces TOO. Hi Eduardo, Check_oracle currently contains an function to monitor any tablespaces. In this case it should be also possible to check the temp tablespaces by it's name. Or do you need some additional data to be monitored? > > Thanks, > Eduardo Valentim > DBA Oracle 10g > > Fortaleza-CE > Brazil > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: check_oracle > Type: application/octet-stream > Size: 9156 bytes > Desc: not available > > ------------------------------ > > Message: 4 > Date: Wed, 16 Jun 2010 20:53:31 +0200 > From: William Preston > Subject: Re: [Nagiosplug-devel] State retention functionality > To: Nagios Plugin Development Mailing List > > Message-ID: <084EBE7B-107C-477F-9984-70153496F1D7 at spidalinx.co.uk> > Content-Type: text/plain; charset=iso-8859-1 > > > On Jun 16, 2010, at 7:16 PM, Holger Wei? wrote: >> While I'm all for reusing code, memcached really solves a different >> problem. We just need a simple solution to store and retrieve trivial >> amounts of data in a specific way. Admins shouldn't be bothered with >> setting up and maintaining the storage at all. So a "distributed, >> cached, scaleable etc." client-server solution seems to be overkill to >> me. > > I think we may be coming at this from opposite ends of the spectrum! > I'm thinking of large setups with hundreds of thousands of checks and > clustered > nagios servers. I suspect the DNX people would also have a problem with > state data being stored on a particular node. > > The current solution of storing state data in the perfdata field and passing > it as > an option may not be pretty, but at least it works in such situations. > > Some concerns I have are; > > * Will you be supplying bindings for perl, shell, python etc.? > * In what format will the data be stored? I'm not keen on binary data being > stored without > knowing if it is 32/64bit, big or little endian > * Unique identifier: I would offer the user a key option (e.g. --statekey > '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last resort because it may > change with on-demand macros. > * Performance -> file I/O is a problem in large setups > * What about plugins that want to share state data? > * Validity: I can think of a few situations where a check is costly and a > cacheing mechanism with a "valid till" field would really help. > > > Don't misunderstand me - I agree with you that we need this functionality - > but I fear > the "simple solution" may be worse than the current workaround using > SERVICEPERFDATA. > > William > > > ------------------------------ > > Message: 5 > Date: Wed, 16 Jun 2010 22:20:36 +0200 > From: Flyinvap > Subject: Re: [Nagiosplug-devel] State retention functionality > To: Nagios Plugin Development Mailing List > > Message-ID: <4C193214.1020608 at orange.fr> > Content-Type: text/plain; charset=ISO-8859-1 > > Le 16/06/2010 20:53, William Preston a ?crit : >> The current solution of storing state data in the perfdata field and > passing it as >> an option may not be pretty, but at least it works in such situations. > > I agree but you can always use that way ;-) > >> * Will you be supplying bindings for perl, shell, python etc.? > > Very important. > >> * Unique identifier: I would offer the user a key option (e.g. > --statekey '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last > resort because it may change with on-demand macros. > > Yes. > >> * Performance -> file I/O is a problem in large setups > > Nagios use too many I/O, with this system would not improve performance. > We can always put thoses files in a ramdisk. > >> Don't misunderstand me - I agree with you that we need this > functionality - but I fear >> the "simple solution" may be worse than the current workaround using > SERVICEPERFDATA. > > I agree. I use SERVICEPERFDATA because I do not have many plugins using > it. In the futur I would try memcached for that, it's not too hard to > install and maintain. From tonvoon at gmail.com Wed Jun 16 23:50:37 2010 From: tonvoon at gmail.com (Ton Voon) Date: Wed, 16 Jun 2010 22:50:37 +0100 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> Message-ID: <6FE9E3C3-F1A6-495B-9BF3-4F26D7FA4394@gmail.com> On 16 Jun 2010, at 19:53, William Preston wrote: > On Jun 16, 2010, at 7:16 PM, Holger Wei? wrote: >> While I'm all for reusing code, memcached really solves a different >> problem. We just need a simple solution to store and retrieve >> trivial >> amounts of data in a specific way. Admins shouldn't be bothered with >> setting up and maintaining the storage at all. So a "distributed, >> cached, scaleable etc." client-server solution seems to be overkill >> to >> me. > > I think we may be coming at this from opposite ends of the spectrum! > I'm thinking of large setups with hundreds of thousands of checks > and clustered > nagios servers. I suspect the DNX people would also have a problem > with > state data being stored on a particular node. > > The current solution of storing state data in the perfdata field and > passing it as > an option may not be pretty, but at least it works in such situations. I've said previously (http://article.gmane.org/gmane.network.nagios.plugins.devel/6819 ), the ideal is that Nagios is able to parse the performance data and thus calculate the thresholds and calculations can be done there. Good luck with that - I'm not planning on making a change of that magnitude to Nagios... > Some concerns I have are; > > * Will you be supplying bindings for perl, shell, python etc.? No. I'm only planning on creating C library routines. You're welcome to port to other libraries. My design is partly based on Nagios::Plugin::Differences, written by Jose Luis Martinez (http://article.gmane.org/gmane.network.nagios.plugins.devel/6787 ), so there is a perl counterpart. > * In what format will the data be stored? I'm not keen on binary > data being stored without > knowing if it is 32/64bit, big or little endian Binary is just that - I've stated the limitations. In fact, while I've considered it, I'm only going to implement string saves initially Bear in mind, this is really a simple way of saving some arbitrary information in a consistent location to calculate differences. Other people have rolled their own mechanisms - I'm just trying to find a way of creating an easily accessible, common routine. > * Unique identifier: I would offer the user a key option (e.g. -- > statekey '$HOSTNAME$/$SERVICEDESC$') and only use argv as a last > resort because it may change with on-demand macros. If you've changed the parameters to the plugin, then, with argv calculation, you'd lose one difference in value. I think that's probably acceptable? But --statekey is a good idea. I don't think I'll implement it, but I'd welcome patches to override the statekey. Ton From mostafa.altantawy at gmail.com Thu Jun 17 10:12:05 2010 From: mostafa.altantawy at gmail.com (mostafa altantawy) Date: Thu, 17 Jun 2010 11:12:05 +0300 Subject: [Nagiosplug-devel] asking about Radius check plugin Message-ID: Dear Sir, Actually i'm trying these days the nagios and it's doing just fine for me but i'm facing a problem regarding to using check radius . as i don't know where i can pass the macros variable like hostname ,username and this type of stuff . I have configured my cfg file with check command check_radius!'my radius server'!'username'!password adn iam getting Auth failed error at nagios . When running the command itself from the command line i got auth ok by passing the parameters explicitly it works for me and gives auth ok . So I need your help of how can i pass this parameters to the check command to make this works, Thanks in advance -- Mostafa Altantawy Network Security Engineer Vodafone Egypt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ae at op5.se Thu Jun 17 12:02:55 2010 From: ae at op5.se (Andreas Ericsson) Date: Thu, 17 Jun 2010 12:02:55 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <20100616171637.GF21104317@CIS.FU-Berlin.DE> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> Message-ID: <4C19F2CF.2010108@op5.se> On 06/16/2010 07:16 PM, Holger Wei? wrote: > * William Preston [2010-06-16 18:27]: >> On Jun 16, 2010, at 5:29 PM, Ton Voon wrote: >>> I have a need to enhance check_snmp to provide support for differences >>> between counters and so I'm going to create some library functions for >>> handling state between invocations of a plugin. I've been working with >>> Holger on the design and we're happy with this: >>> http://nagiosplugins.org/rfc/state_retention >>> >>> This is based on the email threads some time ago started by Alain. >>> I've taken all the comments and tried to get something small and neat. >>> >>> Any comments welcome. I'm planning on starting to code this tomorrow. >> >> I realise I've come a bit late to the party here, but >> have you considered memcached? >> >> It seems to me to be a tried and trusted mechanism that many >> admins are already familiar with, is distributed, cached, scaleable etc. > > While I'm all for reusing code, memcached really solves a different > problem. We just need a simple solution to store and retrieve trivial > amounts of data in a specific way. Admins shouldn't be bothered with > setting up and maintaining the storage at all. So a "distributed, > cached, scaleable etc." client-server solution seems to be overkill to > me. > >> And it should be less work to implement than building something new :-) > > In this case, I think the opposite is true. > Agreed. I've already implemented a state-retention thing for a latency checking plugin. Feel free to reuse it if you like. It's possibly overkill, but the library reading the state is very simple and extremely well-tested, as it's the preferred libraryfor all our (my) projects. It's not opaque, but that can be arranged if you like. The attached plugin should provide sufficient documentation in the form of examples. Btw, I really like the idea of using a hash of the argument list to provide the filename, but I'd use SHA1 if I were you. Not that speed is really all that much of an issue, but there's a very portable, fast and lightweight implementation of SHA1 in git, dubbed "block-sha1". It's easy to extract from there and re-use in other places. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_latency.tar.gz Type: application/x-gzip Size: 6452 bytes Desc: not available URL: From holger at CIS.FU-Berlin.DE Thu Jun 17 12:23:28 2010 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 17 Jun 2010 12:23:28 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> Message-ID: <20100617102328.GA61645@CIS.FU-Berlin.DE> * William Preston [2010-06-16 20:53]: > On Jun 16, 2010, at 7:16 PM, Holger Wei? wrote: > > While I'm all for reusing code, memcached really solves a different > > problem. We just need a simple solution to store and retrieve trivial > > amounts of data in a specific way. Admins shouldn't be bothered with > > setting up and maintaining the storage at all. So a "distributed, > > cached, scaleable etc." client-server solution seems to be overkill to > > me. > > I think we may be coming at this from opposite ends of the spectrum! > I'm thinking of large setups with hundreds of thousands of checks and clustered > nagios servers. If accessing the state data will ever become the bottleneck for such setups (which I doubt), we can easily implement additional storage backends in the future. > * Will you be supplying bindings for perl, shell, python etc.? Nothing prevents us from doing so in the future, I guess. But please note that we currently won't expose this stuff as an external API anyway. > * Unique identifier: I would offer the user a key option (e.g. --statekey '$HOSTNAME$/$SERVICEDESC$') Good idea. > Don't misunderstand me - I agree with you that we need this functionality - but I fear > the "simple solution" may be worse than the current workaround using SERVICEPERFDATA. So you would seriously force each and every user of our Plugins package to setup and maintain a full-blown, distributed client-server solution just in order to provide two or three plugins with a means of storing a few bytes of data? Jeez! We should try to make sure that the API won't get in the way of scalability, but we should keep the initial storage backend as simple as possible. Holger From perldork at webwizarddesign.com Thu Jun 17 13:39:16 2010 From: perldork at webwizarddesign.com (Max) Date: Thu, 17 Jun 2010 07:39:16 -0400 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <20100617102328.GA61645@CIS.FU-Berlin.DE> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> <20100617102328.GA61645@CIS.FU-Berlin.DE> Message-ID: We have been using memcached on our pollers for state retention and delta calculation with very good success - on one of our more active pollers several thousand of the active service checks it runs every 5 minutes use memcached for state. So while you might not like memcached it works quite well and scales well - never have we had to tune or tweak it to keep up with our systems as they have grown. It is zero maintenance as well. Max On 6/17/10, Holger Wei? wrote: > * William Preston [2010-06-16 20:53]: >> On Jun 16, 2010, at 7:16 PM, Holger Wei? wrote: >> > While I'm all for reusing code, memcached really solves a different >> > problem. We just need a simple solution to store and retrieve trivial >> > amounts of data in a specific way. Admins shouldn't be bothered with >> > setting up and maintaining the storage at all. So a "distributed, >> > cached, scaleable etc." client-server solution seems to be overkill to >> > me. >> >> I think we may be coming at this from opposite ends of the spectrum! >> I'm thinking of large setups with hundreds of thousands of checks and >> clustered >> nagios servers. > > If accessing the state data will ever become the bottleneck for such > setups (which I doubt), we can easily implement additional storage > backends in the future. > >> * Will you be supplying bindings for perl, shell, python etc.? > > Nothing prevents us from doing so in the future, I guess. But please > note that we currently won't expose this stuff as an external API > anyway. > >> * Unique identifier: I would offer the user a key option (e.g. --statekey >> '$HOSTNAME$/$SERVICEDESC$') > > Good idea. > >> Don't misunderstand me - I agree with you that we need this functionality >> - but I fear >> the "simple solution" may be worse than the current workaround using >> SERVICEPERFDATA. > > So you would seriously force each and every user of our Plugins package > to setup and maintain a full-blown, distributed client-server solution > just in order to provide two or three plugins with a means of storing a > few bytes of data? Jeez! > > We should try to make sure that the API won't get in the way of > scalability, but we should keep the initial storage backend as simple as > possible. > > Holger > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________________ > 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 holger at CIS.FU-Berlin.DE Thu Jun 17 13:54:27 2010 From: holger at CIS.FU-Berlin.DE (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 17 Jun 2010 13:54:27 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> <20100617102328.GA61645@CIS.FU-Berlin.DE> Message-ID: <20100617115427.GD61645@CIS.FU-Berlin.DE> * Max [2010-06-17 07:39]: > We have been using memcached on our pollers for state retention and > delta calculation with very good success - on one of our more active > pollers several thousand of the active service checks it runs every 5 > minutes use memcached for state. > > So while you might not like memcached it works quite well and scales > well I did not dispute that memcached works well, I said that it's overkill for the job at hand. Holger From perldork at webwizarddesign.com Thu Jun 17 14:06:05 2010 From: perldork at webwizarddesign.com (Max) Date: Thu, 17 Jun 2010 08:06:05 -0400 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: <20100617115427.GD61645@CIS.FU-Berlin.DE> References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> <20100617102328.GA61645@CIS.FU-Berlin.DE> <20100617115427.GD61645@CIS.FU-Berlin.DE> Message-ID: 2010/6/17 Holger Wei? : > * Max [2010-06-17 07:39]: >> We have been using memcached on our pollers for state retention and >> delta calculation with very good success - on one of our more active >> pollers several thousand of the active service checks it runs every 5 >> minutes use memcached for state. >> >> So while you might not like memcached it works quite well and scales >> well > > I did not dispute that memcached works well, I said that it's overkill > for the job at hand. And I would counter that installing an RPM / other binary package or building it from source and then running on Linux /sbin/service memcached start is pretty trivial. We have our memcached instances set to 60 MB (the default) and have never hit that limit. For an embedded platform running Nagios using memcached would be overkill and not the right choice. - Max From nagiosplug-devel at spidalinx.co.uk Thu Jun 17 15:20:17 2010 From: nagiosplug-devel at spidalinx.co.uk (William Preston) Date: Thu, 17 Jun 2010 15:20:17 +0200 Subject: [Nagiosplug-devel] State retention functionality In-Reply-To: References: <20100616171637.GF21104317@CIS.FU-Berlin.DE> <084EBE7B-107C-477F-9984-70153496F1D7@spidalinx.co.uk> <20100617102328.GA61645@CIS.FU-Berlin.DE> <20100617115427.GD61645@CIS.FU-Berlin.DE> Message-ID: On Jun 17, 2010, at 2:06 PM, Max wrote: > > For an embedded platform running Nagios using memcached would be > overkill and not the right choice. a very good point. I would be happy if the API was generic enough to allow multiple backends - and if it was simple to wrap it around memcached even better! I am willing to invest some time adding memcached support if it would be useful? William From tonvoon at gmail.com Fri Jun 18 09:47:33 2010 From: tonvoon at gmail.com (Ton Voon) Date: Fri, 18 Jun 2010 08:47:33 +0100 Subject: [Nagiosplug-devel] [Nagiosplug-help] SSH Plugins In-Reply-To: <4C1AE82F.1050605@aei.ca> References: <17F23FF008715A40B7C82FD31B389FDA07E1811DC6@HQ-MB-07.ba.ad.ssa.gov> <4C1AE82F.1050605@aei.ca> Message-ID: <718C71E6-65B4-47D0-BF7F-86BD1987999B@gmail.com> On 18 Jun 2010, at 04:29, Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10-06-04 10:25 AM, Franz, Jay wrote: >> Has anyone had any success getting the nagios plugins, check_ssh and >> check_by_ssh to work through a socks firewall? I can configure my >> ssh >> client, via environment variables or command line options, with no >> problems. But, I have had no success with the plugins as there seems >> to be no way to pass either environment variables or command line >> options to the plugins. Any help would be appreciated. > > I'm adding the devel list.... > > This is an excellent point... lib/utils_cmd.c:140 creates a new empty > environment array with LC_ALL=C. > > Instead we could use the current environment in: > extern char **environ; > > Now I'm wondering if we should rewrite **environ with the LC_ALL > changed/added or if we can ignore it. Ton, since you added > utils_cmd, do > you have any idea? I set to C, to ensure that the output is not localised from the other end. But that wouldn't work in different locales if you wanted to capture 3rd party error messages in other languages. So it probably should be a plugin writer's decision whether to set LC_ALL=C. As to the whole environment, I can't recall why it is wiped. I can see that PATH could have been altered which maybe a security risk, but that seems like a bad excuse, especially if your system requires different PATHs to be set to get to some binaries (*cough*, Solaris). Ton From ae at op5.se Fri Jun 18 09:55:19 2010 From: ae at op5.se (Andreas Ericsson) Date: Fri, 18 Jun 2010 09:55:19 +0200 Subject: [Nagiosplug-devel] [Nagiosplug-help] SSH Plugins In-Reply-To: <718C71E6-65B4-47D0-BF7F-86BD1987999B@gmail.com> References: <17F23FF008715A40B7C82FD31B389FDA07E1811DC6@HQ-MB-07.ba.ad.ssa.gov> <4C1AE82F.1050605@aei.ca> <718C71E6-65B4-47D0-BF7F-86BD1987999B@gmail.com> Message-ID: <4C1B2667.10904@op5.se> On 06/18/2010 09:47 AM, Ton Voon wrote: > > On 18 Jun 2010, at 04:29, Thomas Guyot-Sionnest wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10-06-04 10:25 AM, Franz, Jay wrote: >>> Has anyone had any success getting the nagios plugins, check_ssh and >>> check_by_ssh to work through a socks firewall? I can configure my >>> ssh >>> client, via environment variables or command line options, with no >>> problems. But, I have had no success with the plugins as there seems >>> to be no way to pass either environment variables or command line >>> options to the plugins. Any help would be appreciated. >> >> I'm adding the devel list.... >> >> This is an excellent point... lib/utils_cmd.c:140 creates a new empty >> environment array with LC_ALL=C. >> >> Instead we could use the current environment in: >> extern char **environ; >> >> Now I'm wondering if we should rewrite **environ with the LC_ALL >> changed/added or if we can ignore it. Ton, since you added >> utils_cmd, do >> you have any idea? > > I set to C, to ensure that the output is not localised from the other > end. But that wouldn't work in different locales if you wanted to > capture 3rd party error messages in other languages. So it probably > should be a plugin writer's decision whether to set LC_ALL=C. > > As to the whole environment, I can't recall why it is wiped. I can see > that PATH could have been altered which maybe a security risk, but > that seems like a bad excuse, especially if your system requires > different PATHs to be set to get to some binaries (*cough*, Solaris). > It was wiped in the old popen() based implementation. I retained that behaviour when I wrote the runcmd() wrapper thing, and noone seems to have gotten around to reverting that change. I think setting LC_ALL=C explicitly and retaining the rest of the environment would be a far better solution, although that environment should almost certainly be passed in from the caller rather than automangled at the lowest level. That way, we can simply use the incredibly portable int main(int argc, char **argv, char **env); declaration of 'main'. I have no idea if 'extern char *environ;' is around on all systems where we'd like to support plugin execution, but the declaration style above works even on VMS and Ultrix, so it's safe to assume it will work everywhere. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From mailinglisten at brennt.net Fri Jun 18 11:47:05 2010 From: mailinglisten at brennt.net (Christian Lauf) Date: Fri, 18 Jun 2010 11:47:05 +0200 Subject: [Nagiosplug-devel] =?utf-8?q?Enc=3A_Suggest_Improvement_plugin_?= =?utf-8?q?=22check=5Foracle=22?= In-Reply-To: <403965.37492.qm@web52902.mail.re2.yahoo.com> References: <403965.37492.qm@web52902.mail.re2.yahoo.com> Message-ID: Hello Eduardo, maybe check_oracle_health can do what you need?? It can monitor tablespaces. See: http://labs.consol.de/lang/de/nagios/check_oracle_health/ Kind regards, Christian -- For private mail please use my GPG-Key. ID: 0xB7849C76 From eduardowillame at yahoo.com.br Fri Jun 18 12:06:12 2010 From: eduardowillame at yahoo.com.br (Eduardo Valentim - Datamanager Consultoria) Date: Fri, 18 Jun 2010 03:06:12 -0700 (PDT) Subject: [Nagiosplug-devel] Enc: Suggest Improvement plugin "check_oracle" Message-ID: <980134.5825.qm@web52908.mail.re2.yahoo.com> I didnt test this yet. I decided to use check_oracle because its simple, but this feature is missing. The default plugin returns no value from temporary tablespaces... Atenciosamente, Eduardo Valentim Em 18/06/2010, ?s 06:47, Christian Lauf escreveu: Hello Eduardo, maybe check_oracle_health can do what you need?? It can monitor tablespaces. See: http://labs.consol.de/lang/de/nagios/check_oracle_health/ Kind regards, Christian -- For private mail please use my GPG-Key. ID: 0xB7849C76 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________________ 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 eduardowillame at yahoo.com.br Fri Jun 18 12:06:12 2010 From: eduardowillame at yahoo.com.br (Eduardo Valentim - Datamanager Consultoria) Date: Fri, 18 Jun 2010 03:06:12 -0700 (PDT) Subject: [Nagiosplug-devel] Enc: Suggest Improvement plugin "check_oracle" Message-ID: <980134.5825.qm@web52908.mail.re2.yahoo.com> I didnt test this yet. I decided to use check_oracle because its simple, but this feature is missing. The default plugin returns no value from temporary tablespaces... Atenciosamente, Eduardo Valentim Em 18/06/2010, ?s 06:47, Christian Lauf escreveu: Hello Eduardo, maybe check_oracle_health can do what you need?? It can monitor tablespaces. See: http://labs.consol.de/lang/de/nagios/check_oracle_health/ Kind regards, Christian -- For private mail please use my GPG-Key. ID: 0xB7849C76 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null From noreply at sourceforge.net Wed Jun 23 16:58:27 2010 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Jun 2010 14:58:27 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2999924 ] check_http: add search string into 'string not found' msg Message-ID: Patches item #2999924, was opened at 2010-05-11 12:23 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2999924&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) >Assigned to: Ton Voon (tonvoon) Summary: check_http: add search string into 'string not found' msg Initial Comment: Is very useful to show the search string in the 'string not found' message when it isn't found in the web page. Patch attached to provide this functionality when using '-o' switch (so is backwards compatible). Patch is against git as of timestamp in patch. ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2010-06-23 15:58 Message: Thanks. Fixed in git now ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2010-06-23 15:58 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Duncan Ferguson (duncan_ferguson) Date: 2010-06-09 16:26 Message: Patch updated to include hostname and URL in 'string not found' message ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2999924&group_id=29880 From dermoth at aei.ca Wed Jun 23 17:29:00 2010 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 23 Jun 2010 11:29:00 -0400 Subject: [Nagiosplug-devel] [Nagiosplug-help] SSH Plugins In-Reply-To: <4C1B2667.10904@op5.se> References: <17F23FF008715A40B7C82FD31B389FDA07E1811DC6@HQ-MB-07.ba.ad.ssa.gov> <4C1AE82F.1050605@aei.ca> <718C71E6-65B4-47D0-BF7F-86BD1987999B@gmail.com> <4C1B2667.10904@op5.se> Message-ID: <4C22283C.2050704@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-06-18 03:55 AM, Andreas Ericsson wrote: > On 06/18/2010 09:47 AM, Ton Voon wrote: >> >> >> I set to C, to ensure that the output is not localised from the other >> end. But that wouldn't work in different locales if you wanted to >> capture 3rd party error messages in other languages. So it probably >> should be a plugin writer's decision whether to set LC_ALL=C. >> >> As to the whole environment, I can't recall why it is wiped. I can see >> that PATH could have been altered which maybe a security risk, but >> that seems like a bad excuse, especially if your system requires >> different PATHs to be set to get to some binaries (*cough*, Solaris). >> > > It was wiped in the old popen() based implementation. I retained that > behaviour when I wrote the runcmd() wrapper thing, and noone seems to > have gotten around to reverting that change. I think setting LC_ALL=C > explicitly and retaining the rest of the environment would be a far > better solution, although that environment should almost certainly be > passed in from the caller rather than automangled at the lowest level. > That way, we can simply use the incredibly portable > > int main(int argc, char **argv, char **env); > > declaration of 'main'. I have no idea if 'extern char *environ;' is > around on all systems where we'd like to support plugin execution, > but the declaration style above works even on VMS and Ultrix, so it's > safe to assume it will work everywhere. There might be other issues to be careful about with **env... See: https://www.securecoding.cert.org/confluence/display/seccode/ENV31-C.+Do+not+rely+on+an+environment+pointer+following+an+operation+that+may+invalidate+it I would tend to just use **environ where available and fall back to the current behaviour otherwise... It also seems that we can get portable setenv and **environ with gnulib. With the appropriate modules ingluded, I could just use setenv to add LC_ALL and then use **environ which will have my added variable. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwiKDYACgkQ6dZ+Kt5BchZpjQCcD848o7r2uGF4uBug7PkgUfhe 6FcAoLJ1e9742HJVq/klBGraccilsn5j =CG7V -----END PGP SIGNATURE----- From dimitrigordeziani at gmail.com Wed Jun 23 19:34:14 2010 From: dimitrigordeziani at gmail.com (Dimitri Gordeziani) Date: Wed, 23 Jun 2010 21:34:14 +0400 Subject: [Nagiosplug-devel] Hello, can someone help me... Message-ID: Hello, can someone help me? Im using nagious plugins for cacti to monitor vmware esxi (VPS server) the issue is that when I try to get net info(vm_net) for Virtuam Machine located on this VPS host server, I get only (net_receive=0.00KB;; net_send=0.00KB;;) - the command is example "perl /var/www/cacti/scripts/ check_esx3.pl -H "VPS host IP" -N "VIrtual Machine Name" -u User -p password -l NET" but as I guess(after investigated) this issue happens when there is network trafic(for Virtual Machine) in bits(small/less traffic) and if there is the traffice in KB,MB so then there is no any issue(the script is worknig fine and gives me a result example "net_receive=122.12KB;; net_send=1210.12KB;;") that is why I would like if it is possible to change/replace the default measure for networ activity from uom="kB"(kbyte) with uom="kb" or uom="b", is it possible? Ive tried to change this value in ..../Nagios/Plugin.pm and ...../Nagios/Plugin/ Performance.pm files but without any success.. pleaes let me know if it is possible somehow to set default traffic measure in bits and not bytes... otherwise I do not get any network info when there is activity in bits(low network activity) and not in bytes/kB/MB (hight network activity) thank you in advance.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitrigordeziani at gmail.com Thu Jun 24 14:50:00 2010 From: dimitrigordeziani at gmail.com (Dimitri Gordeziani) Date: Thu, 24 Jun 2010 15:50:00 +0300 Subject: [Nagiosplug-devel] Hello, can someone help me... In-Reply-To: References: Message-ID: Please can you reply me on this email if it is possible to make nagios plugin to monitor traffice in bits instead of bytes and how? thank you.. On Wed, Jun 23, 2010 at 8:34 PM, Dimitri Gordeziani < dimitrigordeziani at gmail.com> wrote: > Hello, > > can someone help me? > > Im using nagious plugins for cacti to monitor vmware esxi (VPS server) > > the issue is that when I try to get net info(vm_net) for Virtuam Machine > located on this VPS host server, I get only (net_receive=0.00KB;; > net_send=0.00KB;;) - the command is example "perl /var/www/cacti/scripts/ > check_esx3.pl -H "VPS host IP" -N "VIrtual Machine Name" -u User -p > password -l NET" > > but as I guess(after investigated) this issue happens when there is network > trafic(for Virtual Machine) in bits(small/less traffic) and if there is the > traffice in KB,MB so then there is no any issue(the script is worknig fine > and gives me a result example "net_receive=122.12KB;; net_send=1210.12KB;;") > > that is why I would like if it is possible to change/replace the default > measure for networ activity from uom="kB"(kbyte) with uom="kb" or uom="b", > is it possible? > > Ive tried to change this value in ..../Nagios/Plugin.pm and > ...../Nagios/Plugin/ > Performance.pm files but without any success.. > > pleaes let me know if it is possible somehow to set default traffic measure > in bits and not bytes... otherwise I do not get any network info when there > is activity in bits(low network activity) and not in bytes/kB/MB (hight > network activity) > > thank you in advance.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shadhin71 at gmail.com Thu Jun 24 16:25:28 2010 From: shadhin71 at gmail.com (shadih rahman) Date: Thu, 24 Jun 2010 10:25:28 -0400 Subject: [Nagiosplug-devel] Hello, can someone help me... In-Reply-To: References: Message-ID: Dimitri, Please take a look at this oid. you can use check_snmp plugin with the following oid. http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?translate=Translate&objectInput=ifInOctets Also, these requests are not proper for Nagios Plugin Developement mailing list. Please ask these questions in Nagios user mailing list in the future On Thu, Jun 24, 2010 at 8:50 AM, Dimitri Gordeziani < dimitrigordeziani at gmail.com> wrote: > Please can you reply me on this email if it is possible to make nagios > plugin to monitor traffice in bits instead of bytes and how? > > thank you.. > > > On Wed, Jun 23, 2010 at 8:34 PM, Dimitri Gordeziani < > dimitrigordeziani at gmail.com> wrote: > >> Hello, >> >> can someone help me? >> >> Im using nagious plugins for cacti to monitor vmware esxi (VPS server) >> >> the issue is that when I try to get net info(vm_net) for Virtuam Machine >> located on this VPS host server, I get only (net_receive=0.00KB;; >> net_send=0.00KB;;) - the command is example "perl /var/www/cacti/scripts/ >> check_esx3.pl -H "VPS host IP" -N "VIrtual Machine Name" -u User -p >> password -l NET" >> >> but as I guess(after investigated) this issue happens when there is >> network trafic(for Virtual Machine) in bits(small/less traffic) and if there >> is the traffice in KB,MB so then there is no any issue(the script is worknig >> fine and gives me a result example "net_receive=122.12KB;; >> net_send=1210.12KB;;") >> >> that is why I would like if it is possible to change/replace the default >> measure for networ activity from uom="kB"(kbyte) with uom="kb" or uom="b", >> is it possible? >> >> Ive tried to change this value in ..../Nagios/Plugin.pm and >> ...../Nagios/Plugin/ >> Performance.pm files but without any success.. >> >> pleaes let me know if it is possible somehow to set default traffic >> measure in bits and not bytes... otherwise I do not get any network info >> when there is activity in bits(low network activity) and not in bytes/kB/MB >> (hight network activity) >> >> thank you in advance.. >> > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________________ > 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 > -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: