Thank you both! That’s really great as it is the only way to upgrade smoothly.
No, of course not if that is the only way to edit an MKP ( + ). I overlooked the fact that you can only edit enabled and activated MKPs because I build my MKPs with a standalone Python script without any checkmk instance and then install them via commandline.
As @andreas-doehler already said: usually it’s not a big problem for me that downgrading of MKPs works despite the wrong version number, because I usually don’t downgrade. But still, I would appreciate if the GUI would show a big confirmation box in that case (just like the “do you really want to delete?” box). For the commandline I’d prefer that the mkp enable command fails, but that it can be overridden with a --force switch.
As this is the crucial part of this feature the written ‘automatically disabled’ concerned me a bit. So I did some comparison on the first productive remote site which I updated this week from 2.1 to 2.2 and I can confirm that at least this part works as intended but the package is inactive and not disabled . Please understand that there is a difference between disabled and inactive. A package can switch automatically between active and inactive based on criteria. If a package is disabled also this automatism is deactivated and the package is not treated anymore by version, required version and until version.
ldap_groups_to_site_multi 3.2.0 Sync and lock authorized sites of users based on group membership tribe29 GmbH, Ronny BRUSKA/ FORVIA, Michael FRANK <michael.frank@forvia.com> 2.2.0p1 None 1 Enabled (active on this site)
ldap_groups_to_site_multi 3.1.0 Sync and lock authorized sites of users based on group membership tribe29 GmbH, Ronny BRUSKA/ FORVIA, Michael FRANK <michael.frank@forvia.com> 2.1.0p1 2.1.0p99 1 Enabled (inactive on this site)
.
.
.
Problem remaining is that old packages are not deleted on the remote sites:
OMD[VST]:~$ mkp list | grep ldap
ldap_groups_to_site_multi 3.2.0 Sync and lock authorized sites of users based on group membership tribe29 GmbH, Ronny BRUSKA/ FORVIA, Michael FRANK <michael.frank@forvia.com> 2.2.0p1 None 1 Enabled (active on this site)
ldap_groups_to_site_multi 3.1.0 Sync and lock authorized sites of users based on group membership tribe29 GmbH, Ronny BRUSKA/ FORVIA, Michael FRANK <michael.frank@forvia.com> 2.1.0p1 2.1.0p99 1 Enabled (inactive on this site)
ldap_groups_to_site_multi 1.1 Title of ldap_groups_to_site_multi tribe29 GmbH 1.5.0 2.0.0 1 Disabled
ldap_groups_to_site_multi 2.0.0 Sync and lock authorized sites of users tribe29 GmbH, Ronny BRUSKA 2.0.0 None 1 Disabled
The versions 1.1 and 2.0.0 are not existent anymore on master.
Still not fixed is the problem that a once disabled package on a remote site cannot reenabled again:
OMD[VST]:~$ mkp disable ldap_groups_to_site_multi 3.2.0
Part 'web':
plugins/userdb/ldap_groups_to_sites.py
OMD[VST]:~$ mkp enable ldap_groups_to_site_multi 3.2.0
No such package: ldap_groups_to_site_multi 3.2.0
The package itself doesnt exist anymore on the file system.
I will continue do some debugging and internal discussion to decide if we can continue with 2.2.0p39 or not. I will come back soon.
First, I want to once again thank the Checkmk developers for adding the functionality of ‘valid until Checkmk version’ and ‘minimum required version’ as early code in version 1.6.0 of Checkmk. Without these features, we would have had many incompatible packages, making it impossible to upgrade to 2.0.0 without a significant downtime in our monitoring. This new functionality has greatly helped us, and I assume many others as well.
Great job!
We internally discussed the recent change in package management introduced in version 2.2.0, and unfortunately, we cannot agree with it.
We believe the benefit of allowing package activation when the ‘valid until Checkmk version’ is lower than the system’s Checkmk version is very minimal. With the excellent ‘omd’ tool, installing the correct version that the package was built for is already quick and easy, and any necessary modifications can be made there. However, we see the risks and issues associated with this change as much more significant:
Activating code that is not intended to work on the current version could cause serious issues in the system, potentially even preventing the Checkmk frontend from functioning correctly. While this might be a controlled situation in a development environment, it is not necessarily safe in a production environment with multiple administrators.
It contradicts the core concept of ‘valid until Checkmk version’. Consequently, the same approach would need to be applied to packages with a ‘minimum required version’ setting, ultimately breaking the entire purpose of this feature and preventing us from upgrading safely.
If a future version of Checkmk introduces changes to the package manifest format, making it incompatible with earlier versions, this change would become ineffective. The package would still be unable to install on a lower version due to manifest incompatibility.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
+ 
). I overlooked the fact that you can only edit enabled and activated MKPs because I build my MKPs with a standalone Python script without any checkmk instance and then install them via commandline.
. Please understand that there is a difference between disabled and inactive. A package can switch automatically between active and inactive based on criteria. If a package is disabled also this automatism is deactivated and the package is not treated anymore by version, required version and until version.