Tree [354c6f] arelease /
History



File Date Author Commit
common 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
src 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
Changelog 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
Makefile.in 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
README 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
SECURITY 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
configure 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
configure.in 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
install-sh 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
nsca.cfg 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS
send_nsca.cfg 2001-06-23 Ethan Galstad Ethan Galstad [9c052d] Initial import into CVS

Read Me

***********
NSCA README
***********


Purpose
-------
The purpose of this addon is to allow you to execute Nagios
plugins on a remote host in as transparent a manner as possible.


Contents
--------

There are two pieces to this addon:

  1) nsca       - This program runs as a daemon on the central server
                  that runs Nagios.  It listens for service check
	          results from remote machines (sent using the
		  send_nsca program described below).  Upon receiving
                  data from a remote client, the daemon will make a
                  *very* basic attempt at validating the data it has
                  received from the client.  This is done by decrypting
                  the data with the password stored in the nsca.cfg 
                  file.  If the decrypted data looks okay (i.e. it was
                  originally encrypted by the send_ncsa program using
                  the same password), the daemon will make entries in
                  the Nagios external command file telling Nagios
                  to process the service check result.  

		  Notes: The nsca daemon must have sufficient rights
                  to open the Nagios command file for writing.  Also,
		  Nagios will only process passive service check
                  results that it finds in the external command file
                  if the service has been defined in the host config
                  file (hosts.cfg) and it is being monitored.


  2) send_nsca  - This is the client program that is used to send
		  service check information from a remote machine to
                  the nsca daemon on the central machine that runs
                  Nagios.   Service check information is read from
                  the standard input in tab-delimited format as
		  follows:

			<host_name>[tab]<svc_description>[tab]<return_code>[tab]<plugin_output>[newline]

	          where:

			<host_name>=short name of host that the
                                    service is associated with
			<svc_description>=description of the service
			<return_code>=numeric return code
			<plugin_output>=output from service check


Compiling
---------

The code is very basic and may not work on your particular
system without some tweaking.  I just haven't put a lot of effort
into this addon.  Most users should be able to compile
the daemon and client piece with the following commands...

./configure
make all

The binaries will be located in the src/ directory after you
run 'make all' and will have to be installed manually.



Installing
----------

The send_nsca program and associate config file (nsca.cfg) should
be placed on remote machines that you want to have communicate 
with the nsca daemon.  This means that you may have to compile the
send_nsca program on the remote machine, if its not the same
OS/architecture as that of the central server.

The nsca daemon and the configuration file (nsca.cfg) should
be placed somewhere on the central server running Nagios.

NOTES:  Make sure that you specify and use the same password in
        both the nsca.cfg and send_nsca.cfg files!  If you use a
        different password to encrypt the data than you do to
	decrypt it, the nsca daemon will reject the data you send
        it.



Security
--------

There are some security implications with allowing remote clients
to provide service check results to Nagios.  Because of this, you
have the option of encrypting the packets that the NSCA client sends
to the NSCA daemon.  Read the SECURITY file for more information on
the security risks of running NSCA, along with an explanation of what
kind of protection the encryption provides you.



Running Under INETD
-------------------

If you plan on running nsca under inetd and making use of TCP
wrappers, you need to do two things:

1) Add a line to your /etc/services file as follows (modify the port
   number as you see fit)

	nsca            5667/tcp	# NSCA

2) Add an entry to /etc/inetd.conf as follows

	nsca    stream  tcp     nowait  <user> /usr/sbin/tcpd <nscabin> -i <nscacfg>

   - Replace <user> with the name of the user that nrpe should run as
   - Replace <nscabin> with the path to the nsca binary on your system.
   - Replace <nscacfg> with the path to the nsca config file on your system.

3) Restart inetd will the following command

	/etc/rc.d/init.d/inet restart

4) Add entries to your /etc/hosts.allow and /etc/hosts.deny
   file to enable TCP wrapper protection for the nsca service.
   This is optional, although highly recommended.


Note: If you run nrpe under inetd, the server_port and 
      allowed_hosts variables in the nsca.cfg configuration 
      file are ignored.



Questions?
----------

If you have questions about this addon, or problems getting things
working, send me email.

	-- Ethan Galstad (nagios@nagios.org)