[Nagiosplug-devel] discussion of general plugin framework
Andreas Ericsson
ae at op5.se
Fri Jun 10 16:59:12 CEST 2005
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
More information about the Devel
mailing list