Possibility to selectively enable ITL checkcommands

[netson]

Is your feature request related to a problem? Please describe.

Yes; with a recent Icinga2 update the new ITL checkcommand check_systemd was added. Since I was already using a community version of a check with an identical name, this created conflict (duplicate definition). I initially addressed the problem via the icinga2 community forums: https://community.icinga.com/t/systemd-check-now-available-in-latest-icinga2-version/8022

Describe the solution you'd like

If it were possible to selectively enable or disable specific checkcommand from the ITL instead of an all or nothing approach, that would prevent such issues from happening again in the future.

Describe alternatives you've considered

My initial attempt was to simply delete the systemd.conf from the ITL directory which worked just fine, until the next icinga2 software update was pushed though the official PPA and the problem was instantly recreated. I ended up renaming my own checkcommand to avoid the issue.

An alternative solution would be to prevent the installer/package manager from constantly reinstalling the file; maybe it should attempt this only once upon the first availability of the new ITL checkcommand, and then never look back. That would allow you to simply delete those checkcommands that you don't wish to have and not have to worry about them suddenly reappearing with a future update. It would, however, not solve the issue of a new ITL checkcommand conflicting with an existing community version already in use.

Additional context

If any addtional context is needed, I'm more than happy to provide it! :-)

Keep up the good work! I love Icinga2; it keeps an eye on my entire infrastructure, so I don't have to! :-)

[leeclemens]

I think I've brought this up before with no resolution. I haven't been able to find a previous Issue; it may have been on the old website or email list.

[Al2Klimov]

Would it be a reasonable solution to just name your own commands like my::COMMANDNAME?

[netson]

Would it be a reasonable solution to just name your own commands like my::COMMANDNAME?

It is what I ended up doing, but since the entire icinga2 (and also nagios) plugin ecosystem uses the check_* naming convention this seems like a shortcut which will rear its ugly head at every new ITL component launch. To be safe from this issue in the future, I would need to rename every plugin not part of Icinga ITL, regardless of its source. It works, but seems rather user unfriendly. A more robust solution would be preferable I think.

[Al2Klimov]

every plugin not part of Icinga ITL, regardless of its source

Wait! Even non-standard plugins should be contributed to the ITL, so there's only one source (ex. PS plugins).

[Al2Klimov]

Colleagues, what about splitting our ITL – one file à command?

[julianbrost]

And then do what? Suggest only including individual checks instead of the whole ITL? Suggest deleting files from /usr?

[Al2Klimov]

Suggest only including individual checks

All by default, users may comment out individually.

[julianbrost]

But after touching this file once, users would then have to merge in any command added later themselves.

And what would you want to do in a cluster? Sync that file? If not, that would be one thing that you'd have to touch on upgrade on every node.

[Al2Klimov]

OK, as I already have your attention, let's flip the question: will anything ever happen here?

[julianbrost]

Well I think the current behavior is annoying and IMHO even incentivises not contributing command definitions: If you've written a command definition, you probably want to use it right away, so waiting for a release that includes it, is not an option. So you start to use it. Now you have two options: contribute it and have your config break once we include it, or just don't and hope nobody else will do so your config doesn't break.

On the issue itself: I think one option with little impact on existing configuration could be to allow shadowing ITL definitions and issue a warning along the lines of "hey, there exists a command with the same name in the ITL, maybe have a look if it's the same check plugin and start using it, or probably rename your command".