Antwort: NEED HELP configuring NSCA with INETD

h.baecker at ecofis.de h.baecker at ecofis.de
Tue Jan 13 08:14:52 CET 2004


Hi there,

Your config looks OK, same as I have configured on my side.

Perhaps the tcpd spends some LOG?

Yours 
Hendrik




Michael Tucker <mtucker at airmail.net> 
Gesendet von: nagios-users-admin at lists.sourceforge.net
12.01.2004 23:33

An
nagios-users at lists.sourceforge.net
Kopie

Thema
[Nagios-users] NEED HELP configuring NSCA with INETD






Howdy:

I have finally succeeded in my initial installation and configuration 
of Nagios, with help from Marc Powell (thanks, Marc!). I have a 
distributed nagios server, performing checks on a monitored host (using 
check_nrpe + nrpe), and forwarding the results to a central nagios 
server (using send_nsca + nsca). I am able to monitor the state of 
everything on either server via its web interface and Apache. The 
central server sends me notifications via email. Life is good. :-)

All is well, except for two things:

1) NRPE 2.0 doesn't work with SSL enabled. (This is being discussed in 
other threads.)

2) I haven't been able to get NSCA to work within inetd (using tcp 
wrappers). That is the point of this message.

NSCA works fine as a standalone daemon, i.e. if I launch it using the 
command:

# /usr/local/nagios/bin/nsca -c /usr/local/nagios/bin/nsca.cfg --single

then it works great. The status messages being collected by the 
distributed server are successfully passed to the central server, which 
then displays them correctly via its web interface.

But it does *not* work if I try to run it under inetd.

In that case, I get this message on the distributed server (the one 
running send_nsca):
> Error: Server closed connection before init packet was received
> Error: Could not read init packet from server

No data is passed to the central server, and it displays "(No output!)" 
for each of the monitored host's services.

Here are the relevant files:

/etc/hosts.allow:
> nsca: {IP of allowed host}

/etc/hosts.deny:
> ALL: ALL

/etc/inetd.conf:
> nsca                           stream          tcp             nowait  
nagios           /usr/sfw/sbin/tcpd              /usr/local/nagios/ 
> bin/nsca -c /usr/local/nagios/bin/nsca.cfg --inetd

/etc/services:
> nsca                           5667/tcp                # Nagios service 
check acceptor

# ls -l /usr/sfw/sbin/tcpd
> -r-xr-xr-x   1 root     bin          5452 Apr  6  2002 
> /usr/sfw/sbin/tcpd

# ls -l /usr/local/nagios/bin
> -rwxrwxr--   1 nagios   nagios    251472 Dec 12 12:02 nagios
> -rwxr-xr-x   1 nagios   nagios    167896 Dec 23 12:20 nsca
> -rw-r--r--   1 nagios   nagios      4997 Jan 12 09:42 nsca.cfg

/usr/local/nagios/bin/nsca.cfg (omitting comments):
> server_port=5667
> allowed_hosts={IP of allowed host, same as in /etc/hosts.allow}
> nsca_user=nagios
> nsca_group=nagios
> debug=0
> command_file=/usr/local/nagios/var/rw/nagios.cmd
> alternate_dump_file=/usr/local/nagios/var/rw/nsca.dump
> aggregate_writes=0
> append_to_file=0
> max_packet_age=30
> password={password, same as in send_nsca.cfg on distributed server}
> decryption_method=1 {same as in send_nsca.cfg on distributed server}

Just to stress the point: this *works* if I run NSCA as a standalone 
daemon. It just doesn't work if I try to run NSCA through inetd.

I'm stumped. Any ideas, anyone?

FYI, I'm running nagios 1.1, nsca 2.4, nrpe 2.0 (i.e. all the latest 
versions) under Solaris 9 (with all patches up to date).

Yours,
Michael



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20040113/8f63158d/attachment.html>


More information about the Users mailing list