[Nagiosplug-devel] discussion of general plugin framework

[Andreas Ericsson]

sean finney wrote:
> hey folks,
> 
> this is an issue we've been slowly circling around, and the tether
> between us and the issue is getting smaller and smaller, so i might
> as well bring it out in the open for a full discussion.
> 
> so what do we want out of this not-quite-existing API?  here's a brain
> dump of what i can think of:
> 
> functionality:
> 	- common way to run commands and get output, with the options to
> 		- seperate and/or ignore stderr
> 		- grab all output into large blob
> 		- grab all output split line by line
> 		- not grab output but pass handles to fd's (or
> 		  fd-containing structs)

This is more or less completed. It could do with some cross-platform 
testing though.

> 	- common way to perform network based operations, with options to
> 		- connect via various protocols
> 		- specify input
> 		- expect output

This sounds a bit like check_tcp so far.

> 		- match output against strings or regular expressions
> 		- specify an arbitrarily complex pattern of input/ouput
> 		  events in a connection

This sounds a bit like next generation check_tcp (check_net?). I'm not 
entirely sure that an exchange protocol like this is completely useful. 
Most of the common protocols have implementations that doesn't adhere 
strictly to standard. When such implementations are encountered it would 
probably be better to fork the generic plugin and do exception handling 
in separate code. Otherwise there's the risk of making just one large 
plugin which consists primarily of a long series of if() else if().

> 	- snmp related stuff:
> 		- provide as easy of an interface as possible for
> 		  issueing snmp based checks
> 		- support v2c BULK requests
> 		- support v3 authentication
> 		- provide resulting OID arcs as data objects
> 		- provide a way to issue callback funcs on larger oid arcs?

This last one is fairly easy. The mutt (or net-snmp for that matter) way 
of registering hooks for certain criteria works splendidly. It does 
however require a matching structure of some sort. Borrowing from PHP or 
some other high-level script language is most likely the best way to go 
(a struct for all variable types, with a flag telling which one to use).

> 		- provide a means to specify index, name, and values for
> 		  members of tables.
> 		- common CLI options
> 	- general
> 		- common CLI options
> 		- wrapper to getopt to specify plugin-specific options
> 

A long time ago I wrote a getopt() replacement which has the slight 
benefit of parsing options in a serial manner (that is, the first 
argument specified in the parser-list is fetched first from the command 
line). It also supported obscuring of sensitive arguments which could be 
useful and was fairly cheap to implement. I could look into it again if 
there's interest. It could quite easily be modded to auto-generate help 
output from the provided struct.

> language support:
> 	- C: development headers and dynamic libraries
> 	- Perl: Nagios::Plugin class/namespace?
> 	- shell/python/other?
> 

C++? I don't write anything in it personally (except the occasional nmap 
patch, which is always reworked before submission :) ), but it might not 
be a bad idea to add a couple of
#ifdef __cplusplus
extern "C" {
#endif
statements to some of the header files planned for inclusion.

> documentation:
> 	- relevant API-related updates to the developer guidelines
> 	- list of deprecated functions, cmdline options
> 	- an authoritative list of the official and unofficial plugins?
> 

Brief list of what's reserved. For example, some people don't know that 
POSIX has reserved types ending with _t (socklen_t, size_t, time_t etc), 
or that -W is a POSIX reserved command-line option (actually reserved 
for local implementation, but that's just standardese for "standardized 
to be used in some random way").
Recommend ansi89 functions over their BSD counterpart when such exists 
(memset() vs bzero(), memcpy() vs bcopy()). Compile a list if necessary, 
and use the "poison" pragma on them if compiling with a decently recent 
gcc version.

> 
> of the stuff that i've mentioned, much of the work is already done in
> some form or another.  i'm sure i've missed some things, and i've
> probably injected some subjective opinions into others.  so please
> consider this is more of a discussion to get a final idea of the big
> picture, and feel free to amend the above list appropriately...
> 

Userdata functions:
      - provide functions to actually parse (as opposed to validate)
        user-input. For example;

char *byte_size_suffix[] = { "kb", "mb", "gb", "tb", "pb", NULL };
if(suffix) for(i = 0; byte_size_suffix[i]; i++) {
     if(!strcmp(suffix, byte_size_suffix[i]) value <<= (10 * i);
}


Another thing that might be good to decide on is what standards to 
require in the development environment used for building the plugins. 
Being portable is all good and well, but it can't be allowed to stop 
development.

A test-harness is always nice and more or less required. I know someone 
submitted such a one to the tracker a while back, but I haven't had the 
time to look at it.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer