[Nagiosplug-devel] discussion of general plugin framework

[sean finney]

hey andreas,

On Sat, Jun 11, 2005 at 01:56:58AM +0200, Andreas Ericsson wrote:
> >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.

yes.  like i said, many of the things i mentioned are already done to
a certain extent.  what i'm getting at is more of the 'big picture', and
the glue that will bring it all together.

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

i think it would be an enhancement to check_tcp, check_udp, and any
other simple network-based plugin.  also, i think i forgot to mention:

		- better support for reading/sending/expecting binary data.

> 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().

yeah, this may be true.  this would be way more effort than it were
worth if any kind of decision making logic had to be incorporated,
and it would be better to fork it off into a seperate plugin.  the
question is whether or not it's worth the effort to define a datatype
and write the functions to support the arbitrary send/expect stuff
for the simple cases.  i'm thinking it may not be, or at least that
it would be just as much code to do it that way as with some normal
if/else statements.


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

i ran across that patch in the tracker a bit back, though i haven't taken
a close look at it.  i'd argue against the merits of commandline
obfuscation though, as there's still a theoretical opening to get
the cmdline arguments and in most cases there's a better way to provide
said credentials.  

> >language support:
> >	- C: development headers and dynamic libraries
> 
> C++? I don't write anything in it personally (except the occasional nmap 

sure... why not? :)

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

all good points.

> 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);
> }

this would be a very nice macro/function to have laying around.

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

i don't think it has any time recently.  granted it's kind of hard
to bugfix on an AIX system when you don't have one readily available,
but i don't think that would keep us from releasing.  of course, a list
of tested environments and recommended/supported toolchains couldn't hurt.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20050615/ca421522/attachment.sig>