[Nagiosplug-devel] Re: Perl plugins that fail gracefully by reporting missing modules.
Paul L. Allen
pla at softflare.com
Sun Mar 7 14:35:00 CET 2004
Stanley Hopcroft writes:
> I am writing to suggest that Perl plugins can be made to fail gracefully
> when the pre requisite modules are not found on the host.
But there are so MANY ways things can fail if clueless people are
involved. It is impossible to make things idiot-proof because idiots
are so resourceful.
> 1 the FAQ about especially /contrib plugins that
> fail when Perl cannot find utils.pm in the standard Perl search paths.
It's a nice touch, if it doesn't compromise performance too much. Other
perl plugins do check for the existence of utilities they (and they alone)
depend on. But utils.pm is used by EVERY well-written perl plugin, so
having them all check that it is loadable puts an unnecessary performance
hit on all of them. Once you first run the first perl plugin on a box
you know if utils.pm is there or not and every subsequent run of that and
every other perl plugin conducts an unnecessary check that utils.pm is
there.
> 2 distress when a plugin is put into production after testing in a
> directory containing the prereqs and thereupon no longer has access to
> those modules.
If you follow the installation instructions to the letter you do not end
up in that situation. If you do not follow the installation instructions
to the letter then you do so because you think you know how to deal with
the consequences and are prepared to deal with them. Yes, there is a
third possibility: that you are so completely clueless that you do not
know how clueless you are and therefore think you can ignore the
instructions AND demand help when it all goes wrong. I have little
sympathy for those who wilfully follow the path of stupidity.
[...]
> The eval { } _is_ a performance hit, but it may be worth it. If the
> performance hit is thought too severe, the checks could be enabled by an
> option ....
Since the installation process munges certain things in the perl plugins,
I'd prefer an install-time check. If everything looks good, install
the plugin; if there are detectable problems then install a dummy that
says "this plugin was not created at installation time because of blah."
That would be especially good for the C plugins, which just don't get
built at all if dependencies are missing. This way you'd get to see
that check_blah exists but if you try to run it then it explains that
there were dependency problems. As it is, you just get missing plugins
and nothing to tell you that if only you had the right dependencies you'd
have had the pluging you wanted. Since a common way of seeing what
plugins are available is to look in libexec, plugins that don't get
built because of missing dependencies often create a misleading impression.
It would be better to have a check_snmp that returns "This plugin is
unavailable because of missing dependencies" than no check_snmp at all.
The down-side with install-time checks for perl plugins is they won't catch
run-time problems. But if you follow the installation instructions to the
letter, and don't try to do clever things you don't know enough about to
do successfully, then an install-time check will catch the problems.
I am all for idiot-proofing, but not when it causes performance issues
and the people with a need to use it are theoretically not idiots. Nagios
is not for the average computer user. It's for people with a need to
monitor network services and requires root privileges on a *nix box to
install and run. I do not believe it unreasonable for the software
to assume that the people installing it do actually understand network
services and know enough about *nix that they deserve the root password.
These days it may be unrealistic to assume that, but I still think it is
not unreasonable.
Now if you were to propose a test at build time that checks the person
doing the installation understands the underlying concepts of *nix
shell, Apache web server, etc., and refuses to build unless the score is
high enough, I'd whole-heartedly agree. But others, including Ethan,
would disagree so I won't suggest that. I'll just think it... And dream
of LARTs...
--
Paul Allen
Softflare Support
More information about the Devel
mailing list