[Nagiosplug-devel] Auxiliary files required by plugins and other questions
Paul L. Allen
pla at softflare.com
Tue Jul 19 15:04:00 CEST 2005
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
More information about the Devel
mailing list