[Nagiosplug-devel] discussion of general plugin framework

[Andreas Ericsson]

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

This is fairly simple after all; Just slap on a len variable. If it's 
zero but the pointer to the data is non-null, use strlen() to evaluate 
it. Otherwise use len.

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

process_tcp_request() already exists. It's stupid and obsolescent, but 
it's there.

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

Indeed. That was just some intellectual masturbation (although not very 
satisfying). The ability to parse command arguments in an order decided 
by the programmer might be fairly useful though. It would also get rid 
of the various differences of getopt_long on various systems and 
wouldn't increase loc count (getopt.c is already there).

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

There should be more functions like this. Gathering a single 
command-line argument is a 4-5 lines of code today. It should be 1 (+ 
possibly 1 to deal with failures).

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

getopt_long(), asprintf(). The decisions to use both those were taken 
knowing that it would mean bringing in a lot of code from the outside.

asprintf() is also heavily abused (I've ranted about this earlier). In 
about 90% of the cases I've seen so far, a simple restructuring and 
possibly a call to die() every now and then has sufficed to get rid of a 
whole host of them (don't get me started on the uses it's put to in the 
perfdata functions).

>  granted it's kind of hard
> to bugfix on an AIX system when you don't have one readily available,

This is actually a problem I think it would be fairly easy to fix. When 
I was doing a lot of work with check_icmp I called for help from people 
who wanted to use it. I got access (root, even) at no less than 8 
different platforms. It was for a limited time ofcourse, but I don't 
think it would be terribly difficult to do something similar prior to 
releases. At least not if root-access isn't strictly needed. Also, HP 
has a developer program that lets people sign up for accounts on a lot 
of different platforms and architectures. I've made heavy use of that on 
occasion, and I've begged Sun and Apple to do something similar (to no 
avail).

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

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