[Nagiosplug-devel] Re: Hooray - 1.4 is out! What next?

[Benoit Mortier]

Le Samedi 5 Février 2005 06:20, Stanley Hopcroft a écrit :
> Dear Folks,
>
> Le Vendredi 4 Février 2005 12:17, Benoit Mortier a écrit :
> > Ton Voon wrote:
> > > Well, we've finally got to 1.4. Thanks to everyone who has helped
> > > this release out and helped make this software better.
> >
> > Splendid news. Nice work, fellas.
> >
> > > What's next?
> > >
> > >
> > > For 1.5;
> > > * aim to get rid of output parsing plugins completely. Implement
> > > system calls to get disk/memory/swap/load status instead (the ISC
> > > dhcp suite of
> > > programs have excellent ways of determining system type and
> > > version).
> >
> > that's the way to go ..
> >
> > > * rewrite commonly used perl/shell/python/whatever plugins in C.
> > > (this will in time allow Nagios to load plugins as shared modules,
> > > which can only be a good thing).
> >
> > Yes, i wanted to do that for a long time.
> >
> > > * minimize the perl module dependencies.
> >
> > That would be agood thing
>
> Why ?
>
> You may wish to do this because you are reselling Nagios and the Nagios
> plugins, and want to conceal the fact, or it reduces your installation
> costs. This is not necessarily a bad thing; a slicker install is good.

I do install Nagios ;-) but i do not sell it and my platform is Debian so 
install is a snap.

> However, in 1.4 there have been two attempts at this in check_icmp and
> check_dhcp.
>
> At least one attempt - check_dhcp - is not a happy plugin in all
> enterprise environments. And I am quite clear about whose fault that is:
> mine (and in any case, someone will make it better).
>
> However, if it where implemented in Perl for example, multi-platform
> comes at the cost of either
>
> 1 fork tax (Perl load, compile and execution) if your code uses
> _only_ built in functions (ie no modules)
>
> 2 the expense of installing a module (FWIW, I think CPAN can be
> programmed to automate installation).
>
> Again, people should ask themselves why are they doing this ?

You got a very valid point for this !

> I may be able to write write faster code in C but I can certainly code
> faster in other languages.

Yes sure..

> Also, what one gets is basically a limited function plugin that is less
> likely to distinguish Nagios from its competitors.

Yes and from the user point of view the flexibility is the most important 
with snmp support for some of them.

> The next most obvious disappointment of Tivoli and HPOV (after the cost)
> is the extremely low function. Both products seem to provide highly
> scalable employment opportunities for either consulting, or
> administering giant pollers. Apart from the GUI configuration and the
> self discovery these products have little more to commend them
> (excepting the Tivoli rules engine).

Yes i just come back from solutionlinux at Paris, France and our stand were 
next the standof HP where they demonstrated HPOV ;-) and people keep goin 
to our stand to get new about nagios and the plugins.

The localization of the plugins was one of the most asked question.

> (& both of these features are _useless_ to network owners/admins,
> because people are hired to setup Tivoli or HPOV, and no one is brave
> enough to ever ever change things after).
>
> In my view, plugins should do cool things (or check hot boxes if you
> will); how they do so may be  best left up to the imagination and best
> efforts of those who conceive of how to do the cool things.

Yes plugins should be able to do thing like checking temp, acces to rack, 
fire etc... ;-)

> Here is an example, my employer checks multi-page web transactions
> requiring any and all of
>
> 1 proxying HTTP and SSL
>
> 2 authorisation (by proxy and origin)
>
> 3 scraping content out of one page to pass onto the next
>
> 4 timing
>
> 5 HTMl/XML parsing
>
> 6 GET/POST to web forms
>
> The service checks to do this are built in Perl (or could be Ruby,
> Python) on a custom Perl class (although there are standard ways of
> doing this now).

Great for that effectively perl is the best with the help of cpan.

> And in case this is not compelling, another Perl service check does a
> complete site specific simulation of Win 9x client logon to an NT
> domain: locate Domain controllers, connect to the IPC$ share, read the
> LANMAN.INI script, parse it and connect to shares. This one is built on
> top of a Perl XS class that interfaces Perl to some of the Samba library
> functions and other _C functions_ written specially for this class
> (produce the plugin ? the XS class is not good enough to maintain & the
> LANMAN.INI parsing is not general enough. Also it doesn't test a 2k/XP
> client logon)
>
> The idea of providing this general function in C alone is silly. If it
> weren't, there would be _no_ Java, C++ etc.

Yes you are right, perl should have the some fonctionnality than c or c++.
It means that we should focus on getting basic plugins template for c, perl, 
python, localization should not be restricted to c.

> The fact that my implementation skills are lacking does not invalidate
> the cross language approach.

Of course, mine neither ;-)

> Also, most contemporary scripting language Interpreters can be embedded
> in C providing all the power of the script language to do stuff far more
> concisely than in C.

Yes i have seen that recently with one of mine developper collegue ;-) 

> Have a look at perldoc perlembed for examples of functions to
>
> 1 match character strings
>
> 2 substitute character strings
>
> If examples of their application don't come to mind, look at the huge
> amount of duplicated code in Nagios (eg utils.c) that does things like
> substitute macro values for the macro names, crump illegal characters,
> find things in strings.

Yes that's awfull ;-(

> So sure, perfect the check_dns plugin by using the resolver libraries,
> but remember, you're still only getting RRs.
>
> The way to decide between implementation alternatives is to have an
> adequate view of our objectives and businesses.

Yes we should think more about multiplatform, easier coding, templating, 
localizing.

Have a nice day
-- 
Benoit Mortier
Linux Engineer
www.opensides.be