[Nagiosplug-devel] check_mailq Option to specify mail queue dir.

RyeR at schneider.com RyeR at schneider.com
Tue Mar 23 07:39:00 CET 2004


To all,

Has there ever been any discussion of adding a option to the check_mailq
checker to be able to specify a mail queue directory?  IE mail -O
QueueDirectory=/var/spool/mqueue2.

If not I was going to look at adding the option to the perl code.  We have
the need to check the size of non-default mail queues.

Thanks,
Ralph



                                                                                                                                                     
                      Stanley Hopcroft                                                                                                               
                      <Stanley.Hopcroft at IPAustralia.Gov        To:       Howard Wilkinson <howard at cohtech.com>                                       
                      .AU>                                     cc:       Karl DeBisschop <karl at debisschop.net>, Ton.Voon at egg.com,                    
                      Sent by:                                  nagiosplug-devel at lists.sourceforge.net                                               
                      nagiosplug-devel-admin at lists.sour        Fax to:                                                                               
                      ceforge.net                              Subject:  Re: [Nagiosplug-devel] Access to CVS as a developer                         
                                                                                                                                                     
                                                                                                                                                     
                      03/21/2004 05:04 AM                                                                                                            
                                                                                                                                                     
                                                                                                                                                     




Dear Gentlemen,

I am afraid I don't like the look of what I see in check_apache.pl.

My quick first reaction is

1 Code that is likely to be replicated in _each_ plugin

2 Code of questionable utility.

This is a general comment on the Nag plugin approach of rigorously
checking options and so on. This may violate the 'be gracious with what
you accept' policy. OTOH, it may preserve POLA. My stance is check the
plugin specific options that matter to the plugin and let the user worry
about the consistency and sanity of the others: the 'out of here
approach' as used by many CGIs.

There is some infrastructure in embedded Perl to trap the 'out of here'
cases.

3 An approach to providing function that I have no sympathy with.

If I am mistaken please forgive me, but it seems to me that extra
function is added to the plugin rather than in a common base elsewhere.

Would doing so in an object infrastructure or at least a procedural
framework like utils.pm/.sh be a better approach ?

This could even be done in C/C++ for performance, and other language
bindings added (eg a Perl XS object for Perl plugins)

Again, I would be delighted to have this corrected, but it seems this
approach raises the bar or cost of entry of 'standard conforming' Nag
plugins, since plugin authors are expected to do more than they are now.

Lastly, I don't expect these remarks to be taken seriously for obvious
reasons (lack of effort, understanding, ...) but I am concerned that
effort is being made to provide really good useful features in a way
that I won't be able to or choose not to - code bloat reasons - take
advantage of.

I hope this is _not_ what you are proposing, but I can't see any of the
words that I have found promote reuse and reduce both development
and maintenance effort, namely 'class/object' and or 'library/useful
routines'. In my practise, unprofessional and stupid that it is, I have
always ended up rewriting procedural interfaces - or living with the
drawbacks - but can keep on copying constructor and method calls, even
for second rate classes with interfaces that suck, till the cows come
home.

If I have misunderstood, I apologise.

Lastly, your effort and plans impress me no end. Well done ! But I don't
want my plugin output in XML, I think.

Yours sincerely.


--
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagiosplug-devel mailing list
Nagiosplug-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null









More information about the Devel mailing list