NRPE upgrade question / more than one kb output

[Allan Lawrie]

I have a 2.4/2.5.1 codebase with one change, the NRPE message length is 
pushed out to 4k. This works without problems on Solaris 8/9/10. For 
other OS's I have no idea.

Here're the files I changed to make it work:

nagios-2.4/include/common.h  (MAX_INPUT_BUFFER)
nagios-2.4/include/objects.h  (MAX_PLUGINOUTPUT_LENGTH)
nagios-plugins-1.4.3/plugins/common.h  (MAX_INPUT_BUFFER)
nrpe-2.5.1/include/common.h  (MAX_INPUT_BUFFER & MAX_PACKETBUFFER_LENGTH)

There are two things I spotted while making these changes:

a) Config checks using "nagios -v" will always display a warning unless 
you fix that part of the code too.

b) The modified nrpe daemon and send_nrpe will NOT communicate with 
unmodified ones. The message sizes have to match. That is why Nagios and 
NRPE are changed. I did the plugins as well, since my main problem was 
with the output of check_disk.

Andreas Ericsson wrote:
> Steffen Poulsen wrote:
>   
>>> [mailto:nagios-devel-bounces at lists.sourceforge.net] På vegne 
>>> af Andreas Ericsson
>>> Steffen Poulsen wrote:
>>>       
>>>> If anybody knows if there is a spec for the NRPE protocol 
>>>>         
>>> available, we would like a pointer to it.
>>>
>>> It's in the code. If you've got the brains to change it, 
>>> you've got the brains to read it.
>>>       
>> Thanks for the trust in us :-)
>>     
>
> You're welcome ;-)
>
>   
>> We did try our first efforts, but from our reading the source it seems
>> the NRPE protocol/current implementation expects fixed size messages
>> which didn't make much sense to us as a design choice - we will give it
>> another glance.
>>
>>     
>
> It does send fixed size messages. Once upon a time, such an implementation
> made tons of sense, because it made it possible to get the code out in
> the open quickly, and it was a lot easier than doing it with arbitrarily
> sized buffers, especially since Nagios didn't (back then) accept plugin
> input above 1024 bytes anyways.
>
> Good luck in your endeavours though.
>
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/