vanished bug numbers in the nagios mantis tracker

[Andreas Ericsson]

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.

> One thing that needs to be pinpointed for your object IDs, however,
> would be their (guaranteed) lifetime. Should they be persisted until the
> next reload, restart, or even across config changes (say, a host getting
> renamed)? After all, saying that "it's the module's business what data
> to attach to the ID, I don't care" maximizes the chance that someone'll
> write a module whose extra data then suddenly has a legitimate *need* to
> be persisted.
> 

The calling goes like this:

nagios -> modules: Modules, create your ancillary data!
writer -> nagios: Here it is. Enjoy.
reader -> nagios: Ain't got none. Sorry.

nagios -> modules: Modules, get your ancillary data!
writer -> nagios: Don't need any. Thanks though.
reader -> nagios: Ooh, nice, I'll have the data from module X please.
nagios -> reader: Here ya go, son. Enjoy!


At reload (or restart, or shutdown):
nagios -> modules: Modules, release everything that can't persist!
modules -> nagios: righto, releasing right away, SIR!


That last one's already there in the form of an unload event that
modules get when Nagios reloads or shuts down, so only two new
callbacks are really required, although I'm guessing modules can
probably get over those two first steps without us adding any
more callbacks though.


On a sidenote, that's probably the weirdest pseudo-code I've ever
written. I hope you get the idea though.

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