vanished bug numbers in the nagios mantis tracker

[Andreas Ericsson]

On 08/03/2012 05:15 PM, John P. Rouillard wrote:
> 
> 
> 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.
> 

That would be pretty awesome, but "adding items to the object" is simply
not possible. C-objects are carved in stone once the code is compiled,
and nothing but the module will ever know or care about the extra data.

> 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.
> 

Well, no. You might want to add things other than flags in such variables
and you may well have several modules at once competing for the dubious
honor of putting extra junk into objects.

> 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?
> 

No, and in time for Nagios 4 I doubt we'll do that since it doesn't
really require a major version bump to be added and I just don't have
the time for it right now. Patches are ofcourse welcome, but please
make sure to base them on top of latest svn from sourceforge, or the
git repo at www.github.com/ageric/nagios

It would be neat if we could alter the way modules are loaded though,
so one can pass parameters to them in a sane(r) way. Preferrably to
allow users to pass core-grokable parameters that we add later.

> 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.
> 

Well, no, they can't, because if several modules use the same mechanism
they'll overwrite each others data or be unable to find their own.
Unless you mean for the objects to have some sort of marker for each
module, but that's just overly complex.

> 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....
> 

In my mail to Janne Aho, I suggested adding an 'id' field to all
objects. That would allow modules to utilize indexed arrays or large
bitvectors to mark certain properties in objects and look them up in
O(1) time without having to compute a hash and deal with collisions.
If we couple that with a mechanism allowing one module to obtain the
pointers of another module, any module that wants to know about
another module (such as for example livestatus wanting to know which
mod_gearman worker executed a particular check) can just grab the
ancillary data of that module and look it up in constant time.

This means that either mod_gearman has to maintain a key/value vector
for livestatus to use (or some other common form that all modules
know about), or that livestatus has to know about the other module's
dataformat, but it's pretty much the best we can do to allow constant
time lookups of ancillary data.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
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/