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:[email protected]]
>> *Sent:* Wednesday, January 11, 2012 7:33 PM
>> *To:* [email protected]; [email protected]
>> *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: [email protected]
>> To: [email protected]
>>
>> CC: [email protected]
>> 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 active
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]