[//]: # (werk v2)
# Linux agent: drop support for FreeIPMI 0.8.0 and earlier
key | value
---------- | ---
date | 2024-04-17T20:21:00+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | no
This change is only incompatible for users monitoring hosts with a FreeIPMI
version of 0.8.0 or earlier.
FreeIPMI 0.8.1 was released in December 2009.
[//]: # (werk v2)
# Logfile pattern analyzer: Fix crash for first rule without regex pattern
key | value
---------- | ---
date | 2024-04-17T08:10:14+00:00
version | 2.4.0b1
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
The "Logfile pattern analyzer" page crashed when the first "Logfile pattern" rule in place did not hold a regex pattern and a later rule did hold a regex pattern.
The rendering of the table of rules would crash with
```
Internal error: list index out of range
```
This is fixed and all rules are rendered as expected.
[//]: # (werk v2)
# Licensing: Reset license state when updating from Enterprise to non-Enterprise
key | value
---------- | ---
date | 2024-04-17T16:10:14+00:00
version | 2.4.0b1
class | fix
edition | cee
component | setup
level | 1
compatible | no
When upgrading from an Enterprise to another edition is performed, the site will start a new trial period, even if licensing credentials had already been configured.
To license the product, a license verification needs to be performed (on the licensing page: Setup > Maintenance > Licensing > Online/Offline verification).
[//]: # (werk v2)
# Support Diagnostics: The timeout for creating a dump is now configurable
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-04-12T11:07:00+00:00
level | 1
class | feature
component | wato
edition | cre
Before this werk, the process of creating a Support Diagnostics Dump sometimes lead to a timeout exception. The hard-coded timeout was 110s.
Now, it's possible to configure the timeout in the user interface.
[//]: # (werk v2)
# ldap: show the correct customer for ldap users
key | value
---------- | ---
date | 2024-04-18T14:03:11+00:00
version | 2.4.0b1
class | fix
edition | cme
component | wato
level | 1
compatible | yes
When an ldap connection is configured for a specific customer, this
wasn't reflected in the users for that ldap connection. This werk
addresses this issue by now showing the correct customer.
Title: mk_oracle: fix two parse errors
Class: fix
Compatible: compat
Component: checks
Date: 1712642491
Edition: cre
Level: 1
Version: 2.1.0p42
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.1.0p42
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.1.0p42
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.1.0p42
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: postgres_stat_database_size: Don't discover 'access_to_shared_objects'
Class: fix
Compatible: incomp
Component: checks
Date: 1713251421
Edition: cre
Level: 1
Version: 2.2.0p25
Checkmk discovered Services like "PostgreSQL DB MAIN/access_to_shared_objects
Size" but the Services only showed "Database size not available" and a WARN
status.
Those Services are no longer discovered.