[Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps?

[Dag Wieers]

On Wed, 3 Sep 2003, Karl DeBisschop wrote:

> On Wed, 2003-09-03 at 08:22, Dag Wieers wrote:
> > You can look at the changes I've made at:
> > 
> > 	http://dag.wieers.com/packages/nagios-plugins/nagios-plugins.spec
> > 
> > It's not at all closed to the public :)
> 
> I realize that. But without the explanations that you provide below, it
> can be hard to decide if changes need to be pushed back upstream, or it
> upstrem can do anything to help you. Thanks for your feedback.

I agree.


> > Let me summarize the changes I've made:
> > 
> >  + I added some directives that my buildsystem uses as it seems that 
> >    %configure has a problem with Soapbox and I can't build nagios-plugins 
> >    parallellized.
> 
> what is soapbox?

A sandbox system I wrote to make building packages 'more' secure. See:

	http://dag.wieers.com/home-made/soapbox/


> >  + I added a lot of BuildRequires (RH specific) to help people building 
> >    for RH.
> 
> We try to keep our spec useful for Mandrake and Suse as well. But any
> BuidlRequires that apply generally should probably be pushed upstream
> (it looks like most or all can be).

I understand, conflict of interest ;) Beware that Mandrake mostly uses the 
lib%{name}-devel convention, so most BuildRequires will conflict !


> >  + I had to disable INSTALL_OPTS for building as a user.
> 
> Should probably be pushed upstream as well. Wonder what you're seeing
> that I did not, since I've alway built for RedHat.

Maybe it doesn't apply anymore. ;)


> >  + I change the location for the perl-binary and for the location of the 
> >    plugins.
> 
> The Makefile does this. If it does not work, a bug report would help for
> perl location. For location of plugins, you do not configure in the
> libexecdir, so that's why it does not work for you.

Oh, but I do. The %configure macro expands to something that does 
--libexecdir="%{_libexecdir}". Maybe that is fixed by now, but it used to 
be a problem. You can look in the _buildlogs/ to see what it expands too 
and see if that is ok.


> >  + I also added something to compile 2 extra plugins that came in source.
> 
> Those are in contrib, right? We typically don't package contirb plugins,
> but I'd like to set a goal for the 1.5 development cycle to try and move
> a variety of plugins from contrib to core.

Well, I'm also not in favor of the check_cluster plugin, but we're using 
that because this functionality is missing from Nagios. And we don't have 
buildtools on any of our servers, so...


> >  + During the %install phase I add the utils.pm module to the perl module 
> >    path. (The alternative was to add -I flag to every perl-script that 
> >    needs it.)
> 
> Now that CPAN has a Nagios namespace, we need to redo that, as will you
> (though your changes will be smaller than ours).

Ah, nice to know there's progress there. I don't like this particular fix 
as we put a generic named module in a more generic location. But since 
it's packaged, I don't mind that much as people can see where it comes 
from.


> > I have not. Not for the nagios-plugins anyway. I've mentioned the SPEC 
> > file on the (nagios) mailinglist though, when I announced the packages.
> 
> I'd like to go through this same excercise for nagios as well, if we
> could. Maybe after we release the plugins 1.4 alpha, I'll ask for a
> summary of what you see as shortcomings in that spec and build process.

That would be great.


> > Nevertheless any feedback to improve the configuration or my packages 
> > specifically is very welcome. I've learned that maybe I should put an 
> > updated commands.cfg (from the nagios-plugins package) into /etc/nagios/ 
> > (given that they work and consist of more plugins). But I will not let the 
> > nagios-plugins package change files from the nagios-package. So I guess 
> > the 2 projects have to agree on what files and what configuration they 
> > ship to make it work without manual intervention :)
> 
> We have always done exactly that - that is why nagios ships
> checkcommands.cfg and plugins ship commands.cfg - so the packages are
> independent. The two projects do agree on what file names to use - the
> agrrement is that nagios provides chackcommands, which tries to work
> across many plugin releases, while the plugins may provide more bleeding
> edge examples, but in a different file which the user must select.

Ok, that's what I expect too. But what I didn't know was that the config 
file was still in an old format and that people were actually using it ;)


> It occurs to me now that if the plugins chose command names that were
> non-overlapping with the names in nagios checkcommands.cfg, then both
> files could be included at the same time - that might further reduce the
> need for manual intervention. Many nagios would create an empty
> commands.cfg file in %post so the config would parse, but plugins would
> overwrite it? Just a half-formed thought, but maybe it would help.

Yes, that's exactly what I would do. Even better would be if Nagios 
wouldn't halt if a config-file doesn't exist. (Complain but continu if 
possible) What I also would change is the name. 'commands.cfg' 
'misccommands.cfg' and 'checkcommands.cfg'. That's what I previously 
mentioned as being very confusing. I would also make a good distinction 
between notify-commands and checks.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]