Checkmk werks level1 April 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
306 discussions

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

by Checkmk werks level 1

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.

5 months

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

by Checkmk werks level 1

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.

5 months

[2.1.0] Checkmk Werk 15330 created: mk_oracle: report failed login

by Checkmk werks level 1

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.

5 months

[2.2.0] Checkmk Werk 15331 created: postgres_stat_database_size: Don't discover 'access_to_shared_objects'

by Checkmk werks level 1

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.

5 months

[2.2.0] Checkmk Werk 15332 created: Inventory: Add Windows support for Hardware > System > Uuid

by Checkmk werks level 1

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.

5 months

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

by Checkmk werks level 1

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.

5 months

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

by Checkmk werks level 1

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.

5 months

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

by Checkmk werks level 1

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.

5 months

[2.2.0] Checkmk Werk 15330 created: mk_oracle: report failed login

by Checkmk werks level 1

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.

5 months

[2.2.0] Checkmk Werk 16422 created: omd update: Fix Checkmk Free Edition Crash

by Checkmk werks level 1

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.

5 months

← Newer
1
...
17
18
19
20
21
22
23
...
31
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 April 2024