vanished bug numbers in the nagios mantis tracker

[Andreas Ericsson]

On 08/07/2012 10:22 PM, William Leibzon wrote:
> On Tue, Aug 7, 2012 at 12:56 PM, Andreas Ericsson <ae at op5.se> wrote:
> 
>> On 08/07/2012 07:24 PM, Jochen Bern wrote:
>>> On 08/07/2012 03:21 PM, Andreas Ericsson wrote:
>>>> [...] Each module gets to keep its own data and Nagios doesn't need to
>>>> know anything at all about it (although it would be neat if it could
>>>> issue a callback and get a key/value vector when printing status data).
>>> [...]
>>>> It would ofcourse be nifty if modules *did* know about each other's
>>>> data, assuming they explicitly request it, but that's not what you're
>>>> talking about so let's ignore that for now.
>>>
>>> FWIW (and not that I've ever coded such a thing myself), if two modules
>>> would *want* to share data, all they would need beyond the OS' shared
>>> memory support would be unique module IDs, a means to coordinate startup
>>> priority (so that the module that actually *creates* the shared memory
>>> can do so before the "user" modules ask for it), and a means of
>>> user-module---to-nagios-core---to-creator-module "hey creator module,
>>> hand me the necessary access data!" requests. Assuming that there are no
>>> "malevolent" modules you have to protect the same data against, that is.
>>>
>>
>> That is over the top. The idea suggested by John is really good to find
>> random module pointers. The using module needs to know about the data
>> from the module it uses anyway, and a one-time lookup from all loaded
>> modules is no big deal. And the list is already there, btw.
>>
>> So we'd add something like
>>
>>    void *nebmod_get_ancillary_data(const char *module_id);
>>    int nebmod_set_ancillary_data(const char *module_id, const void *ptr);
>>
>> to nagios core. The writing module uses the set call. The reader
>> module uses the get call. Both provide the same module_id and the rest
>> happens automagically.
> 
> 
> I think we need more than this. First of even going with above two calls
> backs, the call syntax is just not enough - need to be able to ask for data
> pertaining to specific service/host/etc and not just by some id. And I'd
> rather not have to make an extra call back to get an ephemeral id.
> 

The ancillary data from one module will ofcourse contain the indexed arrays
with information on all hosts and services.

> That's why I agree with original thoughts of being able to add "named"
> extra data to service/host/etc. And this is not just for use of one module
> but something that other modules are expected to be able to ask for. This
> allows to extend nagios with modules rather than adding features into core
> which is a right way into the future. In fact I'd go as far as advocating
> allowing modules to add new config parameters in the future i.e.
> registering callback function to process "newconfig = ..." parameters.
> 
> And as far as ordering, I don't think it is a big issue. All that is needed
> is for nagios to provide a list of loaded or loaded-to-be modules and this
> is already created by nagios before modules are loaded. Most of the time
> we'll have one module creating extra data and several others who would be
> using/reading it; and reading should then happen after initiation when data
> is there. Rare case when two modules may want to modify the same data
> should either be avoided entirely or synchronization left to those writing
> such modules with additional parameters to be passed that specify ordering,
> etc.
> 

That would still mean linked-list traversal and X strcmp() calls for each
module that wants to get ancillary data on some object. Please keep in
mind that this is expected to happen about 5000 times per second for a
large network, so awesome performance is an absolute requirement rather
than something that would be nice to have.

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