[Pkg-nagios-devel] Bug#756479: Bug#756479: (no subject)

[Alexander Wirt]

On Tue, 01 Sep 2015, David Rosenstrauch wrote:

> On 09/01/2015 11:15 AM, Alexander Wirt wrote:
> >On Tue, 01 Sep 2015, David Rosenstrauch wrote:
> >
> >>On 09/01/2015 10:58 AM, Alexander Wirt wrote:
> >>>On Tue, 01 Sep 2015, David Rosenstrauch wrote:
> >>>
> >>>>So what is the recommended workaround for users who are currently relying on
> >>>>this functionality?
> >>>either get your environment fixed, or build your own package.
> >>>
> >>>Alex
> >>
> >>Not sure what you mean by "get your environment fixed"?
> >>
> >>Presumably a "fixed environment" means "one that doesn't use
> >>'dont_blame_nrpe'".  That's fair enough.  But that also obviously removes
> >>previously working functionality
> >>
> >>So that's exactly what I was asking:  for someone who was previously making
> >>use of this functionality, and no longer should, what might a "fixed
> >>environment" look like?  What is the recommended/more secure way to pass
> >>parms to a remote NRPE process now?  Or, if it's recommended that one not
> >>pass parms to NRPE, what is recommended instead.
> >nrpe has several, not fixable security problems with argument parsing. You
> >should not use it at all. A secure alternative would be to use check_by_ssh.
> >
> >>For a concrete example, I'm currently monitoring machines for disk space.
> >>Most machines I check for at least 20% disk space free.  But on machines
> >>with large disks, 20% is excessive, so I drop that to 10%.  So the 20%/10%
> >>is a parm that I pass to NRPE.  What would be the recommended way to
> >>implement functionality like this going forward?
> >Either use check_by_ssh or use a configuration management system like puppet
> >to write out your nrpe configuration with different parameters.
> >
> >Alex
> >
> 
> Ah.  I wasn't aware of that check_by_ssh plugin.  I'll give that a look.
If you use it with ssh multiplexing
(https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing, look for
ControlMaster and ControlPersist) the overhead from ssh isn't that big. 

Alex

> 
> Thanks!
> 
> DR