13285 Commits

Author SHA1 Message Date
Alexander A. Klimov
a3b00fdb87 tools/win32/configure*.ps1: allow custom $CMAKE_ARGS (JSON array) 2025-01-22 10:08:26 +01:00
Yonas Habteab
f0dccf7020
Merge pull request #10256 from Icinga/gha21311
Update GHA
2024-11-29 16:18:48 +01:00
Alexander A. Klimov
f5e4578454 GHA: Linux: don't track all supported distro versions
Instead just give a generic explanation per distro.
2024-11-29 14:32:49 +01:00
Alexander Aleksandrovič Klimov
000a611fab GHA: update supported Fedora versions
Add v41, drop EOL v37, v38.
2024-11-29 14:31:30 +01:00
Yonas Habteab
c11549a3c7 GHA: Drop ubuntu 23.{04,10} (EOL) 2024-11-29 14:30:19 +01:00
Alexander Aleksandrovič Klimov
7caa52b374
Merge pull request #10242 from Icinga/probot/sync-changelog/support/2.13/9c9af8e3e7298baf21c767bf5094fd38dbd6fe22
CHANGELOG.md: add v2.11.12
2024-11-14 16:54:47 +01:00
Alexander A. Klimov
c18338f837 CHANGELOG.md: add v2.11.12 2024-11-14 15:53:46 +00:00
Yonas Habteab
9c9af8e3e7
Merge pull request #10241 from Icinga/state-before-suppression213
Fix lost recovery notifications after recovery outside of notification time period
2024-11-14 16:53:35 +01:00
Julian Brost
069a56d84f Use Checkable::GetStateBeforeSuppression() only where relevant
This fixes an issue where recovery notifications get lost if they happen
outside of a notification time period.

Not all calls to `Checkable::NotificationReasonApplies()` need
`GetStateBeforeSuppression()` to be checked. In fact, for one caller,
`FireSuppressedNotifications()` in
`lib/notification/notificationcomponent.cpp`, the state before suppression may
not even be initialized properly, so that the default value of OK is used which
can lead to incorrect return values. Note the difference between suppressions
happening on the level of the `Checkable` object level and the `Notification`
object level. Only the first sets the state before suppression in the
`Checkable` object, but so far, also the latter used that value incorrectly.

This commit moves the check of `GetStateBeforeSuppression()` from
`Checkable::NotificationReasonApplies()` to the one place where it's actually
relevant: `Checkable::FireSuppressedNotifications()`. This made the existing
call to `NotificationReasonApplies()` unneccessary as it would always return
true: the `type` argument is computed based on the current check result, so
there's no need to check it against the current check result.
2024-11-14 15:01:14 +01:00
Julian Brost
4cdcaeaa65
Merge commit from fork
Icinga 2.13.10
2024-11-12 15:01:57 +01:00
Alexander A. Klimov
6b362d6c93 Resolve merge conflicts with support/2.13
This reverts commit 5ea8dcf471fcfa5d9a2c4b4ff3371a46b5aac228
which has already been cherry-picked there, but is also needed for v2.13.10.

This has the same effect as `git merge support/2.13`, but involves no merge,
no conflict resolution, less commits and a smaller diff.
2024-10-25 16:40:22 +02:00
Alexander A. Klimov
0eb2949923 Icinga 2.13.10 v2.13.10 2024-10-25 16:40:16 +02:00
Alexander Aleksandrovič Klimov
237b8803aa
Merge pull request #10203 from Icinga/gha21310
Fix GitHub actions
2024-10-24 10:27:53 +02:00
Alexander Aleksandrovič Klimov
28f6341daa GHA: Linux: include Ubuntu 24.10 2024-10-23 16:15:45 +02:00
Alexander A. Klimov
375824f961 GHA: Windows: don't require git.icinga.com/packaging/windows-icinga2
"A little copying is better than a little dependency."
- https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s
(Gopherfest 2015 | Go Proverbs with Rob Pike)
2024-10-23 16:15:45 +02:00
Alexander A. Klimov
5ea8dcf471 Bump OpenSSL shipped for Windows to v3.0.15 2024-10-22 10:55:14 +02:00
Julian Brost
3504fc7ed6 Security: fix TLS certificate validation bypass
The previous validation in set_verify_callback() could be bypassed, tricking
Icinga 2 into treating invalid certificates as valid. To fix this, the
validation checks were moved into the IsVerifyOK() function.

