Werk 16499 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: bluenet: allow discovery for newer devices
Class: fix
Compatible: compat
Component: checks
Date: 1707740421
Edition: cre
Level: 1
Version: 2.1.0p43
Prior to this werk, the snmp detect condition was too
restrictive which excluded subsequently new devices.
Those new devices had another oid section following the
initial condition. This werk makes the detect condition
more lenient to allow discovery of those devices.
------------------------------------<diff>-------------------------------------------
Title: bluenet: allow discovery for newer devices
Class: fix
Compatible: compat
Component: checks
Date: 1707740421
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
Prior to this werk, the snmp detect condition was too
restrictive which excluded subsequently new devices.
Those new devices had another oid section following the
initial condition. This werk makes the detect condition
more lenient to allow discovery of those devices.
Werk 16379 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Allow disabling of bulk walks on inline SNMPv3 hosts
Class: fix
Compatible: compat
Component: checks
Date: 1710141228
Edition: cre
Level: 1
Version: 2.1.0p43
It was impossible to disable bulkwalks for SNMP version 3 hosts using the inline SNMP backend.
It is fixed now in the sense that it works as in the classic backend:
In order to disable bulkwalks <b>for SNMP version 3</b> hosts, you need to make sure they do <b>not</b> match the ruleset "Enable SNMPv2c and bulkwalk for host".
A more thorough fix for this bug and the related phrasing in the rulesets is implemented in for Checkmk 2.3, but it was too risky to port into the stable releases.
See <a href="https://checkmk.com/werk/16382">Werk #16382</a> for more on that.
------------------------------------<diff>-------------------------------------------
Title: Allow disabling of bulk walks on inline SNMPv3 hosts
Class: fix
Compatible: compat
Component: checks
Date: 1710141228
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
It was impossible to disable bulkwalks for SNMP version 3 hosts using the inline SNMP backend.
It is fixed now in the sense that it works as in the classic backend:
In order to disable bulkwalks <b>for SNMP version 3</b> hosts, you need to make sure they do <b>not</b> match the ruleset "Enable SNMPv2c and bulkwalk for host".
A more thorough fix for this bug and the related phrasing in the rulesets is implemented in for Checkmk 2.3, but it was too risky to port into the stable releases.
See <a href="https://checkmk.com/werk/16382">Werk #16382</a> for more on that.
Werk 16631 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: check_mailboxes: Fixed handling of error "Not allowed to access Non IPM folder."
Class: fix
Compatible: compat
Component: packages
Date: 1712910849
Edition: cre
Level: 1
Version: 2.1.0p43
Due to a recent change in Microsoft 365, the access to Exchange mailbox folders via the active check <code>check_mailboxes</code> could fail with an error message like this:
C+:
Unhandled exception: ErrorAccessDenied('Not allowed to access Non IPM folder.')
C-:
With this werk we update the version of the package <code>exchangelib</code> to v5.2.1, fixing the respective error handling.
------------------------------------<diff>-------------------------------------------
Title: check_mailboxes: Fixed handling of error "Not allowed to access Non IPM folder."
Class: fix
Compatible: compat
Component: packages
Date: 1712910849
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
Due to a recent change in Microsoft 365, the access to Exchange mailbox folders via the active check <code>check_mailboxes</code> could fail with an error message like this:
C+:
Unhandled exception: ErrorAccessDenied('Not allowed to access Non IPM folder.')
C-:
With this werk we update the version of the package <code>exchangelib</code> to v5.2.1, fixing the respective error handling.
Werk 16549 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Agent updates failing on Solaris 10
Class: fix
Compatible: incomp
Component: agents
Date: 1709282638
Edition: cee
Level: 1
Version: 2.1.0p43
On some Solaris 10 systems, an agent update did crash with error message
C+:
/var/sadm/pkg/check-mk-agent/install/postremove: syntax error at line 19: `(' unexpected
pkgrm: ERROR: postremove script did not complete successfully
C-:
If you ran into this error, to make the update perform again, please delete the file
<code>/var/sadm/pkg/check-mk-agent/install/postremove</code> on affected systems.
Technical background:\
The postremove script used the subshell evaluation syntax <code>$(...)</code> that is incompatible to the standard <code>bin/sh</code> shell found on some Solaris 10 systems.
------------------------------------<diff>-------------------------------------------
Title: Agent updates failing on Solaris 10
Class: fix
Compatible: incomp
Component: agents
Date: 1709282638
Edition: cee
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
On some Solaris 10 systems, an agent update did crash with error message
C+:
/var/sadm/pkg/check-mk-agent/install/postremove: syntax error at line 19: `(' unexpected
pkgrm: ERROR: postremove script did not complete successfully
C-:
If you ran into this error, to make the update perform again, please delete the file
<code>/var/sadm/pkg/check-mk-agent/install/postremove</code> on affected systems.
Technical background:\
The postremove script used the subshell evaluation syntax <code>$(...)</code> that is incompatible to the standard <code>bin/sh</code> shell found on some Solaris 10 systems.
Werk 16623 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: HW/SW Inventory: Fix crash when filtering for number of sites for Checkmk version
Class: fix
Compatible: compat
Component: inv
Date: 1710167848
Edition: cre
Level: 1
Version: 2.1.0p43
When filtering the Checkmk versions -> #Sites inventory column, a crash occurs with
C+:
TypeError (expected string or bytes-like object)
...
File "/omd/sites/oldstable/lib/python3/cmk/gui/query_filters.py", line 510, in <lambda>
return lambda row: bool(regex.search(row.get(column, "")))
C-:
This crash has been fixed.
------------------------------------<diff>-------------------------------------------
Title: HW/SW Inventory: Fix crash when filtering for number of sites for Checkmk version
Class: fix
Compatible: compat
Component: inv
Date: 1710167848
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
When filtering the Checkmk versions -> #Sites inventory column, a crash occurs with
C+:
TypeError (expected string or bytes-like object)
...
File "/omd/sites/oldstable/lib/python3/cmk/gui/query_filters.py", line 510, in <lambda>
return lambda row: bool(regex.search(row.get(column, "")))
C-:
This crash has been fixed.
Werk 16242 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Kill forked processes by mk_oracle under AIX
Class: fix
Compatible: compat
Component: checks
Date: 1709728993
Edition: cre
Level: 1
Version: 2.1.0p43
The agent plugin <code>mk_oracle</code> creates forked processes, e.g. from <code>sqlplus</code>.
In order to reliable clean up stale processes, we kill now the whole process chain under AIX
which corresponds to the stored <code>PID</code>.
We introduce this only for <code>AIX</code> now as we have customers which are affected under that OS.
------------------------------------<diff>-------------------------------------------
Title: Kill forked processes by mk_oracle under AIX
Class: fix
Compatible: compat
Component: checks
Date: 1709728993
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
The agent plugin <code>mk_oracle</code> creates forked processes, e.g. from <code>sqlplus</code>.
In order to reliable clean up stale processes, we kill now the whole process chain under AIX
which corresponds to the stored <code>PID</code>.
We introduce this only for <code>AIX</code> now as we have customers which are affected under that OS.
Werk 16416 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Make scp command work as site userr on SLES 15
Class: fix
Compatible: compat
Component: omd
Date: 1711615092
Edition: cre
Level: 1
Version: 2.1.0p43
On SUSE Linux Enterprise Server 15 systems, the <code>scp</code> command could crash with
C+:
/usr/bin/ssh: symbol lookup error: /usr/bin/ssh: undefined symbol: EVP_KDF_CTX_free, version OPENSSL_1_1_1d lost connection
C-:
when executed as a site user.
------------------------------------<diff>-------------------------------------------
Title: Make scp command work as site userr on SLES 15
Class: fix
Compatible: compat
Component: omd
Date: 1711615092
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
On SUSE Linux Enterprise Server 15 systems, the <code>scp</code> command could crash with
C+:
/usr/bin/ssh: symbol lookup error: /usr/bin/ssh: undefined symbol: EVP_KDF_CTX_free, version OPENSSL_1_1_1d lost connection
C-:
when executed as a site user.
Werk 16424 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: omd start redis: Don't Start If Process Already Running
Class: fix
Compatible: compat
Component: omd
Date: 1713456408
Edition: cre
Level: 1
Version: 2.1.0p43
With this Werk, <code>omd start</code> will no longer create a new redis process if redis is already started.
This aligns the behaviour with the other services of a site.
------------------------------------<diff>-------------------------------------------
Title: omd start redis: Don't Start If Process Already Running
Class: fix
Compatible: compat
Component: omd
Date: 1713456408
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^
With this Werk, <code>omd start</code> will no longer create a new redis process if redis is already started.
This aligns the behaviour with the other services of a site.
Werk 14227 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Changing settings in the site configuration can no longer cause ActivateChanges to hang forever
Class: fix
Compatible: compat
Component: wato
Date: 1711528118
Edition: cre
Level: 1
Version: 2.1.0p43
------------------------------------<diff>-------------------------------------------
Title: Changing settings in the site configuration can no longer cause ActivateChanges to hang forever
Class: fix
Compatible: compat
Component: wato
Date: 1711528118
Edition: cre
Level: 1
- Version: 2.1.0p42
? ^
+ Version: 2.1.0p43
? ^