Hello, thanks.

→ Are there any compatibility to keep between the OS/packages and the centreon packages on a working Server/Poller ?

For exemple, can “dnf update --exclude=centreon*” (update all the packages except centreon ones) have any impact on centreon plugins ?

Will any working Centreon version will be OK with the OS/packages update ?

Or is it mandatory to always update the centreon plugins at the same time “dnf update” ?

Thanks

instead of “centreon plugins” I meant “centreon packages”

Hello @frantz,

Centreon packages get the recent dependencies they need, but the reverse is not true.

So, it’s rare but possible to encounter issues if the system is up-to-date but the Centreon packages are not. Especially for the centreon-plugins on a poller, which often depend on Perl packages of the system.

Centreon updates can also solve security problems.

I recommend to keep an eye on Release Notes https://docs.centreon.com/docs/releases/centreon-os/ for security concern if you want to decorellate system updates and Centreon updates.

Hello @AltGr 

Thanks for your answer. I was wondering both ways.

So If I understand well ? :

→ We must be carefull while upgrading the OS but not the centreon packages “dnf update --exclude=centreon\*” as there may be compatibility issues.

→ Upgrading the centreon packages (but not the OS) with “dnf update centreon\*” should work as dependencies are checked

→ Upgrading both (OS + centreon) with “dnf update” will always work

Is that it ?

Best regards

Hello @Frantz,

I understand quite the opposite from @AltGr’s answer.

There are more possibilities that older Centreon packages would still work with newer system packages, than a newer Centreon package would work with older system packages.

In a general manner, a distribution tries not to break user applications. But a user application may often require a newer system/library packages.

Concerning Centreon I’m particularly worried about the fact it requires very recent PHP packages, hence PHP packages from the REMI repositories :

1)  REMI repositories do not exist for Debian/Ubuntu, there are some nearly equivalent third-party repository for Debian and its derivatives, but they’re not strictly equivalent.
2) Third-party repositories, as last upstream version of software are less secure and bug-free than software from the stable branch of any mainstream distributions.

3) Sticking to the most common denominator of all the oldest supported distributions would indeed limit the versions available, but I’m pretty sure it would have the great advantage of avoiding fancy, eye-candy and disruptive functionalities to pop in Centreon, which very often only bring more bugs, bloating  and breaking changes than usefulness. Not mentioning the stronger learning curve for potential new contributors.

In my case I’m currently using Centreon 23.10.11 in production, testing the 23.10.14. I will be able to upgrade a development platform in 23.10.15 soon, and looking forward to upgrade the production platform too, as soon as I can. But some company processes can be quite cumbersome in matter of software upgrade politics, sadly.
My (about 12 yo) user experience with Centreon is still made of more cutting edge and highly unfinished new functionalities, which introduce numerous new bugs here and there in the software (sometime even breaking legacy functionalities!), functionalities which are undesired for the most (IMO), than fixes for some annoying and long lasting bugs on the basic, legacy functionalities, which are, in contrary, intensively used, so deeply relied on in our information system.

I’ll be happily surprised if 24.04 and next releases come back to robustness and trustfulness oriented development. Currently I can’t even afford to report all the, sometime blatant, bugs on which I stumble upon on a nearly everyday basis. Furthermore, when I applied myself to did this in the past, it has very few effects.

TMYK

I wish a nice day, and pleasant weekend to everybody.