This is tracked as CVE-2024-49369, more details will be published at a later time.
2024-10-22 10:42:15 +02:00
Yonas Habteab
c900552245
Merge pull request #10175 from Icinga/213OpenSSL3015
Bump OpenSSL shipped for Windows to v3.0.15
2024-10-17 12:59:24 +02:00
Alexander A. Klimov
56f2eacccc Bump OpenSSL shipped for Windows to v3.0.15 2024-09-26 11:50:36 +02:00
Yonas Habteab
4780998444
Merge pull request #10165 from Icinga/formatdatetime-2.13
Overhaul Utility::FormatDateTime()
2024-09-24 12:35:14 +02:00
Yonas Habteab
14d4dd6c5d
Merge pull request #10168 from Icinga/next-check-cluster-sync-issue-2.13
Checkable: Don't recalculate `next_check` while processing remotely genrated check
2024-09-23 12:39:17 +02:00
Julian Brost
396ce871ec Utility::FormatDateTime(): provide an overload for tm*
This allows the function to be used both with a double timestamp or a pointer
to a tm struct. With this, a similar implementation inside the tests can simply
use our regular function.
2024-09-23 10:54:26 +02:00
Alexander A. Klimov
2c34d00261 Don't use std::quoted(), it requires C++14 2024-09-23 10:53:56 +02:00
Julian Brost
8eaab27bd0 Utility::FormatDateTime(): handle invalid format strings on Windows
On Windows, the strftime() function family invokes an invalid parameter handler
when the format string is invalid (see the "Remarks" section in their
documentation). std::put_time() shows the same behavior as it uses
_wcsftime_l() internally. The default invalid parameter handler may terminate
the process, which can be a problem given that the format string can be
specified by the user from the Icinga DSL.

Thus, temporarily set a thread-local no-op handler to disable the default one
allowing the program to continue. This then simply results in the function
returning an error which then results in an exception as we ask the stream to
throw one.

See also:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170
https://learn.microsoft.com/en-us/cpp/c-runtime-library/parameter-validation?view=msvc-170
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/set-invalid-parameter-handler-set-thread-local-invalid-parameter-handler?view=msvc-170
2024-09-23 10:47:20 +02:00
Julian Brost
e65827cd58 Utility::FormatDateTime(): handle errors from strftime()
So far, the return value of strftime() was simply ignored and the output buffer
passed to the icinga::String constructor. However, there are error conditions
where strftime() returns 0 to signal an error, like if the buffer was too small
for the output. In that case, there's no guarantee on the buffer contents and
reading it can result in undefined behavior. Unfortunately, returning 0 can
also indicate success and strftime() doesn't set errno, so there's no reliable
way to distinguish both situations. Thus, the implementation now returns the
empty string in both cases.

I attempted to use std::put_time() at first as that allows for better error
handling, however, there were problems with the implementation on Windows (see
inline comment), so I put that plan on hold at left strftime() there for the
time being.
2024-09-23 10:47:20 +02:00
Julian Brost
9d6b3f3305 Utility::FormatDateTime(): use localtime_s() on Windows
localtime() is not thread-safe as it returns a pointer to a shared tm struct.
Everywhere except on Windows, localtime_r() is used already which avoids the
problem by using a struct allocated by the caller for the output.

Windows actually has a similar function called localtime_s() which has the same
properties, just with a different name and order of arguments.
2024-09-23 10:47:19 +02:00
Julian Brost
5339c72403 Utility::FormatDateTime(): use boost::numeric_cast<>()
The previous implementation actually had undefined behavior when called with a
double that can't be represented as time_t. With boost::numeric_cast, there's a
convenient cast available that avoids this and throws an exceptions on
overflow.

It's undefined behavior ([0], where the implicit conversion rule comes into
play because the C-style cast uses static_cast [1] which in turn uses the
imlicit conversion as per rule 5 of [2]):

> A prvalue of floating-point type can be converted to a prvalue of any integer
> type. The fractional part is truncated, that is, the fractional part is
> discarded.
>
> * If the truncated value cannot fit into the destination type, the behavior
>   is undefined (even when the destination type is unsigned, modulo arithmetic
>   does not apply).

Note that on Linux amd64, the undefined behavior typically manifests itself in
the result being the minimal value of time_t which then results in localtime_r
failing with EOVERFLOW.

[0]: https://en.cppreference.com/w/cpp/language/implicit_conversion#Floating.E2.80.93integral_conversions
[1]: https://en.cppreference.com/w/cpp/language/explicit_cast
[2]: https://en.cppreference.com/w/cpp/language/static_cast
2024-09-23 10:47:19 +02:00
Julian Brost
89f4f4f8d4 Add tests for Utility::FormatDateTime() 2024-09-23 10:45:43 +02:00
Yonas Habteab
377fd59216
Merge pull request #10126 from Icinga/broken-runtime-config-sync-2.13
Fix broken runtime config sync
2024-09-20 12:38:01 +02:00
Yonas Habteab
f66f99516b Checkable: Don't recalculate next_check while processing remotely genrated check
Currently, when processing a `CheckResult`, it will first trigger an
`OnNextCheckChanged` event, which is sent to all connected endpoints.
Then, when `Checkable::ProcessCheckResult()` returns, an `OnCheckResult`
event is fired, which is of course also sent to all connected endpoints.

