[Nagiosplug-devel] Kickoff for 1.5

[Andreas Ericsson]

sean finney wrote:
> hi ton,
> 
> On Tue, Mar 08, 2005 at 08:03:27PM +0000, Ton Voon wrote:
> 
>>I don't personally use SNMP, but it does feel like there are a lot of 
>>redundant pieces. There probably needs to be a bit of thought in how it 
>>hangs together.
> 
> 
> my thoughts exactly.  i don't claim to know the best way to proceed
> with this, but would like to help find out :)
> 
> 
>>What exactly do you think needs doing? Subendu is the resident expert 
>>in SNMP, so I'll leave him to decide the direction here.
> 
> 
> i think there are a few facets to this:
> 
> - availability/selection of snmp plugins
> 
>   bringing in as many snmp-like checks as possible.  for unix hosts
>   there's all kinds of stuff in the ucd/net and host mibs.  i could
>   build a list if it'd be helpful.
> 

It most likely would. If it's standardized things it would be most 
useful to have the OID's. It's faster to use and doesn't require the MIB 
to be installed.

> - consistancy of snmp plugin interface
> 
>   common cmdline interface, normalized cmd naming scheme.  there'll be
>   some cmdline options that will be common to every plugin (community,
>   snmp version, host, port), and some that aren't.
> 

Naturally. I was thinking -C to mean credentials and supply 
username,password for snmp v3. SNMP v3 would be marked with the 
inclusion of the authentication method (authpriv and that sort of thing).

> - consolidation of duplicate code
> 
>   depending on what we learn from the above two, it might make
>   sense to develop a common code base to reduce code redundancy.
> 

This is an area where much can be gained. The plugin devel api today 
isn't very useful.

For spawning commands, there should be a function that takes as input 
the command line, and returns the output and return code of the command. 
This would accomplish much and get rid of a LOT of duplicate code in the 
plugins.

For snmp, there should be a function that takes a snmp_auth struct 
(which needs to be invented) and a list of oid's to fetch, and then 
returns the values of those oid's in an array.

For argument validation, many of the functions just check to see if 
another function can be used to retrieve a value, when it in fact could 
retrieve the value all by itself and just let it go at that. 
is_int_nonneg() and the likes are just plain dumb. Why they made it into 
the plugin distro in the first place is more than I understand.

For argument parsing, the getopt_long function might be all good and 
well, but it's behaviour on various systems is undocumented (some break 
parsing on first non-option argument, other reorder nonopts to be last 
and just keep going). I've written a function which takes identical 
input and is fully compatible in simple parsing but handles non-option 
arguments identically on all systems (by populating a linked list of 
strings). It also has support for obscuring sensitive arguments, such as 
usernames and passwords.


Lately I've become fed up with the official plugin distribution. The 
number of distributed bugs in allegedly stable releases is just too much 
work to sort out, so I've started hacking up my own framework into which 
I'll import the current plugins whith changes as necessary.

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