[Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps?
Dag Wieers
dag at wieers.com
Wed Sep 3 06:27:39 CEST 2003
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]
More information about the Devel
mailing list