Title: Introduce Last seen for the REST API usage
Class: feature
Compatible: compat
Component: wato
Date: 1700822001
Edition: cre
Level: 1
Version: 2.3.0b1
Prior to this Werk, the last time a REST API user was used was not
displayed in WATO and "Never logged in" was displayed. This Werk
changes the behavior and now displays the date and time of when it
was last used. These are the changes introduced in this Werk:
* Last seen column shows "Never" if the user was never authenticated.
* REST API users show the date and time when they last logged in.
* In the Act. column, the login icon includes the means by which
the authentication information was last received (bearer, cookie, etc.).
Title: primekey_hsm_battery_voltage: Fixed parsing of section when battery voltage is not available
Class: fix
Compatible: compat
Component: checks
Date: 1700831541
Edition: cre
Level: 1
Version: 2.3.0b1
Sometimes the battery voltage was not available or it wasn't a number. That cause the parsing of the section to fail.
This has now been fixed.
In the case of voltage being: 'External Battery: absence", the check status will be OK and the summary will provide details that the battery is absent.
If the voltage is not a number or is not absent, the voltage check will be skipped and the check result will the battery state.
Title: haproxy: Adapted HAproxy Server State and HAproxy Frontend State rules to be item specific
Class: fix
Compatible: compat
Component: wato
Date: 1700826137
Edition: cre
Level: 1
Version: 2.3.0b1
HAproxy Server State and HAproxy Frontend State were not configurable with regard to the service name.
This means that the rules were applied to all services.
This has now been adapted and the rules can be configured to apply to certain services only.
Title: Keep label filters when sorting a view
Class: fix
Compatible: compat
Component: multisite
Date: 1700564389
Edition: cre
Level: 1
Version: 2.3.0b1
When a view was filtered for host/service labels and then sorted by clicking on one of the table headers, the label filters were lost.
This is fixed to conserving the label filters when sorting a view.
Title: Deprecate automation user login via HTTP parameters
Class: feature
Compatible: compat
Component: wato
Date: 1700383158
Edition: cre
Level: 1
Version: 2.3.0b1
Checkmk offers a method to authenticate individual requests with the `_username`/`_secret` parameter.
This also works for GET requests and was used for the Webapi (removed in 2.2).
Having secrets in GET parameters is considered bad practice since these parameters are usually logged by webservers and web proxies.
With this Werk we deprecate this authentication method.
This means we now introduced a configuration option *Enable automation user authentication via HTTP parameters* to enable/disable this method.
By default it is enabled to not interrupt existing workflows.
In Checkmk 2.4 we will disable this by default so it will still be possible to enable this.
In Checkmk 2.5 this method will be removed entirely.
If you currently use this method we recommend to switch to Basic Authentication.
Title: Automationuser login must not open full session
Class: fix
Compatible: incomp
Component: wato
Date: 1700382222
Edition: cre
Knowledge: doc
Level: 1
Version: 2.3.0b1
Checkmk offers a method to authenticate single web requests with URL parameters (<tt>_username</tt> and <tt>_secret</tt>).
Due to some refactoring of the session handling with Checkmk 2.2 such automation requests initiated a full session.
The login for automation users was still blocked in the login screen but an authenticated request initiated a full session that could than be used to browse the Checkmk GUI like a regular user.
With this Werk that is no longer the case.
If you use this authentication method you should check if you rely on sessions for your automation users.
Title: mk_oracle: use "${GREP}" instead of "grep"
Class: fix
Compatible: compat
Component: checks
Date: 1701070131
Edition: cre
Level: 1
Version: 2.3.0b1
When executed on solaris, `"grep"` does not know `-x` or `-F`. "${GREP}" points
to a version of grep that understands those options.
Title: Ignore certificates with negative serial numbers
Class: fix
Compatible: incomp
Component: wato
Date: 1700822338
Edition: cre
Level: 1
Version: 2.2.0p16
X509 certificates contain a serial number which is used for various purposes.
Since RFC5280 (May 2008) certificates must be a positive integer.
There used to be certificates with negative serial numbers which were accepted.
Our underlying libraries start to deprecate the support for these certificates, therefore Checkmk now deems them invalid.
Please note that these certificates are very uncommon.
If Checkmk encounters such a certificate it will log it to `var/log/web.log`.
Werk 978 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Fix security issue with mk-job on Linux
Level: 2
Component: checks
Version: 1.2.5i3
Date: 1401093260
Class: security
Compatible: incomp
By use of symlinks or hardlinks normal users could inject files to be read
with root permissions. This was due to the fact that <tt>/var/lib/check_mk_agent/job</tt>
was installed with the permissions <tt>1777</tt>, just as <tt>/tmp</tt>. That way
a normal user could have placed a symlink to a file there that is only readable
by <tt>root</tt>. The content of that file would then appear in the agent output.
This has been fixed by not longer using <tt>/var/lib/check_mk_agent/job</tt> directly,
but by creating a separate subdirectory below that for each user. This is done by
a new version of <tt>/usr/bin/mk-job</tt>, so please make sure that if you update
the agent that you also update <tt>mk-job</tt>.
Also you now have to create job subdirectories for non-<tt>root</tt> jobs manually.
If you have a job running as user <tt>foo</tt>, then do:
C+:
RP:mkdir -p /var/lib/check_mk_agent/job
RP:chown foo:foo /var/lib/check_mk_agent/job
C-:
If you update the Check_MK Agent with RPMs/DEB from the new agent bakery or by
an RPM/DEB created from the source code with <tt>make rpm</tt> or <tt>make deb</tt>
then the permissions of <tt>/var/lib/check_mk_agent/job</tt> are automatically
fixed.
If you have installed the agent manually then please make sure that the permissions
of the job directory are set properly:
C+:
RP:chmod 755 /var/lib/check_mk_agent/job
C-:
------------------------------------<diff>-------------------------------------------
Title: Fix security issue with mk-job on Linux
Level: 2
Component: checks
Version: 1.2.5i3
Date: 1401093260
Class: security
Compatible: incomp
By use of symlinks or hardlinks normal users could inject files to be read
with root permissions. This was due to the fact that <tt>/var/lib/check_mk_agent/job</tt>
was installed with the permissions <tt>1777</tt>, just as <tt>/tmp</tt>. That way
a normal user could have placed a symlink to a file there that is only readable
by <tt>root</tt>. The content of that file would then appear in the agent output.
This has been fixed by not longer using <tt>/var/lib/check_mk_agent/job</tt> directly,
but by creating a separate subdirectory below that for each user. This is done by
a new version of <tt>/usr/bin/mk-job</tt>, so please make sure that if you update
the agent that you also update <tt>mk-job</tt>.
Also you now have to create job subdirectories for non-<tt>root</tt> jobs manually.
If you have a job running as user <tt>foo</tt>, then do:
C+:
RP:mkdir -p /var/lib/check_mk_agent/job
- RP:chown foo.foo /var/lib/check_mk_agent/job
? ^
+ RP:chown foo:foo /var/lib/check_mk_agent/job
? ^
C-:
If you update the Check_MK Agent with RPMs/DEB from the new agent bakery or by
an RPM/DEB created from the source code with <tt>make rpm</tt> or <tt>make deb</tt>
then the permissions of <tt>/var/lib/check_mk_agent/job</tt> are automatically
fixed.
If you have installed the agent manually then please make sure that the permissions
of the job directory are set properly:
C+:
RP:chmod 755 /var/lib/check_mk_agent/job
C-:
Title: Ignore certificates with negative serial numbers
Class: fix
Compatible: incomp
Component: wato
Date: 1700822338
Edition: cre
Level: 1
Version: 2.3.0b1
X509 certificates contain a serial number which is used for various purposes.
Since RFC5280 (May 2008) certificates must be a positive integer.
There used to be certificates with negative serial numbers which were accepted.
Our underlying libraries start to deprecate the support for these certificates, therefore Checkmk now deems them invalid.
Please note that these certificates are very uncommon.
If Checkmk encounters such a certificate it will log it to <code>var/log/web.log</code>.