[Pkg-nagios-devel] Bug#707841: check-mk: Consider packaging the agent and the server part independently
Bernhard Schmidt
berni at birkenwald.de
Sat May 11 18:50:52 UTC 2013
Package: check-mk
Severity: wishlist
Hello check-mk maintainers,
this is just a suggestion/idea, not even a wishlist. I work quite extensively
with check-mk and I just had the following idea. Maybe you already thought
of it and rejected it, but here it comes.
src:check-mk currently builds two totally different kinds of packages
check-mk-agent{,-logwatch}:
- single bash script for the main agent, easy to understand
- very short bash scripts for optional plugins
- very few dependencies, autodetects presence of optional tools and skips checks
gracefully
- totally self contained
- quite good track record of being up- and downwards compatible with different
server versions
- few changes in the code, occasional additions and fixes in the code that
usually don't break anything
http://git.mathias-kettner.de/git/?p=check_mk.git;a=history;f=agents/check_mk_agent.linux;h=78902caff3c26067b08e2f6a8451fdcdec788a3c;hb=HEAD
- additional checks are usually only a few lines and self-contained
- installed on every monitored server
These packages are in my eyes prime backports material and quite suitable
for easy fixes in stable point releases
check-mk-config-*, check-mk-server, check-mk-livestatus, check-mk-multisite:
- quite complex
- often backwards incompatible changes in perfdata labels (-> pnp4nagios breaks
old stats) or in WATO configuration, requiring manual intervention on
upgrades
- quite often regressions and changed behaviour in new releases
- not really well supporting distro packages anyway, upstream pushes use of
their 3rd party OMD packages
These packages are hard to keep updated, especially considering that Debian
is supposed to keep automatic upgrade paths through the versions. A lot of
people are also switching to OMD anyway, making the server parts low popcon.
Would it be an option to split the package into two source packages (with the
same .orig if that's possible), and keep the agent closer to upstream versions?
Of course the best would be to keep all packages updated, but it seems to
be much more work to do so.
Thanks for your opinions,
Bernhard
More information about the Pkg-nagios-devel
mailing list