nrpe, xinetd and LDAP problem

up at 3.am up at 3.am
Tue Aug 2 19:30:13 CEST 2011


Hi:

I have been trying to track down the fix for this for a while.  We have a Nagios
server monitoring a few dozen servers.  Most of these servers authenticate users
against a separate (CentOS Directory Server).  We ONLY use LDAP for user/group
authentication.  It was configured via authconfig and even has a backup LDAP
server.

Whenever there is a problem with the primary LDAP server, all of the NRPE clients
timeout on their services.  Note that the "nagios" user and group exists in the
local auth files on all these servers...there is no need for NRPE or xinetd to use
LDAP:

Aug  2 12:03:18 client1 xinetd[32012]: nss_ldap: failed to bind to LDAP server
ldap://ldap1.domain.com/: Can't contact LDAP server
Aug  2 12:03:18 client1 xinetd[32012]: nss_ldap: reconnected to LDAP server
ldap://ldap2.domain.com/
Aug  2 12:03:18 client1 nrpe[32012]: Error: Could not complete SSL handshake. 5

The message then repeats in the log several times and we all get paged (texted)
hundreds of times :-(

I looked around and found that others have had this issue, but I don't see a fix. 
Is it an xinetd problem?  Should we run nrpe standalone?

Here was somebody else having a similar issue (except we don't have a
per_source_limit problem):

http://www.linuxquestions.org/questions/linux-server-73/nrpe-ldap-and-ssl-787246/

------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Nagios-users mailing list
Nagios-users at 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





More information about the Users mailing list