Nagios 2.0 Event Broker and DB Support

[David Parrish]

> The service struct is an internal Nagios structure definition which 
> changes between Nagios versions.  If the user module is compiled for 
> use with Nagios 2.0 and it's definition of the service struct, it 
> will have problems if it is not recompiled for future versions of 
> Nagios.
> 
> Off the top of my head, I could overcome this by requiring that the 
> user modules indicate (by calling a function) what version of Nagios 
> they are compiled for.  If they report anything but the current 
> version (or do not report at all), unload them so they can do no 
> harm.

I like the idea a lot, and I can see heaps of potential for some funky
dynamic monitoring stuff..

In the .h file which modules will #include, add this macro:

#define NAGIOS_API_VERSION(x) int __nagios_api_version = x;


Each module must insert (near the top) a nice simple line like:
NAGIOS_API_VERSION(3)


Then, when you dlopen() the module, use something like:

#define REQUIRED_API_VERSION 3
if (*((int *)dlsym(dlhandle, "__nagios_api_version")) != REQUIRED_API_VERSION)
{
	printf("Wrong module version... not loading\n");
	return;
}

to get the version number before you call the init function. If the version
number is not exactly right, don't load the module. I think that will
work...

It might be nice in principal to allow multiple versions or some kind of
backward compatibility, but I doubt it's worth it, for the stability you
could potentially lose.

Just make sure that you increase the api version in the core code whenever
you change it, and it'll be sweet.


Also, on second thought, it might be worthwhile putting in some compiler
checking #ifdef blocks, so that an old version of a module won't compile
with the new headers..

-- 
Regards,
David Parrish
0410 586 121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20030804/9c359ff3/attachment.sig>