search for: monitor1

Hey, I have the problem that my timer daemon doesn't start. I checked my configuration more than two times and I don't find the failure. Maybe someone can help me and tell me where the failure could be. --- syslog --- May 13 21:50:34 s-monitor1 upsmon[1674]: UPS usv3 at localhost on battery May 13 21:50:34 s-monitor1 upssched[855]: Executing command: ONBATT May 13 21:50:34 s-monitor1 upssched[855]: exec_cmd(/etc/nut/upssched-cmd ONBATT) returned 126 May 13 21:51:04 s-monitor1 upsmon[1674]: UPS usv1 at localhost on battery May 13 21:51:04...

...06-2013 > 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 > > And if I go back to the monitoring host and try to run nrpe with the -n > flag, this is what I get: > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -n -H > ops.jokefire.com > *CHECK_NRPE: Error receiving data from daemon.* > > And still getting the SSL error without the -n flag: > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H > ops.jokefire.com > *CHECK_NRPE: Er...

> > It's listening on both IPv6 and IPv4. Specifically, why is that a problem? The central problem seems to be that the monitoring host can't hit nrpe on port 5666 UDP. [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H puppet.mydomain.com CHECK_NRPE: Socket timeout after 10 seconds. It is listening on the puppet host on port 5666 [root at puppet:~] #lsof -i :5666 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xinetd 2915 root 5u IPv6 24493 0t0 TCP...

...is strange... > > > Do you have SSL aktive on both systems? Run nrpr localy without > > parameters > > > (this should return some nrpe stats) and check ldd for libssl. > > > > > > I don't seem to have that command. > > > > > > [root at monitor1:~] #find / -name "*nrpr" 2> /dev/null > > [root at monitor1:~] # > > > > And that's on either system. > > > > And if I do an ldd on both, this is what I can tell: > > > > Server: > > > > [root at monitor1:~] #ldd /usr/local/nag...

> This is strange... > Do you have SSL aktive on both systems? Run nrpr localy without parameters > (this should return some nrpe stats) and check ldd for libssl. I don't seem to have that command. [root at monitor1:~] #find / -name "*nrpr" 2> /dev/null [root at monitor1:~] # And that's on either system. And if I do an ldd on both, this is what I can tell: Server: [root at monitor1:~] #ldd /usr/local/nagios/libexec/check_nrpe linux-vdso.so.1 => (0x00007fffd895d000) * li...

...rrect. It's working on localhost: [root at puppet:~] #telnet localhost 5666 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. I notice if I stop the firewall on the puppet host (for no more than 2 seconds) and hit NRPE from the monitoring host it works: [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H puppet.mydomain.com NRPE v2.15 But as soon as the firewall has been enabled on the puppet host (a microsecond later) I get this result: [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H puppet.mydomain.com connect to address 216.120.xxx.xxx...

...SSL Problem. Do you have a nagios user account? Cat > /etc/passwd Yep! Both hosts have nagios user accounts. Demonstrating from the client: [root at ops:~] #id nagios uid=2002(nagios) gid=2002(nagios) groups=2002(nagios),2008(nagioscmd) And this is from the monitoring server: [root at monitor1:~] #id nagios uid=1001(nagios) gid=1001(nagios) groups=1001(nagios),1002(nagcmd) I do notice a slight difference in the user id and group id numbers. But I don't think that could be causing any issue. Does anyone else disagree? I might want to standardize user accounts at some point howver....

....org) Version: 2.15 Last Modified: 09-06-2013 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 And if I go back to the monitoring host and try to run nrpe with the -n flag, this is what I get: [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -n -H ops.jokefire.com *CHECK_NRPE: Error receiving data from daemon.* And still getting the SSL error without the -n flag: [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H ops.jokefire.com *CHECK_NRPE: Error - Could not complete SSL handshake...

...test against with check_nrpe, not using telnet. -- Eero 2015-05-04 2:27 GMT+03:00 Stephen Harris <lists at spuddy.org>: > On Sun, May 03, 2015 at 07:23:19PM -0400, Tim Dunphy wrote: > > [root at puppet:~] #telnet localhost 5666 > > This is using TCP > > > [root at monitor1:~] #nmap -p 5666 puppet.mydomain.com > ... > > 5666/tcp filtered nrpe > > This is using TCP > > > Back on the puppet host I verify that the port is open for UDP: > > So why are you opening a UDP port? > > -- > > rgds > Stephen > ______________________...

...66 open on the security group for this host. And I made sure the local firewall was stopped, because I am blocking ports with the security groups instead. [root at ops:~] #service iptables status Firewall is stopped. It's only when checking from the monitoring host that nrpe fails: [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H ops.jokefire.com CHECK_NRPE: Error - Could not complete SSL handshake. Really, really puzzling. This is driving me up a wall!! I hopeI can solve this soon.... Thanks for any and all help with this one!! Tim On Fri, May 1, 2015 at 1:02 AM, Eric Lehmann...

...stall-daemon make install-daemon-config make install-xinetd Rather than a yum install. If I install the nrpe package from yum I don't find a check_nrpe script on the system for some reason! I demonstrate this on another system than the ones I've been working with in this thread: [root at monitor1:~] #rpm -qa | grep nrpe | grep -v mcollective nrpe-2.15-2.el7.x86_64 [root at monitor1:~] #find / -name "check_nrpe" [root at monitor1:~] # So I'm more comfortable with a source install. test against with check_nrpe, not using telnet. > I actually solved the problem by adding...

...t, I noticed that I was getting permission denied errors on the keypairs on the client hosts. In my audit logs I found this entry: type=AVC msg=audit(1434769414.956:562): avc: denied { open } for pid=3558 comm="ruby" path="/etc/puppet/environments/production/modules/bacula/files/monitor1/monitor1.mydomain.com.crt" dev="vda1" ino=1842005 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=file And audit2allow told me this: #grep puppet /var/log/audit/audit.log | audit2allow -M puppet ******************** IMPORTANT *******************...

...bluethundr at gmail.com>: > > This is strange... > > Do you have SSL aktive on both systems? Run nrpr localy without > parameters > > (this should return some nrpe stats) and check ldd for libssl. > > > I don't seem to have that command. > > > [root at monitor1:~] #find / -name "*nrpr" 2> /dev/null > [root at monitor1:~] # > > And that's on either system. > > And if I do an ldd on both, this is what I can tell: > > Server: > > [root at monitor1:~] #ldd /usr/local/nagios/libexec/check_nrpe > linux-vds...

Hello, I am trying to monitor a host in the Amazon EC2 cloud. Yet when I try to check NRPE from the monitoring host I am getting an SSL handshake error: [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H ops.jokefire.com CHECK_NRPE: Error - Could not complete SSL handshake. And if I telnet into the host on port 5666 to see if the FW port is open, the connection closes right away: [root at monitor1:~] #telnet ops.somewhere.com 5666 Trying 54.225.218.125....

...s "iptables -L" show anything of note? I'm leaving iptables off in this host. Because it's an AWS EC2 host I'm managing the firewall ports using the AWS security groups. [root at ops:~] #service iptables status Firewall is stopped. But still, there's this... [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H ops.jokefire.com CHECK_NRPE: Error - Could not complete SSL handshake. Sadly.... :( Thanks for your input tho! On Fri, May 1, 2015 at 3:18 PM, Brian Miller <centos at fullnote.com> wrote: > On Fri, 2015-05-01 at 01:32 -0400, Tim Dunphy wrote:...

..."record" Load "vbe" Load "int10" EndSection Section "Monitor" Identifier "Monitor0" HorizSync 30-107 VertRefresh 50-160 Option "DPMS" EndSection Section "Monitor" Identifier "Monitor1" HorizSync 31.5 VertRefresh 20-60 Option "DPMS" EndSection Section "Device" Identifier "ATI Graphics Adapter" Driver "fglrx" Option "mtrr" &q...

...4 1:55 GMT+03:00 Tim Dunphy <bluethundr at gmail.com>: > > > > It's listening on both IPv6 and IPv4. Specifically, why is that a > problem? > > > The central problem seems to be that the monitoring host can't hit nrpe on > port 5666 UDP. > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H > puppet.mydomain.com > CHECK_NRPE: Socket timeout after 10 seconds. > > It is listening on the puppet host on port 5666 > > [root at puppet:~] #lsof -i :5666 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > xinetd 2915...

...rvice_description Check Memcached 11212 contact_groups linux-admins check_command check_memcached!web1.example.com !11212 notifications_enabled 1 } And if I run both checks manually they succeed: [root at monitor1:/usr/local/nagios/etc/objects/servers] #../../../libexec/ check_memcached.pl -H web1.example.com -p 11211 MEMCACHE OK: memcached 1.4.22 on web1.example.com:11211, up 22 minutes 52 seconds [root at monitor1:/usr/local/nagios/etc/objects/servers] #../../../libexec/ check_memcached.pl -H web1.exam...

...gt; > And I made sure the local firewall was stopped, because I am blocking ports > with the security groups instead. > > [root at ops:~] #service iptables status > Firewall is stopped. > > It's only when checking from the monitoring host that nrpe fails: > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H > ops.jokefire.com > CHECK_NRPE: Error - Could not complete SSL handshake. > > Really, really puzzling. This is driving me up a wall!! I hopeI can solve > this soon.... > > Thanks for any and all help with this one!! > Tim > &gt...

hey all, I tried disabling tcp v6 on a C7 box this way: [root at puppet:~] #cat /etc/sysctl.conf # System default settings live in /usr/lib/sysctl.d/00-system.conf. # To override those settings, enter new settings here, or in an /etc/sysctl.d/<name>.conf file # # For more information, see sysctl.conf(5) and sysctl.d(5). net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6