nagios2 plugin output sanitization

[Andreas Ericsson]

Matthias.Flacke at gmx.de wrote:
> Andreas Ericson wrote:
>> Matthias Flacke wrote:
> 
>>> A solution could be that the plugin provides a CRC for its output which is
>>> checked afterwards. This could be included in the sanitized_output
>> option.
>> This is a big nono. A very large part of Nagios' success is that it's
>> really,
>> really easy to add functionality to it by providing a plugin that does
>> something, prints something and then exits with one of four well-defined
>> exit codes.
> 
> I understand your point and surely don't want to break the simplicity. But take the following scenario: 
> 
> A plugin uses both return code and output (let's assume 10K), but during NRPE transport only the first 4K survive due to NRPE and kernel compile limitation. The return code is OK but the plugin output is shortened silently and nobody notices this... I don't think that NSCA handles this differently.
> I don't want to 'solve' the problem increasing the buffers, since tomorrow certainly a message comes around with length = buffer + 1... 
> 

Righto, so the solution is to stream the data until the plugin is done feeding it. CRC
checksums in the output would modify the output, so the CRC would have to be modified,
but that would modify the CRC again so ...

One could otherwise argue that plugins designed to be run via NRPE should try very
hard to limit its output to fit in the 1K buffer NRPE uses.

We're digressing from the original "strip all html from plugins" though.

>>> Generally I would say that it's Nagios part to validate the sanity of the
>>> transport and raise UNKNOWN if not ok.
>>>
>> You're wrong. Nagios needs to validate (and fix) the strings it uses
>> depending
>> on the context where it's used. The output from the plugins is written to a
>> file as far as Nagios core is concerned, so there's really no need to
>> mangle
>> them at all.
> 
> I meant the transport level only. On the sender side there is a plugin where I can do everything easily (maybe such a CRC or something else). On the receiver side there is Nagios core where any bytes are gracefully received, even if it's only half of the stuff. ;-)
> 
> How can I deal with this problem?
> 

Patch nagios (and all intermittent data transports) to accept an arbitrary
data-size and feed it in chunks. It's really quite simple, but it's not my
itch.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/