Checkmk werks level1 May 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
549 discussions

[2.3.0] Checkmk Werk 16755 created: mem_win: rename 'Commit Charge' to 'Virtual Memory' for correctness

by Checkmk werks level 1

[//]: # (werk v2) # mem_win: rename 'Commit Charge' to 'Virtual Memory' for correctness key | value ---------- | --- date | 2024-04-19T12:34:59+00:00 version | 2.3.0b6 class | fix edition | cre component | checks level | 1 compatible | yes The value previously displayed as 'Commit Charge' did not match its description. Therefore, this value has been accurately renamed to 'Virtual Memory,' while maintaining the original calculation method. Correspondingly, the titles of related graphs have been adjusted to reflect this change. In versions prior to 2.3, the service summary included a metric labeled 'Pagefile installed.' This has now been correctly renamed to 'Total Virtual Memory,' as it never accurately represented the 'Pagefile installed.'

3 months, 3 weeks

[2.3.0] Checkmk Werk 16790 created: Ruleset API: Fix error during AgentConfig creation

by Checkmk werks level 1

[//]: # (werk v2) # Ruleset API: Fix error during AgentConfig creation key | value ---------- | --- date | 2024-04-19T11:48:42+00:00 version | 2.3.0b6 class | fix edition | cre component | checks level | 1 compatible | yes When creating an `AgentConfig` rulespec using the Ruleset API an error ``` KeyError: 'cmk-match-type' ``` was raised.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16759 created: check certificate: correctly load old Check certificates rules

by Checkmk werks level 1

[//]: # (werk v2) # check certificate: correctly load old Check certificates rules key | value ---------- | --- date | 2024-04-18T13:54:00+00:00 version | 2.3.0b6 class | fix edition | cre component | checks level | 1 compatible | yes Upgrading from 2.3.0b3 to 2.3.0b4 could lead to the _Check certificates_ rules being incorrectly loaded due to a missing field in the old settings. This werk ensures a correct loading by automatically setting the missing parameters.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16754 created: docker_container: skip on incomplete data for diskstat and memory

by Checkmk werks level 1

[//]: # (werk v2) # docker_container: skip on incomplete data for diskstat and memory key | value ---------- | --- date | 2024-04-16T10:28:20+00:00 version | 2.3.0b6 class | fix edition | cre component | checks level | 1 compatible | yes During the data parsing of a container, it is possible to encounter incomplete metric sets, which previously caused a crash. Since the data in these instances is simply unavailable, we now skip the discovery or check cycle for such cases. This adjustment is applied to docker container disktat and memory check plugins.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16790 deleted: Ruleset API: Fix error during AgentConfig creation

by Checkmk werks level 1

Werk 16790 was deleted. The following Werk is no longer relevant. [//]: # (werk v2) # Ruleset API: Fix error during AgentConfig creation key | value ---------- | --- date | 2024-04-19T11:48:42+00:00 version | 2.3.0b6 class | fix edition | cre component | checks level | 1 compatible | yes When creating an `AgentConfig` rulespec using the Ruleset API an error ``` KeyError: 'cmk-match-type' ``` was raised.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16800 created: Fix crash in SNMPv1 and SNMPv2 connection tests

by Checkmk werks level 1

[//]: # (werk v2) # Fix crash in SNMPv1 and SNMPv2 connection tests key | value ---------- | --- date | 2024-04-19T15:28:03+00:00 version | 2.3.0b6 class | fix edition | cre component | wato level | 1 compatible | yes When running the SNMP connection tests for a host that has SNMPv3 credentials configured, the SNMPv1 and SNMPv2 connection tests crashed. With the Inline SNMP backend, the corresponding error message read "argument 2 must be str, not tuple". With the Classic backend, there was no error message at all.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16666 created: Deprecate "Asynchronous execution of plug-ins" rule

by Checkmk werks level 1

[//]: # (werk v2) # Deprecate "Asynchronous execution of plug-ins" rule key | value ---------- | --- date | 2024-04-22T06:19:27+00:00 version | 2.3.0b6 class | fix edition | cee component | setup level | 1 compatible | yes Th rule "Asynchronous execution of plug-ins" has no affect on the execution of the scrips therefore it is being deprecated. This means it will eventually be removed in future versions.

3 months, 3 weeks

[2.3.0] Checkmk Werk 15329 created: mk_oracle: fix two parse errors

by Checkmk werks level 1

[//]: # (werk v2) # mk_oracle: fix two parse errors key | value ---------- | --- compatible | yes version | 2.3.0b6 date | 2024-04-09T06:01:31+00:00 level | 1 class | fix component | checks edition | cre 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.

3 months, 3 weeks

[2.3.0] Checkmk Werk 15328 created: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora

by Checkmk werks level 1

[//]: # (werk v2) # mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora key | value ---------- | --- compatible | no version | 2.3.0b6 date | 2024-04-05T09:38:28+00:00 level | 1 class | fix component | checks edition | cre 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.

3 months, 3 weeks

[2.3.0] Checkmk Werk 15327 created: mk_oracle: Follow-up to privilege escalation fix

by Checkmk werks level 1

[//]: # (werk v2) # mk_oracle: Follow-up to privilege escalation fix key | value ---------- | --- compatible | no version | 2.3.0b6 date | 2024-04-04T07:59:38+00:00 level | 2 class | fix component | checks edition | cre 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.

3 months, 3 weeks

← Newer
1
...
14
15
16
17
18
19
20
...
55
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 May 2024