<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 29, 2010, at 5:47 AM, Assaf Flatto wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div text="#000000" bgcolor="#ffffff">
    <br>
    <blockquote cite="mid:02B80625-B645-4C15-A3CC-9D2679F206C2@salon.com" type="cite">
      <div>Assaf - thanks for your time and patience outlining those
        steps:</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    That is what the list is about .<br>
    <br>
    <blockquote cite="mid:02B80625-B645-4C15-A3CC-9D2679F206C2@salon.com" type="cite">
      <div>I was able to at least get the connectivity between Nagios
        server and the monitored host to show a valid connection:</div>
      <div><br>
      </div>
      <div>
        <div>/usr/local/nagios/libexec/check_nrpe -H 10.0.100.139 -c
          check_users</div>
        <div>USERS OK - 1 users currently logged in |users=1;5;10;0</div>
        <div><br>
        </div>
        <div>there were a few things wrong on the monitoring server, or
          at least what I changed:</div>
        <div><br>
        </div>
        <div>* changed ownership of nrpe.cfg to nagios.nagios</div>
        <div>* modified xinetd.d/nrpe to show Nagios server IP as
          allowed connection</div>
        <div><br>
        </div>
        <div>I struggled with a few other things, and connection
          attempts, before I realized I hadn't restarted the nrpe
          service after modifying the xinetd.d/nrpe file.</div>
        <div><br>
        </div>
        <div>I did notice that the plugin location from another server
          is different than the one that is missing:</div>
        <div>
          <div style="margin: 0px; font: 12px Helvetica;"><i><b>/usr/lib64/nagios/plugins</b></i>
            vs <i>/<b>usr/local/nagios/libexec/</b></i>  (guess this has
            something to do with the way it was compiled)</div>
        </div>
      </div>
    </blockquote>
    <br>
    NRPE by default is placing the path as the lib64  in the nrpe.cfg
    sample file , while all other  packages use the local path - this is
    something that you get used to "ignore-modify " with time .<br>
    <blockquote cite="mid:02B80625-B645-4C15-A3CC-9D2679F206C2@salon.com" type="cite">
      <div>
        <div>Guess I have to wait now a few mins before the host shows
          in the panel? as its not showing now even after 10 mins.
           Restarting xinetd shows this in /var/log/messages:</div>
        <div><br>
        </div>
        <div><b>xinetd[22518]: bind failed (Address already in use
            (errno = 98)). service = nrpe (</b>is this a bug or anything
          in xinetd? I saw that referenced on a few other forums)</div>
        <div><br>
        </div>
        <div>nrpe service is running and listening though on 5666</div>
      </div>
    </blockquote>
    I have always run nrpe as a stand alone daemon , never with xinetd ,
    to have better control on what is running and how it is run .<br>
    <br>
    From what i remember about xinetd , it has an internal "keep-alive"
    mechanism that waits till all connections are terminated before it
    releases a port (again , i may be wrong ) you  need to stop it and
    wait till the port is no longer shown as active , and then restart
    it .<br>
    <br>
    Or move to a standalone daemon - that will allow you to control the
    nrpe separately from any other service and  better debug the issue.<br>
    <br>
    <br></div><br></blockquote><br></div><div><br></div><div><br></div><div>I had to take a break from this project, but now I'm circling back to it.</div><div><br></div><div>I am able to connect from the nagios server to the monitored node (this server has (2) IP's as it's eth0 has an IP alias bound to it, hence checking both IP's):</div><div><br></div><div><div><b>bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.139</b></div><div><b>NRPE v2.12</b></div><div><b>bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.138</b></div><div><b>NRPE v2.12</b></div></div><br><div>I can use another event handler:</div><div><br></div><div><div><b>bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.139 -c check_users</b></div><div><b>USERS OK - 1 users currently logged in |users=1;5;10;0</b></div><div><b>bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.138 -c check_users</b></div><div><b>USERS OK - 1 users currently logged in |users=1;5;10;0</b></div></div><div><b><br></b></div><div>I can also telnet from the Nagios server to the monitored host:</div><div><b><br></b></div><div><div><b>bash-3.1# telnet 10.0.100.139 5666</b></div><div><b>Trying 10.0.100.139...</b></div><div><b>Connected to 10.0.100.139 (10.0.100.139).</b></div></div><div><b><br></b></div><div><b>but... </b></div><div><b><br></b></div><div>I am still getting an SSL failure on the handshake?</div><div><br></div><div>Oct 11 19:12:43 mywebserverB nrpe[17659]: Error: Could not complete SSL handshake</div><div><br></div><div>But back to xinetd; does seem that its not binding or starting with NRPE correctly (not sure if this is why its not connecting)</div><div><br></div><div>{missing server in host panel}:</div><div><br></div><div><div><div><b><div>Oct 11 18:28:37 mywebserverB xinetd[23960]: Exiting...</div><div>Oct 11 18:28:38 mywebserverB xinetd[24300]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.</div><div>Oct 11 18:28:38 mywebserverB xinetd[24300]: Started working: 0 available services</div><div><br></div></b></div></div></div><div><br></div><div><br></div><div>{server showing in host panel}:</div><div><br></div><div><div><b>Oct 11 18:32:34 mywebserverA xinetd[3579]: Exiting...</b></div><div><b>Oct 11 18:32:34 mywebserverA xinetd[28455]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.</b></div><div><b>Oct 11 18:32:34 mywebserverA xinetd[28455]: Started working: 1 available service</b></div></div><div><br></div><div><br></div></body></html>