NRPE upgrade question / more than one kb output

[Andreas Ericsson]

Steffen Poulsen wrote:
>> Fra: nagios-devel-bounces at lists.sourceforge.net 
>> [mailto:nagios-devel-bounces at lists.sourceforge.net] På vegne af
>> Allan Lawrie b) The modified nrpe daemon and send_nrpe will NOT 
>> communicate with unmodified ones. The message sizes have to match.
>> 
> 
> Thanks for your feedback - that problem is the exact problem we are
> trying to brainstorm.
> 
> We have 1000+ hosts running vanilla NRPE installations and we would
> like to start upgrading them to allow for more output. We would like
> to have as non-intruding upgrade procedure as possible - no "big
> bangs" etc.
> 
> But apparently there is no way a sysadmin can upgrade a NRPE-client
> for itself without touching the Nagios server-config also (switch to
> a new check_nrpe for the host) at the same time.
> 

Ofcourse there is, but you need to teach check_nrpe on your nagios
server to support both the old and the new protocol at the same time.

I would claim that NRPE protocol 2 works nicely for sending requests
to nrpe, so that part can remain. Then, assuming an nrpe3-aware nrpe
daemon, the daemon can read as much output as it needs and send it
back to check_nrpe, which will have to do the right thing depending
on the response packet the nrpe daemon sends.

Note that if you go with arbitrary size messages, you'll need to
have output packages and a "final" package which sends the exit-code
(and possibly the last strands of output).

> I had hoped the allowed output size was implementation-specific (not
> enforced by design), but it seems we will have this problem every
> time we want to touch the output size.
> 

Not if you go with the design outlined above, which assumes your
requests from check_nrpe to nrpe will always be using nrpe protocol 2,
which I think is reasonable.

> there was a post mentioning there might be
> output limits regarding the pipe mechanisms in the os'es also.

On Linux, it's 4KiB of guaranteed atomic writes to pipes. Using anything
*but* atomic writes to the nagios command-fifo is just plain stupid, as
you'll sometimes lose the race and have garbage input sent to nagios. It
can probably handle that, but it won't know to glue the broken messages
back together, so the remainder will be discarded.


> We
> need to choose the value that gives us the maximum output size while
> avoiding new related problems arising.
> 

Or go with the strategy above.

-- 
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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/