Next, the other endpoints receive the `event::SetNextCheck` cluster
event followed by `event::CheckResult`and invoke
`checkable#SetNextCheck()` and `Checkable#CheckResult()` with the newly
received check. So they also try to recalculate the next check
themselves and invalidate the previously received next check timestamp
from the source endpoint. Since each endpoint randomly initialises its
own scheduling offset, the recalculated next check will always differ by
a split second/millisecond on each of them. As a consequence, two Icinga
DB HA instances will generate two different checksums for the same state
and causes the state histories to be fully resynchronised after a
takeover/Icinga 2 reload.
2024-09-20 12:24:39 +02:00
Yonas Habteab
0f5aafedad
Merge pull request #10164 from Icinga/do-not-sync-partially-initialised-objects-2.13
IcingaDB: Don't sync partially initialised objects
2024-09-20 11:48:07 +02:00
Yonas Habteab
80e8c166ed Don't allow to modify/create/delete an object concurrently 2024-09-20 11:08:08 +02:00
Yonas Habteab
1b35fe1393 ConfigObjectUtility#CreateObject(): Use Defer for config path cleanup 2024-09-20 11:06:26 +02:00
Yonas Habteab
9e6f6d2213 ApiListener: Process cluster config updates sequentially 2024-09-20 11:05:47 +02:00
Yonas Habteab
e3a7ee079a Introduce RAII style ObjectNameLock class 2024-09-20 11:05:47 +02:00
Yonas Habteab
752f7c4ab6 ConfigObjectUtility: Use AtomicFile to store object config files 2024-09-20 10:30:41 +02:00
Yonas Habteab
1f06ec042a IcingaDB: Don't sync partially initialised objects 2024-09-19 13:33:08 +02:00
Yonas Habteab
adc350da08
Merge pull request #10134 from Icinga/2.13Boost1.86
Bump Boost shipped for Windows to v1.86
2024-09-19 12:00:42 +02:00
Yonas Habteab
20a73f6d13
Merge pull request #10127 from Icinga/AddDowntime-trigger_name-2.13
Downtime::AddDowntime(): NULL-check pointer before deref not to crash
2024-09-18 10:50:16 +02:00
Yonas Habteab
3d1a2b4e44
Merge pull request #10128 from Icinga/broken-timeperiod-2.13
Fix broken `TimePeriod/ScheduledDowntime`s
2024-09-18 10:36:41 +02:00
Yonas Habteab
1938268609
Merge pull request #10133 from Icinga/timeperiod-nth-day-of-month-off-by-one-2.13
Timeperiods: fix off by one when calculating n-th last weekday of the month
2024-09-18 10:28:07 +02:00
Alexander A. Klimov
7761d6f78b l_LegacyDowntimesCache: delete removed objects not to leak memory 2024-09-17 16:44:57 +02:00
Alexander A. Klimov
d09d051fad /v1/actions/schedule-downtime: reject request on invalid trigger_name
For this purpose lookup the specified Downtime. Also pass Downtime objects,
not just names, to Downtime::AddDowntime() not to lookup it twice.
2024-09-17 16:44:57 +02:00
Alexander A. Klimov
0bba441a86 [Refactor] Downtime::GetDowntimeIDFromLegacyID(): return the Downtime itself
not just its name.
2024-09-17 16:44:57 +02:00
Alexander A. Klimov
5a155346e7 [Refactor] l_LegacyDowntimesCache: store Downtime objects, not just their names
to avoid names of vanished objects.
2024-09-17 16:44:57 +02:00
Yonas Habteab
fb46d312e5 Add advanced timeperiod range,include/exclude test cases 2024-09-17 16:44:32 +02:00
Yonas Habteab
be775b4baf tests: Add some basic tests cases for LegacyTimePeriod::IsInTimeRange() 2024-09-17 16:44:32 +02:00
Yonas Habteab
e611dc65ea Check segemnt start date inclusively in TimePeriod::IsInside() 2024-09-17 16:44:32 +02:00
Yonas Habteab
3de7ec062b Fix broken timeperiods/scheduleddowntimes 2024-09-17 16:44:32 +02:00
Julian Brost
6986417533 Timeperiods: fix off by one when calculating n-th last weekday of the month
A day specification like "monday -1" refers to the last Monday of the month.
However, there was an off by one if the first day of the next month is the same
day of the week, i.e. a Monday in this example.

LegacyTimePeriod::FindNthWeekday() picks a day to start the search for the day
in question. When given a negative n to search for the n-th last day, it
wrongly used the first day of the following month as the start and counted it
as if it was within the current month. This resulted in a 1/7 chance that the
result was one week too late.

This is fixed by using the last day of the current month instead.
2024-09-17 16:44:09 +02:00