[Nagiosplug-devel] Re: check_by_ssh patch

Paul L. Allen pla at softflare.com
Wed Mar 31 07:46:11 CEST 2004


Andreas Ericsson writes: 

> Apart from the fact that not everybody has perl installed,

Perl comes with most distros these days.  It may be an optional install
with some of them, but so is the C compiler. 

> and that it is a fair amount slower (even with the epn) than a properly 
> written C-program. 

It depends very much on what you're doing with it.  For number-crunching
it is slower, for uses where it runs, does a few things, then terminates
then the difference can be a lot smaller. 

> Also, Perl isn't, and never will be, an industrial strength 
> programming language.

I wondered if you were a troll when you first popped up here.  Starting a
holy war over programming languages is a typical troll tactic.  And
defining a programming language as "industrial strength" first requires
you to state whether you are basing your definition on programmer
efficiency, CPU efficiency, memory efficiency or other criteria.  Perl
has a lot of stuff that C lacks without adding libraries that are not
a standard part of C.  Useful stuff like data structures, regexes and
memory management.  Stuff that allows perl programmers to be more
productive and means they don't have to take care to avoid buffer
overflows. 

> This means that some things just can't be done 
> without C-coding anyways.

Most things can be done in perl without C coding, although a small number
of them would be a little inefficient. Most, but not all, syscalls can be
handled by perl.  For the few that cannot you need an XS module to provide
the glue.  Since perl is Turing-complete, with a little XS to take care
of the small number of syscalls that return multiple values and which
are not already accessible natively, it can do anything you can do in C. 

> 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

As opposed to every bug ever introduced into the C compiler and libraries,
along with every bug introduced by plugin authors being careless with
buffer overflows and who use printf without a format specification.  You
are surely trolling here. 

> (currently mostly temporary filehandling stuff).

For which there are three solutions.  One of which is not recommended
because it relies upon C's tmpfile(3) implementation - which is broken
on some systems. 

> 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?

Anyone who was in a position to know what they were talking about when
commenting on the deficiencies of perl would know that Nagios does not
have to run as root to run a setuid script.  Not that I would recommend
having a setuid plugin, but if it's absolutely necessary it will run
quite happily.  Well, not happily if you don't know how to write setuid
perl because perl will complain bitterly about data it receives from
the outside world unless you take steps to stop it complaining for each
and every item - something intended to make you consider what you're
doing with that data and whether or not malicious input could do you
harm. 

-- 
Paul Allen
Softflare Support 






More information about the Devel mailing list