With Fedora 41, DNF was upgraded to version 5, breaking the command line
API of "dnf config-manager"[^0]. Unfortunately, DNF 5's addrepo does not
work with a simple URL anymore, but requires to construct a .repo file.
Furthermore, no information about trusting the Icinga signing key was
available, resulting in one being unable to install packages. This was
already the case for Fedora 40, still using DNF 4.
Since we are building Icinga DB for Fedora, I have included Icinga DB
documentation for Fedora. Otherwise, this section was empty.
Finally, the icingadb-redis-selinux package was mentioned for
distributions were we started to build SELinux packages for[^1].
[^0]: https://docs.fedoraproject.org/en-US/quick-docs/adding-or-removing-software-repositories-in-fedora/#_adding_repositories
[^1]: https://github.com/Icinga/icingadb/issues/580
CMake 3.15 introduced the `MSVC_RUNTIME_LIBRARY` property as a way to specify
which MSVC runtime library is used and how it is linked. Also with that
release, policy CMP0091 was introduced where the new behavior no longer adds
the corresponding compile flags to the `CMAKE_<LANG>_FLAGS_<CONFIG>` variables.
The new policy was enabled by 7f164bda96341272be385fa1359a26f97eb9d2b4,
resulting in the MSI no longer working on previous Windows Server versions
(2019 for example) as the CMake configuration replaced those compile flags
(lines 3-9 in the same file) which no longer works when they are no longer part
of the string. This commit fixes this regression by setting the
`MSVC_RUNTIME_LIBRARY` property on the icinga-installer target.
I've also added a comment stating my understanding of why this is necessary.
Unfortunately, I couldn't find an explanation of why replacing the /MD with the
/MT flag was done originally in the project history, so it's a bit of
guesswork.
https://cmake.org/cmake/help/latest/policy/CMP0091.htmlhttps://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html
The wait group gets passed to HttpServerConnection, then down to the
HttpHandlers. For those handlers that modify the program state, the
wait group is locked so ApiListener will wait on Stop() for the
request to complete. If the request iterates over config objects,
a further check on the state of the wait group is added to abort early
and not delay program shutdown. In that case, 503 responses will be
sent to the client.
Additionally, in HttpServerConnection, no further requests than the
one already started will be allowed once the wait group is joining.
CalcEventID's internal logic uses the TimestampToMilliseconds function
to convert the given eventTime to milliseconds. Within this function,
the timestamp is capped to prevent an overflow.
On three occasions, the input timestamp given to CalcEventID had already
been converted using TimestampToMilliseconds. The second
TimestampToMilliseconds function then checked the value and always
returned the capped maximum value. Consequently, CalcEventID returned
the same hash value for different timestamps.
This affected SendFlappingChange, SendAcknowledgementSet, and
SendAcknowledgementCleared. For example, when two acknowledgments were
created for the same service, the calculated event_id representing the
history table row would be identical.
Fixes#10465
Since the types and states attributes are user configurable and allowed to change at
runtime, we need to update the actual filter bitsets whenever these attributes change.
Otherwise, the filter bitsets would be stale and not reflect their current state.
Since recently, rockylinux:9 failed with linker errors against bz2, lzma
and zstd. Installing the relevant devel packages fixed the builds.
For reasons, cmake has started to add the -lbz2, -llzma, and -lzstd
linker flags. Since Icinga 2 usually does not need those, the relevant
devel packages were not installed. This may be due to some other
transitively linked dependency.
> 2025-06-05T13:12:59.5866282Z : && /usr/lib64/ccache/c++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wsuggest-override -Wrange-loop-construct -g -pthread -Winvalid-pch -O2 -g -DNDEBUG -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--export-dynamic -rdynamic third-party/mmatch/CMakeFiles/mmatch.dir/mmatch.c.o third-party/socketpair/CMakeFiles/socketpair.dir/socketpair.c.o lib/base/CMakeFiles/base.dir/application-version.cpp.o lib/base/CMakeFiles/base.dir/journaldlogger.cpp.o lib/base/CMakeFiles/base.dir/base_unity.cpp.o third-party/execvpe/CMakeFiles/execvpe.dir/execvpe.c.o lib/config/CMakeFiles/config.dir/config_lexer.cc.o lib/config/CMakeFiles/config.dir/config_parser.cc.o lib/config/CMakeFiles/config.dir/config_unity.cpp.o lib/remote/CMakeFiles/remote.dir/remote_unity.cpp.o plugins/CMakeFiles/check_nscp_api.dir/check_nscp_api.cpp.o -o Bin/RelWithDebInfo/check_nscp_api -Wl,-rpath,:::::::::::::::::::::::: -ldl /usr/lib64/libboost_coroutine.so.1.75.0 /usr/lib64/libboost_context.so.1.75.0 /usr/lib64/libboost_date_time.so.1.75.0 /usr/lib64/libboost_filesystem.so.1.75.0 /usr/lib64/libboost_iostreams.so.1.75.0 /usr/lib64/libboost_thread.so.1.75.0 /usr/lib64/libboost_system.so.1.75.0 /usr/lib64/libboost_program_options.so.1.75.0 /usr/lib64/libboost_regex.so.1.75.0 /usr/lib64/libssl.so /usr/lib64/libcrypto.so -lsystemd /lib64/libedit.so -ltermcap /usr/lib64/libboost_chrono.so.1.75.0 -lbz2 -llzma -lz -lzstd -licudata -licui18n -licuuc && :
> 2025-06-05T13:12:59.5872347Z /usr/bin/ld: cannot find -lbz2
> 2025-06-05T13:12:59.5872577Z /usr/bin/ld: cannot find -llzma
> 2025-06-05T13:12:59.5872802Z /usr/bin/ld: cannot find -lzstd
> 2025-06-05T13:12:59.5873039Z collect2: error: ld returned 1 exit status
Hopefully, this issue may resolve itself in the near future, but for the
time being this satisfies our CI run on Rocky Linux 9.
No external user needs to manipulate the actual object dependency
graphs. This was maybe introduced for debugging purposes at that time
but if someone messes with this in prod - good luck with that. Oh, apart
from that it's broken :( and doesn't track parents as its implies but
children.
Not sure why it's introduced in the first place, maybe for debugging
purposes at the early stage of Icinga 2 dev but I failed to see an
actual useful use case for it that's worth its maintenance burden. So,
this commit dropped it entirely from the DSL language.
