[Bug 693608] Review Request: icinga - System Monitoring Application
bugzilla at redhat.com
bugzilla at redhat.com
Mon Jun 20 16:05:21 UTC 2011
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #11 from Michael Friedrich <michael.friedrich at univie.ac.at> 2011-06-20 12:05:19 EDT ---
(In reply to comment #10)
> I have created two Spec-files. The first one I have left the permissions
> unchanged so icinga can read and write its configs, but I don't see why this
> should be needed so I have created the second one.
Thanks, I'll have a look what I can merge into the upstream available
2 more topic to discuss ...
1) the so called "icinga api" is mainly a php based abstraction layer on the
idoutils rdbms. shouldn't this be renamed into "icinga-phpapi" in their
respective package name (if you consider adding this from scratch)? i can't
change that in the official spec file but e.g. debian maintainers did due to
the nature of its behaviour.
2) the newly introduced "module definition" in 1.4.0 -
https://dev.icinga.org/issues/162 can now be used to load neb modules without
enabling them in icinga.cfg explicitely.
1.4.x still contains the modules/idoutils.cfg which contains commented sample
configs. this is known bug (make install overrides existing source installs) -
https://dev.icinga.org/issues/1625 - and it will be replaced by
modules/idoutils.cfg-sample allowing the same procedure as you know about
(all recent changes can be found in this git branch until they hit the release
whilst cgis and ido do have their own)
> It fixes the most issues mentioned above I think. Most warnings come from using
> user icinga and groups icinga and icingacmd.
> > icinga.x86_64: W: non-executable-in-bin /usr/bin/p1.pl 0644
> > icinga.x86_64: E: script-without-shebang /usr/bin/p1.pl
> > icinga.x86_64: E: non-executable-script /usr/bin/p1.pl 0644 None
> If my perl knowledge is right, it is a perl module so I gave no execution
> permissions, but did not move it because I think it will break something.
p1.pl is only used if embedded perl is enabled (by configure/compile) and if
enabled explicitely in icinga.cfg. this is intentionally disabled in future
releases as the embedded perl interpreter could cause memory leaks which
haven't been fixed / cannot be fixed for some years now. don't ask me about the
details, i'm no expert at this stage of coding.
even more, nearly each know distribution moans about the location of p1.pl in
$bindir so the recent git commit introduces default $libdir and a new configure
option to be named '--with-p1-file-dir' and is targetted to be used by
packagers who don't like to do the normal mv and sed stuff.
so expect older packages to be having an old p1.pl floating around, but that's
something to be mentioned seperately in the changelogs.
due to these changes, the icinga-spec provided with the official releases will
and some more changes, because the target of p1.pl in (new_)mini_epn.c in
contrib/ (which can be used to manually execute and test perl plugins) have a
lot of hardcoded stuff which is now to be replaced to be more packager
the intended location for an official distribution package is
$libdir/icinga/p1.pl which is enabled in configure and the filelist itsself.
though i'm not sure if introducing such changes would make sense in 1.4.2 as it
will remain a bugfix release.
> > icinga-idoutils-mysql.x86_64: E: explicit-lib-dependency libdbi-dbd-mysql
> > icinga-idoutils-pgsql.x86_64: E: explicit-lib-dependency libdbi-dbd-pgsql
> It is not really the lib, it is the driver needed by the lib.
probably a change which can only be done with a fresh package start. existing
rpmbuilds will suffer from revoking icinga-idoutils, but that's fine if it will
be kept as an alternative over here.
> Building the package works fine on rhel5, rhel6 and f14 also i386 and x86_64,
> install is only tested on rhel5 and it works.
> I hope the provided files are useful, but I am sorry I am not allow to do
> packaging and maintain packages by my employer, so someone else has to step in.
i'm doing internal packaging stuff (still learning!), but my daily job is
partly icinga core development, so i'd be very happy to see an official
maintainer. also possible as part of team icinga as we are trying to keep
communication channels easy and changes - if they fit - mostly upstream.
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the package-review