Merge branch 'master' into nvme-smart-monitoring

.bazelrc

@@ -1,6 +1,5 @@
 # https://docs.bazel.build/versions/main/best-practices.html#using-the-bazelrc-file
 try-import %workspace%/user.bazelrc
-try-import /etc/ci.bazelrc
 
 # default/common bazel args for all commands supporting it
 common --experimental_ui_max_stdouterr_bytes=10000000
@@ -12,6 +11,8 @@ common --remote_local_fallback
 common --cycles
 common --local_resources=cpu=HOST_CPUS-2
 common --local_resources=memory=HOST_RAM*.5
+# We standardized on Ubuntu, a Debian-based distro, so LSB
+common --@//:filesystem_layout=lsb
 
 ## For specific commands
 # Always require debug info.
@@ -24,6 +25,11 @@ build --flag_alias=cmk_version=//:cmk_version
 # valgrind-clean again, which is a crucial feature for debugging the NEB & CMC!
 build --copt="-DRE2_ON_VALGRIND"
 
+# Don't require system python for bootstrapping
+# See: https://github.com/bazelbuild/rules_python/commit/f5b19dce7bc0837396ac03a425cdb9b64643cf61
+# TODO: should be dropped as soon as this becomes the default
+build --@rules_python//python/config_settings:bootstrap_impl=script
+
 clean --async
 # all bazel-created temporary and build output files
 # clean --expunge
@@ -42,6 +48,9 @@ common:ci --local_resources=cpu=HOST_CPUS
 common:ci --local_resources=memory=HOST_RAM*.67
 common:ci --lockfile_mode=error
 
+# No standard in the CI where we must explicitly differentiate between LSB and FHS.
+common:ci --@//:filesystem_layout=FILESYSTEM_LAYOUT_INVALID
+
 ## For specific commands
 # build:ci ...
 # clean:ci ...
@@ -81,3 +90,6 @@ build:iwyu --output_groups=report
 build:iwyu --@bazel_iwyu//:iwyu_executable=//omd/packages/bazel_iwyu:iwyu_bin
 build:iwyu --@bazel_iwyu//:iwyu_opts="--error"
 build:iwyu --@bazel_iwyu//:iwyu_mappings=//omd/packages/bazel_iwyu:iwyu_mappings
+
+# Must be last
+try-import /etc/ci.bazelrc

.git-blame-ignore-revs

@@ -17,3 +17,5 @@ ceda4094911503651b9c609e8cc13a9fac424ce5
 d9b8ef297ad50067c0459715f3f9dc0612480c97
 241859c84dcb8cfa1f8bc25875ef07a213d3fef9
 059144cfb995c7d58cb5c512890f1de192eaf649
+# precommit: check-yaml
+b99627261d63d02751fdd9675d84c2ff81e6dfb8 # check-yaml

.pre-commit-config.yaml

@@ -26,7 +26,12 @@ repos:
           - id: trailing-whitespace
           - id: check-merge-conflict
             types: [file]
-          - id: check-yaml
+          - id: check-yaml # pre-commit cannot parse utf-16 files
+            exclude: |
+                (?x)(
+                    ^agents/wnx/test_files/config/check_mk_dev_malformed.yml|
+                    ^agents/wnx/test_files/config/check_mk_dev_utf16.yml
+                )
           - id: end-of-file-fixer
             exclude: .werks/.*
           - id: fix-encoding-pragma
@@ -53,14 +58,14 @@ repos:
             language: script
             entry: scripts/run-autoflake
             types: [file, python]
-          - id: isort
-            name: Run isort
-            entry: scripts/run-isort
+          - id: format
+            name: Run format
+            entry: scripts/run-format
             language: script
             types: [file, python]
-          - id: black
-            name: Run black
-            entry: scripts/run-black
+          - id: sort
+            name: Run sort imports
+            entry: scripts/run-sort
             language: script
             types: [file, python]
           - id: bandit

.werks/10471

@@ -12,6 +12,6 @@ If the plugin mk_logwatch is configured to send context along with found message
 the amount of data can become quite large. This werk adds the option of limiting
 the context given for every warning or critical message to a given number of lines
 befor and after the message. For instance, to limit the context to 3 lines before
