vanished bug numbers in the nagios mantis tracker

John P. Rouillard rouilj at cs.umb.edu
Fri Aug 3 17:11:23 CEST 2012


In message <501BDA9E.8070606 at op5.se>,
Andreas Ericsson writes:
>On 08/03/2012 10:27 AM, Wim Hoekman wrote:
>> On 2012-08-01 10:37, Andreas Ericsson wrote:
>>> This one might resolve itself in Nagios 4, when we change how checks
>>> are run. I won't investigate it further until that's out anyway though.
>> The release of Nagios 4 would be a great time to import the Nagios patch
>> I've submitted a while ago.
>> (Subject: Additional image for action_url in host and service
>> definitions patch)
>> 
>> That patch required a change to the object abi, so it was not included
>> in any minor release.
>
> Is there a reason why we just can't make this a custom variable with
> special meaning in the UI?
>
>I'm especially uninterested in patches that move more UI code into the
>core, since that's something that really should be going away rather
>than increase.

One of the things that frustrated me to no end when creating the
external correlation event broker
(http://www.cs.umb.edu/~rouilj/sec_nagios/nagios_sec_manual.txt) was
that the broker architecture provided no mechanism for the plugin to
add items to the objects and provide parsers for the objects in config
files.

Custom variables help a little bit but introduce the need to parse the
value on every event which is not acceptable. The value should be
parsed once into a quickly accessible form (e.g. bitfield) and carried
around with the object.

Are there any plans to add something like:

 add_new_custom_variable_property(SERVICE_OBJECT, "_ec_active_action", \
    func_parse_ec_active_action);

  where:
      void * func_parse_ec_active_action(char * property_name,
                        char * property_value) 

 int add_property_value(*service_object, "_ec_active_action", void * value)

 void * get_property(*service_object, "_ec_active_action");

to allow the brokers to register parsers for specific custom
variables?

I envision the parsed properties (returned as a void *) are stored in
a linked list or array in the object struct and simply store a propery
name and a pointer to some blob returned by the
func_parse... function. The blob is opaque to nagios and only has
meaning to the event brokers.

This way brokers (and other plugins too) could add new data to the
internal objects without having to break abi compatibility.

This also neatly (IMHO) works around the issues with serializing the
object to disk as the custom variable mechanism can pass the info
around to only those who are looking for it. In most other
applications, the overhead of parsing the custom variable's value
isn't a huge issue but in the event broker loop....

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/




More information about the Developers mailing list