I strongly doubt it has any relation to ssl: NRPE - Nagios Remote Plugin Executor Copyright (c) 1999-2008 Ethan Galstad (nag...@nagios.org) Version: 2.12 Last Modified: 03-10-2008 License: GPL v2 with exemptions (-l for more info) SSL/TLS Available: Anonymous DH Mode, OpenSSL 0.9.6 or higher required TCP Wrappers Available
this is output from nrpe (Centos binary package) that shows it's compiled with ssl/tls support. Openssl library is installed as well. Anyway. I tried suggested workaround, defining "check_nrpe_no_ssl" as "$USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -n" and defining service as "check_nrpe_no_ssl!check_load" and running nrpe deamon no centos host with "-n" option - result is just the same, "NRPE: Unable to read output" However, when I do "./check_nrpe -H centos.host.com" it does return me nrpe version correctly ("NRPE v2.12"). From all this steps I figured that it is not about ssl at all - nrpe version is returned correctly with ssl and without it. Interesting, that in nagios server debug log I see that remote NRPE returns output that nagios check_nrpe cannot parse, it returns similar output, that I would get if call /usr/sbin/nrpe without arguments: [1277983505.131702] [016.2] [pid=17495] Parsing check output... [1277983505.131711] [016.2] [pid=17495] Short Output: (No output returned from plugin) [1277983505.131719] [016.2] [pid=17495] Long Output: NRPE Plugin for Nagios\nCopyright (c) 1999-2008 Ethan Galstad (nag...@nagios.org)\nVersion: 2.12\nLast Modified: 03-10-2008\nLicense: GPL v2 with exemptions (-l for more info)\nSSL/TLS Available: Anonymous DH Mode, OpenSSL 0.9.6 or higher required\n\nUsage: check_nrpe -H <host> [-n] [-u] [-p <port>] [-t <timeout>] [-c <command>] [-a <arglist...>]\n\nOptions:\n -n = Do no use SSL\n -u = Make socket timeouts return an UNKNOWN state instead of CRITICAL\n <host> = The address of the host running the NRPE daemon\n [port] = The port on which the daemon is running (default=5666)\n [timeout] = Number of seconds before connection times out (default=10)\n [command] = The name of the command that the remote daemon should run\n [arglist] = Optional arguments that should be passed to the command. Multiple\n arguments should be separated by a space. If provided, this must be\n the last option supplied on the command line.\n -h,--help Print this short help.\n -l,--license Print licensing information.\n -n,--no-ssl Do not initial an ssl handshake with the server, talk in plaintext.\n\nNote:\nThis plugin requires that you have the NRPE daemon running on the remote host.\nYou must also have configured the daemon to associate a specific plugin command\nwith the [command] option you are specifying here. Upon receipt of the\n[command] argument, the NRPE daemon will run the appropriate plugin command and\nsend the plugin output and return code back to *this* plugin. This allows you\nto execute plugins on remote hosts and 'fake' the results to make Nagios think\nthe plugin is being run locally.\n\n so that seems to me as if NRPE does not understand arguments from check_nrpe or something... any ideas? -- best regards, yuris Greg Pangrazio wrote: > I had a very similar problem with checks coming from Ubuntu 8.04 and > 10.04 destined for RHEL. I had to disable SSL on both ends and set > the encryption method to 0. > > I would also check the NRPE config to make sure the passphrases match > if you are using them. > > > Greg Pangrazio > > > > > > On Thu, Jul 1, 2010 at 6:49 AM, Julius Kidubuka <juki.e...@gmail.com> wrote: > >> Yuris, >> >> You could try compiling nrpe without ssl and then in your commands.cfg file >> have something like this; >> >> # 'check_nrpe' command definition >> define command{ >> command_name check_nrpe_no_ssl >> command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -n >> } >> >> Then in your specific service definitions have the check_command line read; >> >> check_command check_nrpe_no_ssl!<put-whatever-plugin> >> >> >> Hope this helps. >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Nagios-users mailing list >> Nagios-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/nagios-users >> ::: Please include Nagios version, plugin 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 Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null