-and four lines after the message, set the option "limitcontext=3,4".
+and four lines after the message, set the option "maxcontextlines=3,4".
 
 This option can be configured using the WATO rule "Text logfiles".

.werks/14236.md

@@ -0,0 +1,15 @@
+[//]: # (werk v2)
+# Fixed missing hosts on remote sites
+
+key        | value
+---------- | ---
+date       | 2024-09-09T07:25:03+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cme
+component  | wato
+level      | 1
+compatible | yes
+
+If a folder belonging to a customer contained hosts from several sites of the same customer, there was a risk that these hosts were not monitored at all.
+

.werks/15029.md

@@ -0,0 +1,17 @@
+[//]: # (werk v2)
+# Improve setting up new least privileged user roles
+
+key        | value
+---------- | ---
+date       | 2024-09-04T09:48:19+00:00
+version    | 2.4.0b1
+class      | feature
+edition    | cre
+component  | wato
+level      | 1
+compatible | yes
+
+Add new role "Empty template for least privilege roles". The role is not indented to be used
+directly. Instead it can be used to create new roles with only the
+minium required permission. Even on updates you can be sure that the
+derived role does not suddenly get new unexpected permissions.

.werks/15323.md

@@ -0,0 +1,15 @@
+[//]: # (werk v2)
+# mk_postgres: Adapt environment file parsing
+
+key        | value
+---------- | ---
+date       | 2024-01-31T10:45:29+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+Reading variables from the environment file was adapted:
+Lines starting with `#` will now be ignored.

.werks/15341.md

@@ -0,0 +1,17 @@
+[//]: # (werk v2)
+# systemd_units_*_summary: Handle reloading units correctly
+
+key        | value
+---------- | ---
+date       | 2024-08-20T13:34:14+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+Reloading systemd units were not handle correctly: They were always in the state
+specified in "Monitoring state for any other unit state" (CRIT by default) and
+ignored the "Tolerance period for 'reloading' state" configuration (30/60
+seconds by default)

.werks/15342.md

@@ -0,0 +1,18 @@
+[//]: # (werk v2)
+# systemd_units_*_summary: Support units without description
+
+key        | value
+---------- | ---
+date       | 2024-08-20T13:41:37+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+The parser assumed that there is always a description, but systemd seems to be
+okay with units without description.
+
+The units were still detected but some service details were missing, for example
+how long the service was in a temporary state.

.werks/16026.md

@@ -0,0 +1,14 @@
+[//]: # (werk v2)
+# Add support for SLES 15 SP6
+
+key        | value
+---------- | ---
+date       | 2024-08-14T07:25:20+00:00
+version    | 2.4.0b1
+class      | feature
+edition    | cre
+component  | omd
+level      | 1
+compatible | yes
+
+With this werk, Checkmk is build for SLES 15 SP6

.werks/16120.md

@@ -1,5 +1,5 @@
 [//]: # (werk v2)
-# Fixed value of dowtimes:is_pending column
+# Fixed value of downtimes:is_pending column
 
 key        | value
 ---------- | ---

.werks/16122.md

@@ -0,0 +1,16 @@
+[//]: # (werk v2)
+# Fixed site matching for expected regular event console messages
+
+key        | value
+---------- | ---
+date       | 2024-09-11T10:57:26+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | ec
+level      | 1
+compatible | yes
+
+Due to a regression in 2.2.0, the "Match site" option had no effect for
+expected regular messages, i.e. it was effectively ignored in that case.
+This has been fixed.

.werks/16123.md

@@ -0,0 +1,19 @@
+[//]: # (werk v2)
+# Use the original message text for rewriting the comment field
+
+key        | value
+---------- | ---
+date       | 2024-09-11T13:54:07+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | ec
+level      | 1
+compatible | yes
+
+Werk 16534 made the rewriting of the comment field use the comment field
+itself as the basis. For this field, it doesn't really make sense, because
+rewriting is the only way to fill that field, so e.g. \0 was always empty.
+
+With this change, we revert to the old behaviour where all match groups
+refer to the original message text.

.werks/16250.md

@@ -0,0 +1,24 @@
+[//]: # (werk v2)
+# Handle years in ntp output
+
+key        | value
+---------- | ---
+date       | 2024-08-27T11:12:57+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+This werk affects you, in case your last `ntpq` synchronization was indeed more than a year ago.
+
+A potential check crash traceback looks like:
+```
+  File "/omd/sites/SITE/lib/python3/cmk/base/plugins/agent_based/ntp.py", line 67, in _ntp_fmt_time
+    return int(raw)
+ValueError: invalid literal for int() with base 10: '3y'
+```
+
+The year case is now handled in the parse function.
+

.werks/16251.md

@@ -0,0 +1,14 @@
+[//]: # (werk v2)
+# Update monitoring-plugins to 2.4.0
+
+key        | value
+---------- | ---
+date       | 2024-09-04T14:11:06+00:00
+version    | 2.4.0b1
+class      | feature
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+

.werks/16252.md

@@ -0,0 +1,16 @@
+[//]: # (werk v2)
+# Reduce API requests during gcp list-assets
+
+key        | value
+---------- | ---
+date       | 2024-09-10T12:07:04+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+This werk is relevant to you if you've been monitoring gcp assets and experienced exceeded quota torwards the google API.
+The special agent will now only acquire data which is really processed by the check plugin which will reduce the requests torwards gcp.
+

.werks/16253.md

@@ -0,0 +1,14 @@
+[//]: # (werk v2)
+# Cease to provide builds for Centos8
+
+key        | value
+---------- | ---
+date       | 2024-09-16T11:03:06+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | omd
+level      | 1
+compatible | yes
+
+

.werks/16351.md

@@ -0,0 +1,15 @@
+[//]: # (werk v2)
+# Support Diagnostics crashes when receiving tar from remote site
+
+key        | value
+---------- | ---
+date       | 2024-08-05T11:58:01+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cre
+component  | wato
+level      | 1
+compatible | yes
+
+This werk fixes the behavior that creating the support diagnostics crashed when receiving the tar file(s)
+from a remote site.

.werks/16352.md

@@ -0,0 +1,18 @@
+[//]: # (werk v2)
+# Support Diagnostics: Add rotated log files to the dump
+
+key        | value
+---------- | ---
+date       | 2024-08-29T12:12:16+00:00
+version    | 2.4.0b1
+class      | feature
+edition    | cre
+component  | wato
+level      | 1
+compatible | yes
+
+With this werk, it's possible to select rotated logfiles for the dump, for example update.log and update.log.1
+In the "Pack only xyz sensitivity files" and "Pack all files" modes, both are are added automatically.
+In the "Select individual files from the list" mode, the user can select them separately.
+
+Background: In rare cases, the .log files were empty, because the logging process still wrote into the .log.1 file.

.werks/16566.md

@@ -0,0 +1,27 @@
+[//]: # (werk v2)
+# Standardize notification spooler log level configuration
+
+key        | value
+---------- | ---
+date       | 2024-09-02T09:16:08+00:00
+version    | 2.4.0b1
+class      | fix
+edition    | cee
+component  | notifications
+level      | 2
+compatible | yes
+
+The notification spoolers log level was configured differently than other
+services. Previously users had the choice between:
+
+* Normal logging (only startup, shutdown and errors)
+* Verbose logging (also spooled notifications)
+* Debugging (log every single action)
+
+This was changed to the standard log levels which we also use in all other services.
+
+The command line flag `-v` of the `mknotifyd`, which could be used to override
+the configured log level was replaced with the `--log-level=LEVEL` argument.
+While the change to this command line flag is an incompatible change, we don't
+rate this as a change that is worth marking the werk to be incompatible. In the
+end it's only an option used for manual debugging.

.werks/16594.md

@@ -0,0 +1,19 @@
+[//]: # (werk v2)
+# Container: Support setting custom timezone
+
+key        | value
+---------- | ---
+date       | 2024-08-21T15:44:20+00:00
+version    | 2.4.0b1
+class      | feature
+edition    | cre
+component  | packages
+level      | 1
+compatible | yes
+
+The checkmk containers now support setting the TZ variable for a container to specify what timezone the site should use.
+
+The timezone information is then set for the site running inside the container.
+This removes the need to mount timezone files from the host machine into a docker container.
+
+A run command can look like this: `docker container run ... --env TZ="Europe/Berlin" check-mk-enterprise:<version>`