Title: Inventory: Add Windows support for Hardware > System > Uuid
Class: feature
Compatible: compat
Component: inv
Date: 1713272987
Edition: cre
Level: 1
Version: 2.2.0p25
This element is already available for Linux, now the windows agent also supports
reading this value.
You have to update <code>mk_inventory.vbs</code> on the monitored host, to provide the
necessary data.
Title: mk_oracle: fix two parse errors
Class: fix
Compatible: compat
Component: checks
Date: 1712642491
Edition: cre
Level: 1
Version: 2.2.0p25
Due to fixes introduced with
<a href="https://checkmk.com/werk/16232">Werk #16232</a> new error messages
have been introduced to sections which previously had not to handle any errors.
Now <tt>oracle_processes</tt> and <tt>oracle_recovery_area</tt> services can
handle the new error messages.
Title: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora
Class: fix
Compatible: incomp
Component: checks
Date: 1712309908
Edition: cre
Level: 1
Version: 2.2.0p25
You are affected by this Werk if you use mk_oracle agent plugin on unix.
<tt>mk_oracle</tt> only works if it can find a <tt>sqlnet.ora</tt> in your
<tt>$TNS_ADMIN</tt> folder. In the past, <tt>mk_oracle</tt> executed all oracle
binaries as root, so <tt>sqlnet.ora</tt> was alwas readable. With <a
href="https://checkmk.com/werk/16232">Werk #16232</a> the oracle binaries are
executed with a low privileged user, so it might be the case, that
<tt>sqlnet.ora</tt> can not be read by this user.
<tt>mk_oracle</tt> will exit early if it can not read <tt>sqlnet.ora</tt>. The
error message might look like:
<code>
/etc/check_mk/sqlnet.ora can not be read by user "oracle"! Either use 'sqlnet.ora permission group' bakery rule, or directly modify permissions of the file.
</code>
The error message will also be visible in the <tt>oracle_instance</tt> check.
If you use the agent bakery to roll out mk_oracle to unix servers using
<tt>.rpm</tt>, <tt>.deb</tt> or Solaris <tt>.pkg</tt> packages, you have to use
the 'sqlnet.ora permission group' bakery rule to adapt the group of the
<tt>sqlnet.ora</tt> file, otherwise your permission changes might be
overwritten by updating the agent.
Otherwise it is sufficient to adapt the permissions.
If you install the agent on Unix using the <tt>tgz</tt> package, you will have
to manually adjust the permissions of the <tt>sqlnet.ora</tt> file.
Title: mk_oracle: Follow-up to privilege escalation fix
Class: fix
Compatible: incomp
Component: checks
Date: 1712217578
Edition: cre
Level: 2
Version: 2.2.0p25
You might be affected by this Werk if you use <tt>mk_oracle</tt> on a unix
system.
You might be affected by this Werk if you use oracle wallet to connect to your
database.
You are definitively affected by this Werk if you use oracle wallet to connect to your
database and used the instructions of our official documentation to setup your
configuration.
This Werk fixes connection problems introduced with 2.1.0p41, 2.2.0p24 and 2.3.0b4.
Since <a href="https://checkmk.com/werk/16232">Werk #16232</a> we switch to a
unprivileged user when executing oracle binaries. This causes problems when
using an oracle wallet as the unprivileged user might not be able to access
files defining the connection details and credentials.
We introduced an additional permission check to the <code>-t</code> "Just check
the connection" option of <code>mk_oracle</code>. It should help you modifying
the permissions to continue using <code>mk_oracle</code> with oracle wallet.
You can execute it with the following command:
<pre>
MK_CONFDIR=/etc/check_mk/ MK_VARDIR=/var/lib/check_mk_agent /usr/lib/check_mk_agent/plugins/mk_oracle --no-spool -t
</pre>
The path to mk_oracle might be different if you execute it asynchronously. For a
60 second interval the path would be <code>/usr/lib/check_mk_agent/plugins/60/mk_oracle</code>
The script will test permissions of the files needed to connect to the database. It boils down to the following:
<code>mk_oracle</code> will switch to the owner of
<code>$ORACLE_HOME/bin/sqlplus</code> before executing <code>sqlplus</code>. So
this user has to have the following permissions:
<ul>
<li>read <code>$TNS_ADMIN/sqlnet.ora</code></li>
<li>read <code>$TNS_ADMIN/tnsnames.ora</code></li>
<li>execute the wallet folder (<code>/etc/check_mk/oracle_wallet</code> if followed the official documentation)</li>
<li>read files inside the wallet folder (<code>/etc/check_mk/oracle_wallet/*</code> if followed the official documentation)</li>
</ul>
Beside that we also fixed some bash syntax errors we introduced with
<a href="https://checkmk.com/werk/16232">Werk #16232</a>.
See <a href="https://checkmk.atlassian.net/wiki/spaces/KB/pages/70582273/Troubleshooting…">Troubleshooting mk_oracle for Windows and Linux</a>
for more information about troubleshooting this problem.
Title: mk_oracle: report failed login
Class: fix
Compatible: compat
Component: checks
Date: 1712738280
Edition: cre
Level: 1
Version: 2.2.0p25
Due to fixes introduced with
<a href="https://checkmk.com/werk/16234">Werk #16234</a> a failed login to the
oracle database was not reported as critical, but the services were going
stale. This is now fixed.
Title: omd update: Fix Checkmk Free Edition Crash
Class: fix
Compatible: compat
Component: omd
Date: 1713275522
Edition: cre
Level: 1
Version: 2.2.0p25
While upgrading from the 2.1.0 Checkmk Free Edition to a 2.2.0 Checkmk Enterprise Edition, the
following crash occured and the update failed:
C+:
File "/omd/versions/2.2.0p21.cce/lib/python3.11/enum.py", line 790, in __getitem__
return cls._member_map_[name]
KeyError: 'CFE'
C-:
This crash is now fixed.
[//]: # (werk v2)
# Synthetic Monitoring: Incompatible overhauls
key | value
---------- | ---
date | 2024-04-17T11:05:50+00:00
version | 2.4.0b1
class | feature
edition | cee
component | checks
level | 1
compatible | no
This werk only affects users who have configured the rule *Robotmk scheduler (Windows)* during the
2.3.0 beta phase. The following incompatible changes have been made:
* The plan naming convention introduced in [werk 16421](https://checkmk.com/werk/16421) has been adopted in more places, both internally and user-facing.
* The service items of the *RMK Plan* and *RMK Test* services have been reworked to include the name of the corresponding top-level Robot Framework suite.
* Previously, the scheduler terminated in case of permission issues for example with its working directory. As of this werk, the scheduler instead skips affected plans and forwards these issues to the Checkmk server, where they are reported to the user.
After updating, the *RMK scheduler status* service will report UNKNOWN. The plan and test services
will go stale. Furthermore, the *Check_MK* service will report that there is monitoring data missing
for the plugins `robotmk_plan` and `robotmk_test`. To remedy these issues, users first have to re-
bake and then update the Checkmk agent on affected systems. After updating the agent, users have to
re-discover the services of affected Checkmk hosts.
Werk 16651 was deleted. The following Werk is no longer relevant.
[//]: # (werk v2)
# "TSM - IBM Tivoli Storage Manager (Linux, Unix)": Agent plugin rules are merged
key | value
---------- | ---
date | 2024-04-04T13:12:06+00:00
version | 2.4.0b1
class | feature
edition | cee
component | agents
level | 1
compatible | yes
Multiple matching rules of the bakery configuration ruleset "TSM - IBM Tivoli Storage Manager (Linux, Unix)" will now be merged to compute the set of effective parameters.
Previously only the first matching rule was applied.
During the migration to Checkmk 2.4 existing rules will be "filled", such that the outcome of the rule evaluation will not change on existing configurations.
[//]: # (werk v2)
# "TSM - IBM Tivoli Storage Manager (Linux, Unix)": Agent plugin rules are merged
key | value
---------- | ---
date | 2024-04-04T13:12:06+00:00
version | 2.4.0b1
class | feature
edition | cee
component | agents
level | 1
compatible | yes
Multiple matching rules of the bakery configuration ruleset "TSM - IBM Tivoli Storage Manager (Linux, Unix)" will now be merged to compute the set of effective parameters.
Previously only the first matching rule was applied.
During the migration to Checkmk 2.4 existing rules will be "filled", such that the outcome of the rule evaluation will not change on existing configurations.
[//]: # (werk v2)
# Ruleset API: Fix migration with scaling of SimpleLevels
key | value
---------- | ---
date | 2024-04-17T11:19:36+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | no
This change is relevant to plugin developers
The migration helper functions `migrate_to_integer_simple_levels` and `migrate_to_float_simple_levels` for `SimpleLevels` currently apply the scaling factor (if given) every time the migration is run, meaning also to the already migrated value.
This means any rule where these helpers are used with a scaling factor will have incorrect values and will have to be manually corrected.
No shipped rules are affected by this.