[Nagiosplug-devel] Re: Auxiliary files required by plugins and other questions

[Paul L. Allen]

Hi Sean 

> On Tue, Jul 19, 2005 at 10:58:56PM +0100, Paul L. Allen wrote:
>> But until that happens I'd like to know where to put the eicar file. 
> 
> i'd say ditch a default place and provide a cmdline flag to specify the
> file.

I'd considered that.  There are several disadvantages that I can see: 

 1) It bulks up the command-line.  Not a big problem if you're just
 checking the localhost or using check_by_ssh to check remote hosts and
 make intelligent use of checkcommands.cfg.  A slightly bigger problem
 with NRPE, particularly if you're using NRPE to monitor hosts behind a
 firewall, which means defining check_clamav_host1, etc. 

 2) The end user has to locate a suitable tame virus file.  With a
 default location the tame virus could be part of the plugin tarball. 

 3) It's easy for somebody to omit doing, either through laziness or
 because they don't read the plugin help (we both know the latter happens
 a lot).  I think checking a tame virus is a pretty essential sanity
 check of functionality/virus signature generation.  Put it this way, if
 ever clamav's virus signatures got messed up in such a way that it was no
 longer recognizing viruses, we'd get a lot of irate phone calls.  And
 maybe a claim for damages if a virus got through and infected somebody. 

But if there's no enthusiasm for a default location for files like that
then I'll have to come up with some other method. 

>> Decide amongst yourselves and let me know. 
> 
> yeah, there are a couple ones close to this, like check_rrd, which
> i believe has the rrd location specified via cmdline.  i think others
> have been written that are more stateful and not accepted because of it.

Hmmm, does that mean that some stateful plugins that might be of use to
others have been turned down simply because nobody has defined default
locations for state info? 

>> If this were converted to some sort of native check then for people
>> checking many servers it would be sensible to have a configuration file
>> similar to the freetds one. 
> 
> if either freetds or ms sql has a standard configuration file format
> (for example, like mysql has my.cnf format files)  i think providing a
> cmdline option to use it is fairly acceptable for situations where you
> don't want to specify all the info via the cmdline.  

I didn't make myself clear enough, sorry.  Currently there is a contributed
script for checking MS SQL which runs freetds.  Freetds has a configuration
file which defines the servers it can access giving username, password,
protocol version.  If somebody were to come up with a self-contained MS
SQL check in C to eliminate the need to install freetds then it would
probably require a similar configuration file if you had lots of servers
to check - it's nicer to call check_mssql -x wibble than it is to call
it with -u foo -p bar --version 7.0 for dozens of hosts. 

Of course you could use the same location, filename and format as freetds,
which makes switching a lot easier.  But the location of the freetds
conf file is specified when you install freetds so a plugin can only make
a guess as to where the conf file is whereas freetds itself has that
location compiled in. 

> i really think the best approach is to not have a hardcoded location
> (most distributions providing nagios plugins use different locations
> anyway)

That's why I did suggest locations relative to the existing nagios
root.  That way it doesn't matter if the root is /usr/local/nagios or
/opt/nagios or /home/fred/nagios or whatever. 

> and instead provide a way via the cmdline to specify said files.

Or come up with some other devious mechanism.  Which I just have.  :)
I'm just trying to decide if it's an elegant hack or something too evil
to see the light of day.  Since utils.pm ought to be present and free of
viruses on any plugin installation that makes use of perl plugins (which
check_clamav will be) I can use that as a known clean file.  Which means
I can embed eicar or similar in check_clamav itself.  It does make it
rather hard to mail patches around, though... 

>> The fourth question is what do I do with a readme that is essential to
>> the plugin?  The easiest, and most sensible, and most accurate, way of
> 
> i guess put it in the documentation somewhere :)

And the default directory for that is where? :) 

-- 
Paul Allen
Softflare Support