There's a set of two tests for each perfdatawriter, just
to make sure they can connect and send data that looks reasonably
correct, and to make sure pausing actually works while the connection
is stuck.
Then there's a more in-depth suite of tests for PerfdataWriterConnection
itself, to verify that connection handling works well in all types
of scenarios.
Co-authored-by: Yonas Habteab <yonas.habteab@icinga.com>
This doesn't fix any concrete errors in master, but if tests ever get
reordered for some reason and the tlsutility tests run before the
http tests, they will leave broken certificates behind. This could
be solved by cleaning up manually in the tests, but that again could
cause issues if the tlsutility tests ever run in the middle of the
http ones.
The proper solution is using a CTest fixture to establish a dependency
where the tlsutility tests always run before the tests using a new
CTest fixture that provides the cleanup between these test groups.
On Windows, waiting on system timers is notoriously inaccurate, with
short sleeps taking tens of milliseconds longer than specified.
This led to these tests to sporadically fail on the Windows GHAs with
`check 5 == counter has failed [5 != 4]`, because it couldn't get the
expected five invokations within the given tolerance of 50ms.
Currently on master, the tests check if a timer triggers five times
in 550ms with a 100ms interval, only leaving those 50ms to spare.
This commit extends the tolerance of to 75ms. This is a pretty
conservative increase (when we could have gone to 99ms), but it
might be enough to satisfy the windows GHAs.
This commit refactors the ValueGenerator class to be a template that can
work with any container type. Previously, one has to manually take care
of the used container by lazily iterating over it within a lambda. Now,
the `ValueGenerator` class itself takes care of all the iteration,
making it easier to use and less error-prone. The new base `Generator`
class is required to allow the `JsonEncoder` to handle generators in a
type-erased manner.
The dummy command would sometimes fail with a "broken pipe" error
on slow runners like the arm64 container image one, so this commit
replaces them with executing a noop lambda. Using "/bin/echo" might
also have been fine, but with this there isn't even a process spawned
that can get a broken pipe.
Due to the changes in the previous commit, the test-cases for
notitificationcomponent now also pick up LogDebug level messages that
also fit the pattern. To get the test-cases working again a second
pattern is needed to exclude these.
If the logger is started with `Activate()` before `SetActive()`, it won't
log anything, as the logger updates the "min severity" value of loggers
only when starting them, and if they're not active at that point, they
will just be ignored, so the min severity remains at info.
This adds generalized IncomingHttpMessage and OutgoingHttpMessage templates
that support different types of streams (via a std::variant) and can both
be used for either requests or responses.
The tacked on metadata from the old HttpRequest and server connection from
the old HttpServerConnection have been moved to HttpApi(Request|Response)
classes that derive from the above generalized message types.
The race is between `NotificationTimerHandler`, which sends a reminder notification
after a certain inverval during problem states and `SendNotificationsHandler` which
sends out the notifications on state changes.
When the timer handler runs just before a state change triggers a notification, the
timer handler might pick up that state-change before the send notification handler
can set its no_more_notifications flag. In that case a "reminder" notification will
be sent out before the initial one, and despite `interval = 0` on the notification
object.
The certificate generated by `PkiUtility::NewCert()` is self-signed,
and so the subsequent `PkiUtility::SignCsr()` call is required.
However, `PkiUtility::SignCsr()` doesn't reuse existin cert, instead
it'll generate a fresh one on its own. So, skip the first one entirely!
This includes a few common scenarios and a reproduction of the current behavior
affected by the underlying bug of issue #10575. This is done both to document
the change in behavior, as well as to ensure the behavior of the other scenarios
stays the same before and after the fix is applied.
Due to this missing check, evaluating a DSL expression can result in a null
dereference, crashing the Icinga 2 process. Given that API users can also
provide DSL expression as filters, this can be triggered over the network as
well.
This issue was assigned CVE-2025-61908.
It's annoying to have to wait 10 seconds for the `liveness_disconnect`
test to complete, so make the timeout configurable and set it to a way
lower value to test the functionality.
This adds a global fixture that can parse an additional argument to
the test executables (`--generate_ctest_config`). When run by
CMake during build, this generates a CTest script containing all
the tests and their properties.
An additional decorator, that defines CTest properties for a test case
or suite that will be added to the tests during config generation.
This version needs no hacks, no huge CMake scripts, just a bit of
additional C++ code that iterates over all test-cases and collects
the information CTest needs.
One caveat is still that this does not work with cross-compilation,
which probably isn't an issue to begin with, but there are also ways
to fix that if necessary.
The Array, Dictionary, and Namespace types provide a Freeze() method that makes
them read-only. So far, there was the possibility to call some methods with
`overrideFrozen=true` which would then bypass the corresponding check and allow
modification of the data structures nonetheless.
With 24b57f0d3a, this possibility was already
removed from the Namespace type. However, for interface compatibility, it kept
the parameter and just ignores it, throwing an exception on any modification on
a frozen instance.
The only place using `overrideFrozen` was processing of the `-D`/`--define`
command line flag that allows setting additional variables in the DSL. At the
time it is evaluated, there are no user-created data structures yet that could
be frozen, so the only frozen objects that could be encountered are Namespaces
(Icinga doesn't freeze other types by itself) and for these, `overrideFrozen`
already has no effect.
Hence, there is no harm in removing `overrideFrozen` altogether. This
simplifies the code and also means that frozen objects are now indeed read-only
without exceptions, allowing further optimizations regarding locking in the
future.
