NRPE/NSCA replacement thoughts?

[Kevin Keane]

> -----Original Message-----
> From: Flyinvap [mailto:flyinvap at orange.fr]
> Sent: Friday, February 19, 2010 7:21 AM
> To: nagios-users at lists.sourceforge.net
> Subject: Re: [Nagios-users] NRPE/NSCA replacement thoughts?
> 
> Le Fri, 19 Feb 2010 03:17:11 -0800,
> Kevin Keane <subscription at kkeane.com> a écrit :
> 
> > Seems to me that NRPE beats SNMP to begin with?
> 
> I you need an insecure protocol, choose nrpe.
> 
> There is no key or password in nrep configuration. DH key is defined at
> during compilation ...

Oh, absolutely. And actually, I believe that's a good thing as long as you get to select the underlying transport mechanism. The authentication and encryption should really be provided by whatever carries the data, not by Nagios at all. With security-related issues, the fewer implementations you have, the better. Rather than reimplement encryption and authentication and then waiting for the security holes to get discovered, why not leverage the work on the SSH and Apache projects?

With SNMP, there is no way to do that - you basically can't wrap UDP in any way. With NRPE, you can easily implement all kinds of homegrown solutions already: ssh tunnels, HTTPS.

In the end, I agree with another poster: NRPE/NSCA could use a revamp (or outright replacement), but it's really not on the top of the list. And I'm concerned that the replacement may end up being worse than the original.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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