Werk 16444 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: EC: Fix missing configuration files
Class: fix
Compatible: compat
Component: ec
Date: 1705915976
Edition: cee
Level: 1
Version: 2.2.0p21
With werk 16012 the event console rules are filtered and saved to the location
var/mkeventd/active_config during activate changes.
Unfortunatelly other configuration files like global.mk are missing which are
now copied recursively, too.
------------------------------------<diff>-------------------------------------------
Title: EC: Fix missing configuration files
Class: fix
Compatible: compat
Component: ec
Date: 1705915976
Edition: cee
Level: 1
- Version: 2.2.0p20
? ^
+ Version: 2.2.0p21
? ^
With werk 16012 the event console rules are filtered and saved to the location
var/mkeventd/active_config during activate changes.
Unfortunatelly other configuration files like global.mk are missing which are
now copied recursively, too.
Werk 16071 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Notification spooler: Fix ignored timing settings for specific methods
Class: fix
Compatible: incomp
Component: notifications
Date: 1699356565
Edition: cee
Level: 1
Version: 2.2.0p21
If you used notification spooling and configured "Timing settings for specific
methods" in the global settings option "Notification Spooler Configuration",
the settings "Maximum number of delivery attempts" and "Timeout" had no effect.
The notification methods were executed until they succeded.
Please note:
This change can cause changes in the notification spooling, please check if the
behaviour still matches your needs. Otherwise you would have to adjust the
mentioned settings again.
------------------------------------<diff>-------------------------------------------
Title: Notification spooler: Fix ignored timing settings for specific methods
Class: fix
Compatible: incomp
Component: notifications
Date: 1699356565
Edition: cee
Level: 1
- Version: 2.2.0p20
? ^
+ Version: 2.2.0p21
? ^
If you used notification spooling and configured "Timing settings for specific
methods" in the global settings option "Notification Spooler Configuration",
the settings "Maximum number of delivery attempts" and "Timeout" had no effect.
The notification methods were executed until they succeded.
Please note:
This change can cause changes in the notification spooling, please check if the
behaviour still matches your needs. Otherwise you would have to adjust the
mentioned settings again.
Werk 16292 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: user_config: add verification for contact groups and locked attributes
Class: fix
Compatible: compat
Component: rest-api
Date: 1705416141
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p21
This werk introduces two changes:
LI: it now verifies for create & edit if the provided contact groups actually exist
LI: it verifies that for an edit request, locked attributes are not being modified
------------------------------------<diff>-------------------------------------------
Title: user_config: add verification for contact groups and locked attributes
Class: fix
Compatible: compat
Component: rest-api
Date: 1705416141
Edition: cre
Knowledge: doc
Level: 1
- Version: 2.2.0p20
? ^
+ Version: 2.2.0p21
? ^
This werk introduces two changes:
LI: it now verifies for create & edit if the provided contact groups actually exist
LI: it verifies that for an edit request, locked attributes are not being modified
Werk 16075 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Notification spooler: Fix possible wrong order of notification processing
Class: fix
Compatible: compat
Component: notifications
Date: 1700481159
Edition: cee
Level: 1
Version: 2.2.0p21
The notification spooler used the mtime of the spool files to determine the
order of execution.
In rare cases, the mtime was too imprecise so we now use the mtime in
nanoseconds.
------------------------------------<diff>-------------------------------------------
Title: Notification spooler: Fix possible wrong order of notification processing
Class: fix
Compatible: compat
Component: notifications
Date: 1700481159
Edition: cee
Level: 1
- Version: 2.2.0p20
? ^
+ Version: 2.2.0p21
? ^
The notification spooler used the mtime of the spool files to determine the
order of execution.
In rare cases, the mtime was too imprecise so we now use the mtime in
nanoseconds.
Werk 16309 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Fix error on update if LDAP connection ID contains spaces
Class: fix
Compatible: compat
Component: wato
Date: 1705650557
Edition: cre
Level: 1
Version: 2.2.0p21
With werk #15815 LDAP connection IDs are validated and rewritten if they
contain spaces (possible in 2.1).
Such connection IDs resultet in sync_time files in the web dir, also containing
spaces and lead to an error on user ID validation if you update from 2.1
to 2.2.
This files are now also renamed during the update.
------------------------------------<diff>-------------------------------------------
Title: Fix error on update if LDAP connection ID contains spaces
Class: fix
Compatible: compat
Component: wato
Date: 1705650557
Edition: cre
Level: 1
- Version: 2.2.0p20
? ^
+ Version: 2.2.0p21
? ^
With werk #15815 LDAP connection IDs are validated and rewritten if they
contain spaces (possible in 2.1).
Such connection IDs resultet in sync_time files in the web dir, also containing
spaces and lead to an error on user ID validation if you update from 2.1
to 2.2.
This files are now also renamed during the update.
Title: check_uniserv: running the active check results in exception "TypeError: a bytes-like object is required, not 'str'"
Class: fix
Compatible: compat
Component: checks
Date: 1705503976
Edition: cre
Level: 1
Version: 2.2.0p20
<code>check_uniserv</code> implementation didn't encode the <code>close</code> command resulting in an exception
<code>TypeError: a bytes-like object is required, not 'str'</code> being raised.
This change adds the missing encoding among some general modernization.
Title: EC: Fix missing configuration files
Class: fix
Compatible: compat
Component: ec
Date: 1705915976
Edition: cee
Level: 1
Version: 2.2.0p20
With werk 16012 the event console rules are filtered and saved to the location
var/mkeventd/active_config during activate changes.
Unfortunatelly other configuration files like global.mk are missing which are
now copied recursively, too.
Title: Update PHP version in SLES15SP3 from 7 to 8
Class: fix
Compatible: incomp
Component: rpm
Date: 1701254497
Edition: cre
Level: 2
Version: 2.2.0p20
Checkmk was shipped with a dependency to PHP7 for SLES15SP3. Since PHP7 is
part of the legacy module, this Werk updates the dependency from PHP7 to PHP8.
As SLES only allows one version of PHP to be installed, the following steps
will uninstall PHP7 from the system and install the new version of Checkmk
with PHP8. Be aware that this procedure updates PHP from version 7 to 8 for the whole OS. In case you run additional PHP applications next to Checkmk, the update will also affect them.
Run the following commands to perform the update to the new Checkmk version:
* add SLES-15SP4 repo to get PHP8 with <tt>zypper addrepo https://updates.suse.com/SUSE/Products/SLE-BCI/15-SP4/x86_64/product/ sles15sp4</tt>
* install the new Checkmk version with <tt>zypper install NEW_CHECKMK.rpm</tt>
* Zypper will now complain about a conflict with several PHP packages and asks you to select a solution. There, select <tt>solution 1</tt> to confirm the deinstallation of the current Checkmk version, the PHP7 modules and to continue with the installation
* confirm the installation of the new Checkmk version and PHP8 with <tt>yes</tt>
* removing the existing Checkmk version will throw an error like `Site <SITENAME> is still using this version! Removal of <OLD_CHECKMK>(@System) failed:`, proceed by choosing <tt>ignore</tt> which creates a inconsistent state for the old Checkmk version package, which we will resolve in a later step.
* PHP7 will be removed and PHP8 gets installed
* change to the site user with <tt>omd su SITE_NAME</tt>
* stop the site with <tt>omd stop</tt>
* perform the update to the new Checkmk version with <tt>omd update</tt>, select <tt>Update</tt> at the user prompt
* in case further prompts regarding wrong permissions of BUILD files appear, choose the default value with <tt>d</tt>
* start the site again with <tt>omd start</tt>
* exit from the site user
* list all installed Checkmk version with <tt>omd versions</tt>
* finally remove the old Checkmk installation with <tt>zypper remove OLD_CHECKMK</tt>
Werk 16384 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: notification rule: allow for non builtin service levels
Class: fix
Compatible: incomp
Component: rest-api
Date: 1705490346
Edition: cre
Level: 1
Version: 2.2.0p20
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level": "gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
"value": {"from_level" 10, "to_level": 20}
}
}
```
------------------------------------<diff>-------------------------------------------
Title: notification rule: allow for non builtin service levels
Class: fix
Compatible: incomp
Component: rest-api
Date: 1705490346
Edition: cre
Level: 1
Version: 2.2.0p20
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
+ ```
-
- C+:
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level": "gold"}
}
}
- C-:
+ ```
New schema
+ ```
-
- C+:
{"match_service_levels: {
"state": "enabled",
"value": {"from_level" 10, "to_level": 20}
}
}
- C-:
+ ```
+
[//]: # (werk v2)
# EC: Fix missing configuration files
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-01-22T09:32:56+00:00
level | 1
class | fix
component | ec
edition | cee
With werk 16012 the event console rules are filtered and saved to the location
var/mkeventd/active_config during activate changes.
Unfortunatelly other configuration files like global.mk are missing which are
now copied recursively, too.