NRPE upgrade question / more than one kb output
Allan Lawrie
allan.lawrie at eservglobal.com
Wed Nov 21 20:55:31 CET 2007
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/
More information about the Developers
mailing list