> -----Original Message-----
> From: Flyinvap [mailto:flyin...@orange.fr]
> Sent: Friday, February 19, 2010 7:21 AM
> To: nagios-users@lists.sourceforge.net
> Subject: Re: [Nagios-users] NRPE/NSCA replacement thoughts?
> 
> Le Fri, 19 Feb 2010 03:17:11 -0800,
> Kevin Keane <subscript...@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&#174; 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@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

Reply via email to