[Nagiosplug-devel] Obsoleted contrib and tarballs files

[sean finney]

hi ethan,

On Mon, Jun 27, 2005 at 05:31:14PM -0500, Ethan Galstad wrote:
> Timing out can be useful, and not just for debugging purposes.  This 
> should definitely stay in the plugin distribution - I'm not planning 
> on taking any plugins back into the main Nagios distribution.  If its 
> still there, check_dummy should stay as well.

i agree, but it would probably be more appropriate to segregate these
debugging plugins into a seperate location other than 'contrib' or the
main plugins directory.

> Also, it seems like there should be more input from plugin developers 
> and users before a whole swath of plugins gets nuked from the CVS 
> repository.  Unless the complete functionality of some of the 

perhaps that was a bit heavy handed of me.  however, these were all
'contrib' plugins, and i guess i take a slightly different attitude
towards these vs. the 'official' plugins.  also, when i signed on the
nagiosplug team, the initial area where i was going to focus my efforts
was bug-fixing and code cleaning, to which i feel this is an extension.

i was basically operating on the assumption that these are buggy and
not frequently used plugins and no tears would be shed about their
disappearance.  it is worth pointing out that if someone wants it back,
it can always be resurrected from the attic (or in some cases preferably
re-written).

also, i do agree that there should be more communication.  between the
plugin group and the nagios core as well, for that matter--the current
discussion of developing a more robust plugin api, is a good example.
however the lists have been fairly quiet as of late...

> should they be removed?  Sure, check_ftpget.pl and check_dl_size.pl 
> (for example) may be insecure or inefficient, but so what if those 
> are the things you need to monitor as an admin?  I'm sure there was a 

in that case, the version from the official 1.4 release could still
be used.  and of course the nagiosplug developers would appreciate
hearing from said admins with either a comment like 'wtf? i need this
plugin!', or more preferably a new version of the plugin.

> valid reason that someone submitted the check_rbl.c plugin and 
> related friends.  If someone needs the functionality those plugins 
> provide, why should we nuke them?  Just my two cents.

about the check_rbl.c, this is perhaps true.  i don't know enough
about what it's doing wrt the rbls (and how what it does differs from an
equivalent check_dns), but do know enough to be concerned about providing
what might turn into a headache for rbl server admins when the number
of nagios installations running check_rbl every 5 minutes slowly starts
to grow.  perhaps something could be done on our end to discourage that
behavior and still provide the desired functionality--like have
check_rbl require a --not-abusive option that has to be passed to
function, and if not passed exits with a warning telling them to make
sure not to check too frequently or whatever and use the option.  an
idea, anyway.  perhaps someone with more knowledge of the plugin can
comment?


	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/20050627/e83b9070/attachment.sig>