Better soon than later: when will the first preview of Centreon on Bokworm be available?

Hi Stéphane,

yes, there are many reasons, mainly related with my personal tastes, but other are technically motivated.

The most important are the following:

• Debian’s footprint is smaller. Debian’s packaging policies provides smaller packages and this allows to reduce the security surface, installing less applications and services (i.e. installing postfix on RH brings OpenLDAP in the system, even if you don’t use ldap maps in postfix; in Debian there is a specific package for ldap maps). Since the monitoring server usually has access to every other server in an environment, the less the security surface is, the most secure is the network. If you use the linux-image-cloud-amd64 kernel image you further reduce update downtimes and kernel security footprint.
• Debian’s release upgrade is straightforward. I have many servers born with Debian Sarge and now landed on Bookworm stepping on all the intermediate releases without any problem. Sure, dist-upgrading requires some additional care, but the process works flawlessly 90% of times. OTOH I never succeeded in upgrading a CentOS n to CentOS n+1 (with  4<=n<=9, at least the few times I tried) and eventually I always did a fresh installation and app migration (with all the connected problems).
• RedHat Centreon packaging uses extra RPM repos that install apps in /opt/rh, and that hurts me because it brokes all the tools I commonly use (that assumes i.e. the apache server config is in /etc/httpd, not in /opt/rh…) and may cause problems with package dependencies. In Debian, instead, the external repositories adhere perfectly to the Debian Guidelines and the things are all in the right place, without any kind of conflict with distribution provided packages.
• Debian packaging has a better handling of config changes during updates and it helps a lot if you have more applications than only Centreon on the same server.
• Direct conseguence of the previous sentence, I usually install some other apps other than Centreon on the same host, because not all my needs are covered by Centreon (unfortunately). One of the other app I use is nagvis with NagVis Centreon Backend. I managed to make it work on Debian, but I didn’t succeed on RH; and nagvis, although missing some features on Centreon Backend, is a great piece of software. Then I (often) install netdisco which is helpful because it allows to discover devices and their connections (via SNMP and LLDP/CDP) and when you have many network devices it helps the troubleshooting. Then I install dokuwiki as documentation management. Centreon provides the knowledge base with mediawiki, but it is extremely complex and heavy for my needs. So I prefer the lightweight dokuwiki with some of its interesting plugins. Finally I sometimes add netbox as IPAM and documentation management.
  In Debian everything is straightforward… all the config separated in /etc/apache2/sites-available/<vhostname>.conf, more than one php-fpm version available without interference among the instances, etc.etc. And everything completely respecting Debian’s rules. On RH it was a nightmare to make 2 app work without messing everything up :(
• Debian offers more software in the default repositories than RH and derivatives. Having a comprehensive repo allows you to limit the usage of foreign resources, which can imply conflicts between packages or even the unavailability of some app on newer releases (i.e. vpnc is not available on RH >=8. OK, it’s a crap, but I need it in one place).
• Debian’s software is usually more on pair with upstream versions than RH, even if every stable release stays stopped about 2.5 years after freeze.

As you can see many of the above are probably more related with my personal tastes and my knowledge of the different distributions, than with real technical reasons. I.e. if I knew RH better, I probably could manage the coexistence of multiple apps in a simpler manner. But I don’t know it so well :D

Anyway the cleanliness of Debian in handling packaging and updates is technically superior to RH and this is an undeniable fact. IMHO this is more than enough to tip the scales in favour of Debian.

I tend to use RH only when required by the specific app, or when the client uses only RH based host by policy, or when it is anyway the best solution for the specific role.

Anyway when I use RH based distros I prefer to install one app on one host and, in order of preference, I choose RHEL (free for 5 hosts), Oracle Unbreakable Linux (free and well supported with many enhancements) or Rocky Linux.

Put some IMHO randomly in the text ;)

Flavio

There are too many changes on base packages and probably won’t work, but even if it could work (didn’t try yet) I wouldn’t put in production an unsupported configuration for this role (expecially after what I wrote before about security concerns).

If there isn’t any current work on bookworm it will need to start soon, so I’ll wait patiently. I’m anyway available to beta test the packages when available :)

hi @Laurent - not sure if you saw my mention as it was edited later

Hi Laurent,

OK, i understand - you will not put valuable time in updating unless it is needed, as bullseye is still maintained - makes sense.

But you also don’t rule out doing it once bullseye nears EOL, right?

And thnx for replying.

Regards

Timo

Problem is security support end in august 2024, and extended support is maintened by another team in a best effort basis.
In fact, all security patches are in the stable version, and lot of time not backported to the old version in extended support.

Not giving support to last release force all new deployment to be based on an old version …