[Nagiosplug-devel] check_by_ssh patch

[Andreas Ericsson]

Karl DeBisschop wrote:
> On Wed, 31 Mar 2004 09:26:13 +0100
> Howard Wilkinson <howard at cohtech.com> wrote:
> 
> 
>>Karl,
>>
>>my approach has been that we should make the plugin writers life
>>easier, even if learning a bit more about how to write a plug-in
>>becomes a necessity. So I am looking to replicate the framework
>>approach from Perl into C. 
> 
> 
> Remember that the plugins are C not C++.
> 
> That being said, moving the burden of creating consistent code to
> utils.c is generally a concept I support, having already written the
> type checks and a variety of other functions to do that in utils.c.
> 
> Of course I'm hoping to focus on releasing 1.4 before trying to
> incorporate the large amount of code you have just submitted.
> 
> Of course this comment does not answer the question I originally posed.
> Currently you have chosen to go against published developer guidelines
> and make usgae lines more than 80 chars long in order to meet the
> requirement of your configuration generator. I'm still wondering if the
> configuration info could be genrated from the source rather than from
> the compiled executable.
> 
> 
>>Big advantage that C will have is that it
>>will be able to lots of things at compile time, that Perl gets to do a
>>invocation time. Big disadvantage is the library will be a much larger
>>body of work and I am putting it off until I can assume I have the
>>Perl framework sufficiently stable to act as an exemplar of what to
>>achieve if not a how to achieve it. I have thought about using a
>>embedded Perl interpreter in the 'C' code plugins. But I assume this
>>would go down like a lead balloon for performance reasons!
> 
> 
> In my mind, perl is the way to write good plugins. When epn is fully
> stable, there will be a fairly little reason to keep the most of the C
> plugins alive. Right now, however, the basic reason to keep the C
> plugins alive is for performance. So yes, performance hogs in the C
> plugins will be strongly resisted.
> 
Apart from the fact that not everybody has perl installed, and that it 
is a fair amount slower (even with the epn) than a properly written 
C-program. Also, Perl isn't, and never will be, an industrial strength 
programming language. This means that some things just can't be done 
without C-coding anyways.

If I understand the epn correctly, it will cache compiled images of 
every perl script it needs to run in memory and then pass the 
precompiled image to perl (correct me if I'm wrong here), so every time 
Nagios forks it will copy the cached images along with the rest of the 
stack (the other PTE's are copy-on-write in Linux, but other OS'es may 
have to copy these as well).

If we set all that aside there is still the issue of having every bug 
ever intoduced in Perl spread to every plugin written in it (currently 
mostly temporary filehandling stuff).

Also, what happens if one or more perl-scripts need to be setsuid?
Will Nagios have to run as root, or will the epn be able to handle it 
properly?

> --
> Karl
> 

-- 
Mvh / Best Regards
Sourcerer / Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se