Make OS facts available in the icinga check

[dnsmichi]

Story

We have a powerful version detection for Linux, Unix and Windows (the latter needs a patch with #7743) but we do not expose them anywhere else than with icinga2 --version. With running satellites and agents, we could expose these small facts e.g. with the icinga check in the first iteration.

Following iterations may include inventory tasks, or thresholds.

Desired Solution

• Use the utility helpers and cache them on startup in icinga2 daemon.

        os << "System information:\n"
                << "  Platform: " << Utility::GetPlatformName() << "\n"
                << "  Platform version: " << Utility::GetPlatformVersion() << "\n"
                << "  Kernel: " << Utility::GetPlatformKernel() << "\n"
                << "  Kernel version: " << Utility::GetPlatformKernelVersion() << "\n"
                << "  Architecture: " << Utility::GetPlatformArchitecture() << "\n";

• Access and print the cached details in the icinga check.

Questions

Discussion on Twitter: https://twitter.com/dnsmichi/status/1217052451725041664

• Fact providers, built-in and external
  • Re-use Puppet, Ansible, etc.
• Inventory a like ideas, collection and forwarding (tbd)
• Specifically Windows, the new framework and its capabilities

[dnsmichi]

The inventory ideas are tracked in the draft concept in #7814, out of scope for this issue.

[Al2Klimov]

I consider this is especially useful for, like, https://icinga.com/blog/2024/11/04/icinga2-security-pre-announcement/ where you want to monitor whether all nodes have been upgraded to vX.Y.Z. CC @yhabteab https://github.com/Icinga/icinga2/pull/7819#pullrequestreview-2420456253

[julianbrost]

@Al2Klimov You might want to have a look at the icinga_min_version input variable of the built-in icinga check command: https://icinga.com/docs/icinga-2/latest/doc/10-icinga-template-library/#icinga

[Al2Klimov]

There's no analogy for the OS version, though.

[slalomsk8er]

@julianbrost icinga_min_version doesn't work if a check against >= 2.14.3, 2.13.10, 2.12.11, and 2.11.12 is required after Tuesday 12th November 2024 between 13:00 and 15:00 UTC.

[oxzi]

@slalomsk8er: Could you please elaborate? I have just created a service check for the "icinga" check command in my test setup, setting vars.icinga_min_version = "2.14.3". As expected, the check went critical with the following message:

Icinga 2 has been running for 2 minutes and 28 seconds. Version: v2.14.0-334-ge894e45d6; Minimum version 2.14.3 is not installed.

If you want to check against all these patch versions, the "icinga" check command does not work. However, is having different Icinga 2 versions in a setup a realistic setup?

[Al2Klimov]

However, is having different Icinga 2 versions in a setup a realistic setup?

Oh, hi! You must be new here. 😊 /s

We even officially support that satellites may have one lower major version than masters and so on. In large setups, one does not simplyTM upgrade all stuff to Icinga vX. Just ask Eric for how old Icinga versions customers use according to recent tickets. 🙈

But yes, "having different Icinga 2 versions in a setup" isn't a perfect setup.

[slalomsk8er]

@oxzi sadly yes I hope that I can get rid of some old versions, now that new packages for EOL OSs get released. I still think Icinga GmbH could ask for money for new packages of current releases on EOL OSs ;)

[oxzi]

Even if derailing this issue, maybe check if all packages are updated then? But yes, having a more specific "icinga" check would be good, e.g., allowing checks against a minor version or a range of versions.

[Al2Klimov]

@lippserd!!1 Give this man a medal. (Srsly. Even if you want a new PHP. Just the agent may be enough for some old-OS boxes.)

Icinga GmbH could ask for money for new packages of current releases on EOL OSs

Won't work for https://icinga.com/blog/2024/11/04/icinga2-security-pre-announcement/, though. 😅