[//]: # (werk v2)
# check_sql: activate thick mode for oracle connections
key | value
---------- | ---
date | 2024-08-08T09:40:54+00:00
version | 2.3.0p13
class | fix
edition | cre
component | checks
level | 1
compatible | yes
With [Werk #16023](https://checkmk.com/werk/16023) we switched the library used
to connect to oracle databases from `cx_Oracle` to `oracledb`. For `cx_Oracle`
it was mandatory to install "Oracle Instant Client". The newer `oracledb` library has
two modes: A stand alone thin mode and a thick mode that needs the "Oracle
Instant Client".
In order to fully replace `cx_Oracle`, `oracledb` needs to be in thick mode.
This is something we have not considered for Werk #16023.
With this Werk we now try to switch into the thick mode, and if this does not
work, we use thin mode. If you execute `check_sql` with `-v` switch you will see
a message if `oracledb` could not switch into thick mode.
`oracledb` searches for the "Oracle Instant Client" in several standard location.
`check_sql` will find the installation if the files (among other things `*.so`
and `*.jar`) from the "Oracle Instant Client" files are directly in
`~local/lib/` in your site.
[//]: # (werk v2)
# Fix link of "Open this Aggregation"
key | value
---------- | ---
compatible | yes
version | 2.3.0p13
date | 2024-08-12T13:22:22+00:00
level | 1
class | fix
component | multisite
edition | cre
If you used the option "Open this Aggregation" in the burger menu of a check
based on "Check State of BI Aggregation", the link lead to a none existing
page.
Werk 16615 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Remove websphere_mq plugin
key | value
---------- | ---
date | 2024-03-11T11:09:48+00:00
version | 2.3.0b5
class | security
edition | cre
component | checks
level | 1
compatible | no
With this Werk the `websphere_mq` plugin is removed for security reasons.
In this plugin the output of `ps` is used to determine an argument for
`runmqsc`. This meant that anybody who can launch processes with an arbitrary
command line could manipulate one argument to `runmqsc`.
The plugin was already superseded by the agent plugin `ibm_mq` and deprecated with Werk [10752](https://checkmk.com/werk/10752) and version 2.0.0.
Since this plugin is already deprecated and it was not configurable via the
*agent bakery* we assumed that this plugin is not frequently used. Therefore we
decided to not fix the issue but to push the removal.
We found this vulnerability internally.
__Affected versions__:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0
__Mitigations__:
Migrate to the `ibm_mq` plugin.
__Vulnerability Management__:
We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N`.
We assigned CVE-2024-3367 to this vulnerability.
__Changes__:
The plugin was removed.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Remove websphere_mq plugin
key | value
---------- | ---
date | 2024-03-11T11:09:48+00:00
version | 2.3.0b5
class | security
edition | cre
component | checks
level | 1
- compatible | yes
? ^^^
+ compatible | no
? ^^
With this Werk the `websphere_mq` plugin is removed for security reasons.
In this plugin the output of `ps` is used to determine an argument for
`runmqsc`. This meant that anybody who can launch processes with an arbitrary
command line could manipulate one argument to `runmqsc`.
The plugin was already superseded by the agent plugin `ibm_mq` and deprecated with Werk [10752](https://checkmk.com/werk/10752) and version 2.0.0.
Since this plugin is already deprecated and it was not configurable via the
*agent bakery* we assumed that this plugin is not frequently used. Therefore we
decided to not fix the issue but to push the removal.
We found this vulnerability internally.
__Affected versions__:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0
__Mitigations__:
Migrate to the `ibm_mq` plugin.
__Vulnerability Management__:
We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N`.
We assigned CVE-2024-3367 to this vulnerability.
__Changes__:
The plugin was removed.
[//]: # (werk v2)
# Opsgenie: Better error handling
key | value
---------- | ---
date | 2024-08-12T12:32:45+00:00
version | 2.3.0p13
class | fix
edition | cre
component | notifications
level | 1
compatible | yes
In earlier versions some errors (like authentication failures) lead to a
traceback.
Errors should be shown in a better way now.
[//]: # (werk v2)
# Check Point plug-ins: increase detection sensitivity
key | value
---------- | ---
date | 2024-08-08T13:12:02+00:00
version | 2.3.0p13
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Some Check Point devices have not been discovered as expected.
We now additionally consider all devices where the system object
identifier points to Check Points enterprise SNMP tree
_".1.3.6.1.4.1.2620"_.
[//]: # (werk v2)
# azure: Handle Azure API rate limit
key | value
---------- | ---
compatible | yes
version | 2.3.0p13
date | 2024-08-07T08:56:46+00:00
level | 1
class | fix
component | checks
edition | cre
After the changes in Azure API rate limits, the Azure agent requests to the API
were getting throttled for the big Azure environments.
This fix introduces handling for throttled requests. If the rate limit is reached,
the agent will repeat the request after 5 s. If it fails again, the agent will repeat the request
after another 10 s.
Additionally, the default limits for 'Lower levels for remaining API reads' in
the 'Azure Agent Info' monitoring rule are removed.
[//]: # (werk v2)
# Don't log unparsable SNMP traps per default
key | value
---------- | ---
date | 2024-08-08T09:11:31+00:00
version | 2.3.0p13
class | fix
edition | cre
component | ec
level | 1
compatible | yes
When an SNMP trap arrives at the event console which can't be parsed for
various reasons (unknown SNMP engine ID, some deserialization error, ...),
we previously logged a full Python backtrace to the EC log. This could lead
to the incorrect conclusion that there is something wrong with the EC
itself, which is not what has actually happened: Actually, some device was
probably misconfigured and/or misbehaving. To avoid such log spam, such a
trap is now silently dropped at the standard "informational" log level, and
more details can be logged at higher levels when needed.
[//]: # (werk v2)
# HTTP/HTTPS Service: Correctly apply 'Certificate validity' of 'Standard settings'
key | value
---------- | ---
date | 2024-08-07T09:57:27+00:00
version | 2.3.0p13
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This fixes a bug in the Setup ruleset _"Check HTTP web service"_.
If users configured *any* individual settings for an endpoint,
the standard setting for _"Certificate validity"_ was not respected.
Other settings where not affected.
[//]: # (werk v2)
# brocade_fcport: fix operating speed conversion
key | value
---------- | ---
date | 2024-07-09T09:22:21+00:00
version | 2.3.0p13
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This werk affects anyone monitoring Brocade fibre channel ports
by comparing current or average throughput to certain absolute or percentage levels
via the _Brocade FibreChannel ports_ rule.
In the plugin the current operating speed of the interface,
read from the SNMP interface data,
was not properly converted to GByte/s,
the unit of measurement displayed in the interface.
This resulted in an erroneous comparison of values and the related service states.
[//]: # (werk v2)
# Custom graphs: Visibility toggle had no effect
key | value
---------- | ---
date | 2024-08-06T08:29:16+00:00
version | 2.3.0p13
class | fix
edition | cee
component | multisite
level | 1
compatible | yes
The visibility toggle to enable or disable elements of custom graphs had no effect.