Title: service_discovery: redirect response header incorrectly configured to an absolute URI
Class: fix
Compatible: compat
Component: rest-api
Date: 1700141008
Edition: cre
Level: 1
Version: 2.3.0b1
When calling the service discovery endpoint, the redirect response
header 'location' was set to an absolute URI, when it should be a
relative URI.
This werk addresses this issue by setting the URI correctly in the
redirect responses.
Werk 15307 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: logwatch_ec: tcp remote forwarding: create one spool file per service
Class: fix
Compatible: compat
Component: checks
Date: 1699863833
Edition: cre
Knowledge: doc
Level: 1
Version: 2.1.0p37
This Werk affects you if you have a logwatch_ec check which forwards events to
a remote syslog hosts and if you activated the option "Create a separate check
for each logfile".
In this case all separate services shared one spoolfile. This lead to the
problem, that one event in the spoolfile was displayed as one event for each
separate service (but it was only sent out once, when the remote was reachable
again).
In some conditions events might been unnoticeable dropped, because the
spoolfile was overwritten by another logwatch service.
Now each logwatch service will have their own spoolfile.
The spoolfiles will be automatically assigned to their logwatch service.
After all your logwatch_ec services sent all their spoolfiles out, you may
manually consult the following folder for <tt>spoolfile.*</tt> files:
<tt>./var/check_mk/logwatch_spool/<hostname></tt>
If there are any spoolfiles in this folder, they could not be assigned to a
logwatch service. If you still want them to be forwarded, move them to one of
the folders, otherwise they can be deleted.
<tt>./var/check_mk/logwatch_spool/<hostname>/item_<url_encode(item)></tt>
------------------------------------<diff>-------------------------------------------
Title: logwatch_ec: tcp remote forwarding: create one spool file per service
Class: fix
Compatible: compat
Component: checks
Date: 1699863833
Edition: cre
Knowledge: doc
Level: 1
Version: 2.1.0p37
This Werk affects you if you have a logwatch_ec check which forwards events to
a remote syslog hosts and if you activated the option "Create a separate check
for each logfile".
In this case all separate services shared one spoolfile. This lead to the
problem, that one event in the spoolfile was displayed as one event for each
separate service (but it was only sent out once, when the remote was reachable
again).
In some conditions events might been unnoticeable dropped, because the
spoolfile was overwritten by another logwatch service.
Now each logwatch service will have their own spoolfile.
The spoolfiles will be automatically assigned to their logwatch service.
After all your logwatch_ec services sent all their spoolfiles out, you may
manually consult the following folder for <tt>spoolfile.*</tt> files:
<tt>./var/check_mk/logwatch_spool/<hostname></tt>
If there are any spoolfiles in this folder, they could not be assigned to a
logwatch service. If you still want them to be forwarded, move them to one of
- the hash folders, otherwise they can be deleted.
? -----
+ the folders, otherwise they can be deleted.
- <tt>./var/check_mk/logwatch_spool/<hostname>/<<sha1_hash_of_item></tt>
? ^ ^^^^ ^^^^^ ^^
+ <tt>./var/check_mk/logwatch_spool/<hostname>/item_<url_encode(item)></tt>
? ^^^^^ ^^^ ^^^ ^^^ +
Title: mssql_backup: Correct timezone difference for last backup date
Class: fix
Compatible: compat
Component: checks
Date: 1696949130
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.1.0p37
This werk is relevant for users monitoring the age of the last backup time of mssql databases in different timezones.
The date/time of the last backup of a mssql database is currently stored in local host time without the information about the host timezone. When this time is used to check the age of the last backup, it is interpreted in the Checkmk server timezone.
When using different timezones, this leads to incorrect values for "Age of last database backup" and if the age is negative, in newer Checkmk versions to the warning "Cannot reasonably calculate time since last backup (hosts time running ahead)".
The mssql agent plugin will now store the time in UTC and the mssql_backup check will interpret the time accordingly.
You will need to update the agent plugin mssql.vbs to receive the corrected times.
Title: "Always up" hosts can always notify
Class: fix
Compatible: compat
Component: core
Date: 1699884551
Edition: cee
Knowledge: undoc
Level: 1
State: unknown
Version: 2.1.0p37
Do not postpone notifications for "always up" hosts.
The notification logic would wrongly assume that "always up" hosts may,
in fact, be down and erroneously postpone notifications. This has been
fixed, such hosts are never down.
Werk 15307 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: logwatch_ec: tcp remote forwarding: create one spool file per service
Class: fix
Compatible: compat
Component: checks
Date: 1699863833
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p15
This Werk affects you if you have a logwatch_ec check which forwards events to
a remote syslog hosts and if you activated the option "Create a separate check
for each logfile".
In this case all separate services shared one spoolfile. This lead to the
problem, that one event in the spoolfile was displayed as one event for each
separate service (but it was only sent out once, when the remote was reachable
again).
In some conditions events might been unnoticeable dropped, because the
spoolfile was overwritten by another logwatch service.
Now each logwatch service will have their own spoolfile.
The spoolfiles will be automatically assigned to their logwatch service.
After all your logwatch_ec services sent all their spoolfiles out, you may
manually consult the following folder for <tt>spoolfile.*</tt> files:
<tt>./var/check_mk/logwatch_spool/<hostname></tt>
If there are any spoolfiles in this folder, they could not be assigned to a
logwatch service. If you still want them to be forwarded, move them to one of
the folders, otherwise they can be deleted.
<tt>./var/check_mk/logwatch_spool/<hostname>/item_<url_encode(item)></tt>
------------------------------------<diff>-------------------------------------------
Title: logwatch_ec: tcp remote forwarding: create one spool file per service
Class: fix
Compatible: compat
Component: checks
Date: 1699863833
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p15
This Werk affects you if you have a logwatch_ec check which forwards events to
a remote syslog hosts and if you activated the option "Create a separate check
for each logfile".
In this case all separate services shared one spoolfile. This lead to the
problem, that one event in the spoolfile was displayed as one event for each
separate service (but it was only sent out once, when the remote was reachable
again).
In some conditions events might been unnoticeable dropped, because the
spoolfile was overwritten by another logwatch service.
Now each logwatch service will have their own spoolfile.
The spoolfiles will be automatically assigned to their logwatch service.
After all your logwatch_ec services sent all their spoolfiles out, you may
manually consult the following folder for <tt>spoolfile.*</tt> files:
<tt>./var/check_mk/logwatch_spool/<hostname></tt>
If there are any spoolfiles in this folder, they could not be assigned to a
logwatch service. If you still want them to be forwarded, move them to one of
- the hash folders, otherwise they can be deleted.
? -----
+ the folders, otherwise they can be deleted.
- <tt>./var/check_mk/logwatch_spool/<hostname>/<<sha1_hash_of_item></tt>
? ^ ^^^^ ^^^^^ ^^
+ <tt>./var/check_mk/logwatch_spool/<hostname>/item_<url_encode(item)></tt>
? ^^^^^ ^^^ ^^^ ^^^ +
Title: mssql_backup: Correct timezone difference for last backup date
Class: fix
Compatible: compat
Component: checks
Date: 1696949130
Edition: cre
Knowledge: doc
Level: 1
State: unknown
Version: 2.2.0p15
This werk is relevant for users monitoring the age of the last backup time of mssql databases in different timezones.
The date/time of the last backup of a mssql database is currently stored in local host time without the information about the host timezone. When this time is used to check the age of the last backup, it is interpreted in the Checkmk server timezone.
When using different timezones, this leads to incorrect values for "Age of last database backup" and if the age is negative, in newer Checkmk versions to the warning "Cannot reasonably calculate time since last backup (hosts time running ahead)".
The mssql agent plugin will now store the time in UTC and the mssql_backup check will interpret the time accordingly.
You will need to update the agent plugin mssql.vbs to receive the corrected times.
Title: "Always up" hosts can always notify
Class: fix
Compatible: compat
Component: core
Date: 1699884551
Edition: cee
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
Do not postpone notifications for "always up" hosts.
The notification logic would wrongly assume that "always up" hosts may,
in fact, be down and erroneously postpone notifications. This has been
fixed, such hosts are never down.
Title: logwatch_ec: tcp remote forwarding: create one spool file per service
Class: fix
Compatible: compat
Component: checks
Date: 1699863833
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p15
This Werk affects you if you have a logwatch_ec check which forwards events to
a remote syslog hosts and if you activated the option "Create a separate check
for each logfile".
In this case all separate services shared one spoolfile. This lead to the
problem, that one event in the spoolfile was displayed as one event for each
separate service (but it was only sent out once, when the remote was reachable
again).
In some conditions events might been unnoticeable dropped, because the
spoolfile was overwritten by another logwatch service.
Now each logwatch service will have their own spoolfile.
The spoolfiles will be automatically assigned to their logwatch service.
After all your logwatch_ec services sent all their spoolfiles out, you may
manually consult the following folder for <tt>spoolfile.*</tt> files:
<tt>./var/check_mk/logwatch_spool/<hostname></tt>
If there are any spoolfiles in this folder, they could not be assigned to a
logwatch service. If you still want them to be forwarded, move them to one of
the hash folders, otherwise they can be deleted.
<tt>./var/check_mk/logwatch_spool/<hostname>/<<sha1_hash_of_item></tt>