[//]: # (werk v2)
# Split up rule "Main memory usage of simple devices"
key | value
---------- | ---
date | 2023-12-23T14:52:41+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | no
This affects all users that had rules for "Main memory usage of simple devices" configured.
To clean up inconsistencies that the new APIs no longer tolerate, we had to split the ruleset into two.
We renamed "Main memory usage of simple devices" to "Main memory usage of simple devices with multiple services" and added a new ruleset "Main memory usage of simple devices with single services".
The required new rules are created automatically during upgrade, but we advise users to check if they have rules that are not needed anymore.
The plugins using the new ruleset are
* Check Point Firewalls: Memory Usage (`checkpoint_memory`)
* HPE Procurve Switches: Memory Usage (`hp_procurve_mem`)
* UCD SNMP Daemon: Memory Check (`ucd_mem`)
[//]: # (werk v2)
# Agent updater: allow automation user to login with password
key | value
---------- | ---
date | 2024-01-02T16:50:40+00:00
version | 2.3.0b1
class | fix
edition | cee
component | agents
level | 1
compatible | yes
Up to now, when using the agent updater CLI, you would have to use the
`--password` (or `-P`) parameter to specify the password for a human
user and the `--secret` (or `-S`) parameter to specify the secret for
an automation user.
This starts to be confusing with the interactive mode: in that case the
program assumes that you are using a human user and will fail if the
credentials that you enter are valid credentials for an automation user.
On top of that, the error message is completely misleading.
With this commit, we are changing the behavior of the agent updater so
that an automation user credentials will work even if the secret is
specified with the `--password` (or `-P`) param.
This way the end user don't have to care about which param name is the
right one to use: they can just specify the password, or the secret,
with the `--password` param and it will work.
This also allows the interactive mode to work with an automation user.
This change is backward compatible, meaning that everything that used to
work up until now, will keep working even after this.
Title: ibm storwize: Fix missing data when monitoring nodes
Class: fix
Compatible: compat
Component: checks
Date: 1704272720
Edition: cre
Level: 1
Version: 2.2.0p18
lsnodestats command was used for monitoring nodes in IBM Storwize devices.
Storwize devices don't have the lsnodestats command which led to missing data
in ibm_svc_nodestats services.
Now, the IBM SVC agent uses the lsnodestats if it's available and lsnodecanisterstats
otherwise.
[//]: # (werk v2)
# ibm storwize: Fix missing data when monitoring nodes
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-01-03T09:05:20+00:00
level | 1
class | fix
component | checks
edition | cre
lsnodestats command was used for monitoring nodes in IBM Storwize devices.
Storwize devices don't have the lsnodestats command which led to missing data
in ibm_svc_nodestats services.
Now, the IBM SVC agent uses the lsnodestats if it's available and lsnodecanisterstats
otherwise.
Title: "Cisco Devices: Temperature Sensors" used wrong lower device levels
Class: fix
Compatible: compat
Component: checks
Date: 1702899571
Edition: cre
Level: 1
Version: 2.1.0p38
The services picked the device levels meant for a "less than" comarison,
when in fact comparing "less or equal" (as Checkmk usually does).
They now pick the levels meant for "less or equal" comparison.
Title: "Cisco Devices: Temperature Sensors" used wrong lower device levels
Class: fix
Compatible: compat
Component: checks
Date: 1702899571
Edition: cre
Level: 1
Version: 2.2.0p18
The services picked the device levels meant for a "less than" comarison,
when in fact comparing "less or equal" (as Checkmk usually does).
They now pick the levels meant for "less or equal" comparison.
[//]: # (werk v2)
# "Cisco Devices: Temperature Sensors" used wrong lower device levels
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2023-12-18T11:39:31+00:00
level | 1
class | fix
component | checks
edition | cre
The services picked the device levels meant for a "less than" comarison,
when in fact comparing "less or equal" (as Checkmk usually does).
They now pick the levels meant for "less or equal" comparison.
[//]: # (werk v2)
# primekey_fan: rename service description to 'Primekey Fan'
key | value
---------- | ---
date | 2023-12-20T09:43:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | no
You are affected by this change if you monitor a Primekey appliance and use
searches or rules that rely on the service description.
In order to unify the primeky checks `primekey_fan` services description was
renamed from 'Fan Primekey' to 'Primekey Fan'.