And I made sure the local firewall was stopped, because I am blocking
ports
with the security groups instead.
As an aside, I wouldn't do this unless running in a VPC as there are other hosts in the general cloud and many are malicious.
Hmmm... you make an excellent point! I picked up this habit from an AWS shop I used to work at. But what you just said will make me reconsider!
It's only when checking from the monitoring host that nrpe fails:
Check /var/log/messages to see if xinetd says anything.
I tailed /var/log/messages while hitting the client with check_nrpe from the monitoring host. However, that didn't cause an entry in the messages log.
Also nrpe needs to be told from where connections are allowed whether running under an inetd or self-daemonized.
Yep! I've set the only_from to have only the loopback address and the IP for the monitoring host in /etc/xinetd.d/npre.
Also check the NRPE reviews on exchange.nagios.org, where the issue is discussed.
Cool! Thanks. I'll check it out, and see if I can find anything useful.
I appreciate the input!
Also I really appreciate the ongoing dialog with the community on this issue. I'm grasping at straws at this point. And all the attempts at help have been really great! I hope we can still get to the bottom of this!
Tim
On Sat, May 2, 2015 at 11:45 AM, Mark Milhollan mlm@pixelgate.net wrote:
On Fri, 1 May 2015, Tim Dunphy wrote:
And I made sure the local firewall was stopped, because I am blocking
ports
with the security groups instead.
As an aside, I wouldn't do this unless running in a VPC as there are other hosts in the general cloud and many are malicious.
It's only when checking from the monitoring host that nrpe fails:
Check /var/log/messages to see if xinetd says anything. Also nrpe needs to be told from where connections are allowed whether running under an inetd or self-daemonized.
Also check the NRPE reviews on exchange.nagios.org, where the issue is discussed.
/mark