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

[Paul L. Allen]

Hi 

Since I can't find a plugin that checks the clamav anti-virus scanner, I'm
in the middle of writing one, and various questions have arisen.  I can't
find answers in the developer guidelines, nor do any of the plugins I'm
familiar with set any precedents that I can copy.  Since I don't want to
set precedents that the plugin development team would disagree with, I
figured I'd better ask for opinions first. 

 The first question arises from the fact that I need an auxiliary file
 and I don't know of any officially-sanctioned place to put it.
 Specifically, I want the eicar test 'virus' so that I can run clamdscan
 on it and check that it is identified as a virus.  So where to put it?
 If the plugin makes it into the standard distribution then configure can
 create a directory for it, such as /usr/local/nagios/share, or
 /opt/nagios/share, or whatever, in a way that accommodates custom and
 practise on various distros.  But until that happens I'd like to know
 where to put the eicar file. 

 My gut feeling is that somewhere in /usr/local/nagios (or whatever the
 equivalent is on some exotic flavours  of *nix) would be best simply
 because the plugin can use a relative path which can be hardcoded rather
 than having to have configure substitute the appropriate absolute path
 which would be needed with /opt/nagios/share (or whatever it is on exotic
 platforms). 

 The second question is that, assuming a path relative to
 /usr/local/nagios (or equivalent on some flavours of *nix) is the way to
 go, should it go in an existing sub-directory or a new one?  The utils*
 stuff lives in libexec, but those files are common to many plugins.  I'm
 not sure I like the idea of polluting libexec with files that are
 specific to one plugin.  The share directory seems like a better choice,
 but the share directory is used essentially for nagios static html.  If
 we go down that route I'd suggest share/plugins would be better than
 polluting the share directory directly, but that requires changes to
 configure (if my plugin makes it into the standard distribution) or
 manual directory creation (if my plugin ends up in contrib or on
 nagiosexchange). 

 So far this is the only plugin or plugin-to-be that I know of that
 requires something like this, but I'd rather the developers make a de
 jure decision rather than me set a de facto precedent.  "Shove it in
 libexec" or "we'll have configure create a share/plugins sub-dir if
 needed" or "shove it here" or "$%#! off" are the alternative answers.
 Decide amongst yourselves and let me know. 

 The third question is not relevant to my check_clamav plugin-to-be but
 I can see that the question might arise in the future and it is related
 to my previous questions.  What if a plugin needs some sort of
 configuration file?  What I'm thinking of is a plugin that requires
 multiple options for each host it checks, so many options that it's
 impractical to specify them individually in service definitions, so that
 the plugin refers to the config file and uses host X service Y to pick up
 the required info.  We pretty much have this situation with one of the
 contributed MS SQL checks which uses freetds - you specify a server in
 the check and freetds looks up the details of the server.  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. 

 The obvious place to put such a config file would be
 /usr/local/nagios/etc (can I stop mentioning 'or equivalent on exotic
 flavours of *nix' yet?) but I really dislike the idea of polluting that
 directory with stuff specific to individual plugins.  There's no rush in
 answering this one because (as far as I know) the need has yet to arise.
 But maybe it would be a good idea to come up with an answer in advance
 while dealing with related issues (like where do I put my eicar file). 

 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
 determining if the clamav virus database is up to date is to run
 freshclam and examine the exit code.  For all SANE installations of
 clamav this will not be a problem, even though the clamav FAQ implies
 that you must not run freshclam more than four times an hour.  Having
 looked at how freshclam works, and having confirmed my conclusions with
 the clamav development team, there is absolutely no problem running
 freshclam as often as you want PROVIDED that you are running a reasonably
 recent version of clamav and PROVIDED that freshclam uses the default
 DNSDatabaseInfo mechanism and PROVIDED the DNS on your nagios machine is
 not well and truly borked so that ignores TTLs. 

 The DNSDatabaseInfo mechanism checks TXT records with 900s (15 minute)
 TTLs so you'll never query clamav's DNS servers more than 4 times an hour
 no matter how frequently you run freshclam PROVIDED you do it right.  If
 your setup is borked in some way and you end up doing a DNS query against
 the clamav DNS servers more often than that then you risk being blocked.
 And if you try to download the virus signatures repeatedly there is no
 question about it, you'll be blocked. 

 According to the clamav docs there are systems out there that are this
 borked, so I want to make it VERY clear that you really should make sure
 that your freshclam configuration won't hammer the clamav nameservers
 (or, worse, their webservers for the virus databases) if you run
 check_clamav.  Yeah, I can (and will) make some reference to this in the
 -h output (but not everybody reads that, as we all know).  And I also
 want to make it clear that you shouldn't rely on check_clamav to update
 your virus definitions but that you should have a cron job on the server
 running clam to do it - if check_clamav happens to update the definitions
 ahead of the cron job that is a bonus. 

 So the question is do we have any place for readmes?  Do we have any
 conventions for plugins saying "you really have to check this before
 you run me and after you've checked it you can create a file with this
 name *here* and I'll do the checks instead of returning critical all the
 time."  Again we're back to where to put auxiliary files, in this case
 one called "I_understand_that_running_check_clamav_may_get_my_server_
 blocked_from_updates_if_my_freshclam_setup_is_borked" (or whatever). 

Oh, I ought to mention, for the benefit anyone who thinks that I ought to
test a known virus-free file with clamdscan and check that the file is
indeed free of viruses according to clamd, that I don't need a special
location for the known-good file.  I can run clamdscan on the plugin
itself.  If clamd ever thinks that plugin is infected you have major
problems. :)  I know where the "good" file lives, I want to know where
the "bad" file ought to live. 

-- 
Paul Allen
Softflare Support