nsca-2.9 compatability

[Michael Friedrich]

Eric Stanley wrote:
> I also ran into this issue this week, but before I had caught up on 
> the list traffic. I discussed it with Ethan and his concern is that 
> there are a lot of agents (especially for Windows) that are not being 
> maintained and will break with the larger buffer size expected by the 
> newer daemon.

which agents are you talking about? nsclient++ is very well maintained.

>
> We think the best way is to roll back the buffer size to its old value 
> for compatibility with older clients. NRDP is a more flexible solution 
> going forward anyway. We realize that rolling back the buffer size 
> will mean that some of the output will be truncated.

it's not about nrdp, it's about nsca itsself. people won't just change 
their environment because there's a more flexible solution. upgrading 
nsca works seamlessly and is rather simple.

>
> Anyone have violent objections or better ideas?

adding this change to changelog and marking the break with compatibility 
by incrementing the major version to 3.0. imho it's about time to change 
things.
packagers will be happy as well (nsca conflicts nsca3).

furthermore i suggest adding some docs and explaining the change. the 
most valuable part will be attaching to the pluginapi and their format, 
being truncated most likely on the various platforms.

changing the major version will also allow addon maintainers to release 
an updated version. those who can't upgrade their clients shouldn't 
upgrade to nsca3 then either. ah well and delete the 2.9 release from 
sf.net then.


jm2c,
michael


>
> Eric
>
> On 1/11/2012 11:57 PM, Daniel Wittenberg wrote:
>>
>> Yeah we went through the same thing and had to bite the bullet and 
>> increased the nsca and nrpe buffer sizes all at once across the 
>> board.  It was painful, but once done it was done.
>>
>>
>> Dan
>>
>> *From:*Andrew Widdersheim [mailto:awiddersheim at hotmail.com]
>> *Sent:* Wednesday, January 11, 2012 7:33 PM
>> *To:* mike-nagios at 5dninja.net; nagios-devel at lists.sourceforge.net
>> *Subject:* Re: [Nagios-devel] nsca-2.9 compatability
>>
>> I haven't looked at NRDP much more than you have but it sounds like 
>> it would be a fix to many of NSCA's short comings. The problem for us 
>> is the chore of switching everything over in one shot.
>>
>> We don't do that much passively so the check results queue feature is 
>> actually an extra bonus for us in the upgrade. We are actually more 
>> interested in the longer output. If there is an easy way to make this 
>> more compatible for with older versions than great. If not we can 
>> plan a large upgrade of everything or a cut over to NRDP. We just 
>> have a problem now and were looking for a quick solution without 
>> breaking already existing stuff.
>>
>> -Andrew W.
>>
>> ------------------------------------------------------------------------
>>
>> Date: Wed, 11 Jan 2012 15:38:44 -0800
>> From: mike-nagios at 5dninja.net <mailto:mike-nagios at 5dninja.net>
>> To: nagios-devel at lists.sourceforge.net 
>> <mailto:nagios-devel at lists.sourceforge.net>
>> CC: awiddersheim at hotmail.com <mailto:awiddersheim at hotmail.com>
>> Subject: Re: [Nagios-devel] nsca-2.9 compatability
>>
>> On 1/11/12 11:16 AM, Andrew Widdersheim wrote:
>>
>> I wanted to use Mike Lindsey's new features in nsca-2.9 but found 
>> that clients on 2.7.2 were not able to communicate after updating the 
>> server. I found this on the Nagios bug tracker:
>>
>> http://tracker.nagios.org/view.php?id=78
>>
>> >From what I'm reading it's not possible to have a client and server 
>> compiled with different MAX_PLUGINOUTPUT_LENGTH. Has this been fixed 
>> at all and I'm just not finding it?
>>
>> As far as I'm aware, there's no easy fix for this.  If you cannot 
>> upgrade your clients, then you can recompile the nsca binary with 
>> MAX_PLUGINOUTPUT_LENGTH set back to 512.  That should let you use the 
>> checkresult directory feature, without breaking compatibility with 
>> older clients.
>>
>> I'll take another look at the source and see if any options jump out 
>> at me, but I don't know how much effort I should put into it - I 
>> think Andreas is actively working on a Better Solution.
>>
>> -- 
>> Mike Lindsey
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>>
>>
>> _______________________________________________
>> Nagios-devel mailing list
>> Nagios-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>
> -- 
> Eric Stanley
> ___
> Developer
> Nagios Enterprises, LLC
> Email:estanley at nagios.com
> Web:www.nagios.com  
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
>
>
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel


-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:  michael.friedrich at univie.ac.at
phone:  +43 1 4277 14359
mobile: +43 664 60277 14359
fax:    +43 1 4277 14338
web:    http://www.univie.ac.at/zid
         http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org


------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2