Re: [Nagios-devel] New Nagios dev branch?

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

Re: [Nagios-devel] New Nagios dev branch?

Post by Guest »


--Apple-Mail-117--353505498
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit


On 9 Feb 2010, at 11:41, Andreas Ericsson wrote:

>>
>> Any feedback? Some people might think there is a lack of development
>> in Nagios :)
>>
>
> I'm kinda torn on this option. If Nagios is given the option to accept
> check results via a socket rather than from temporary files, there's
> no harm in having the checking daemons sit on a different server, with
> possibly a feeder daemon in between to handle authentication, security
> and multiplexing.

Cheers for the opinion.

This is not about having check results though - that's a completely
different path of logic because if it was a check result then there's
other processing like parent-child dependencies/notifications/event
handlers could be invoked. This patch is about selectively changing or
adding to existing retention data.


> I'm for it, but I feel it would be redundant with a different fix.

I'm fine with ripping it out afterwards if there is a better way, but
I'm erring on the side of functionality now rather than in some
unspecified time in the future.

Ton


--Apple-Mail-117--353505498
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On 9 Feb 2010, at =
11:41, Andreas Ericsson wrote:Any =
feedback? Some people might think there is a lack of =
developmentin Nagios =
:)I'm =
kinda torn on this option. If Nagios is given the option to =
acceptcheck results via a socket rather than from temporary files, =
there'sno harm in having the checking daemons sit on a different =
server, withpossibly a feeder daemon in between to handle =
authentication, securityand =
multiplexing.Cheers for the =
opinion.This is not about having check results =
though - that's a completely different path of logic because if it was a =
check result then there's other processing like parent-child =
dependencies/notifications/event handlers could be invoked. This patch =
is about selectively changing or adding to existing retention =
data.I'm =
for it, but I feel it would be redundant with a different =
fix.I'm fine with ripping it out =
afterwards if there is a better way, but I'm erring on the side of =
functionality now rather than in some unspecified time in the =
future.Ton=

--Apple-Mail-117--353505498--





This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Locked