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
