Modify check command for a single service

[alamp1360]

Hi!

Is it intentional that there is no way to edit the check command for a single service?

When i create a new single service for a host, i can define the check command. But when i safe the definition and re-open it, then the field "Check Command" is no longer displayed. So currently the only way to change the check command for a single service is to delete the service and add a new one.

On all other service types (sets, apply rules,..) the check command can be changed.

I am using director module 1.11.1

Greetings Andreas

[alamp1360]

I have "solved" the issue with the following patch for the file /usr/share/icingaweb2/modules/director/application/forms/IcingaServiceForm.php

*** IcingaServiceForm.php 2024-02-08 15:59:13.000000000 +0100 --- x 2024-07-15 09:31:10.161299439 +0200

---

* 497,502 ** --- 497,503 ---- $this->addHidden('object_type', 'object'); $this->addImportsElement(); $imports = $this->getSentOrObjectValue('imports');

• $forceCommandElements = $this->hasPermission(Permission::ADMIN);

    if ($this->hasBeenSent()) {
        $imports = $this->getElement('imports')->setValue($imports)->getValue();

  ---

  * 512,518 ** ->addDisabledElement() ->addGroupsElement() ->groupMainProperties() ! ->addCheckCommandElements() ->addExtraInfoElements() ->setButtons();

--- 513,519 ---- ->addDisabledElement() ->addGroupsElement() ->groupMainProperties() ! ->addCheckCommandElements($forceCommandElements) ->addExtraInfoElements() ->setButtons();

I simply copied that change from the "setupServiceElements" function, which is called for a "new" single service, whereas for an existing single service, the function "setupHostRelatedElements" is called. Since i have no idea why that "forceCommandElements" variable was introduced, would you please be so kind and check if this solution is "safe" and eventually integrate it into the source-code?

[Thomas-Gelf]

Security concerns are the main motivation here. Sets, Apply Rules and Templates are accessible to Admins only. You can grant access to single services in various ways in a multi-user environment. Allowing them to pick custom commands would (depending on the offered command list) easily lead to setups, where restricted users could run custom code on your Icinga nodes.

Therefore, setting and changing the Command in the related Template (or creating a new one) is the way to go. Might require an extra step in single cases, but also has the benefit of (usually) leading to cleaner configurations in the long run.

Cheers, Thomas

[alamp1360]

Thank you for explaining the inner logic of Director! So, following the current implementation, an admin is allowed to choose the command when creating a new single service, and, because of security concerms, a "normal user" is only allowed to select a template, which an admin has created previously, right? But why should an admin then not being allowed to modify the command for a single service? And as far as i can tell, my little patch allows exactly that....

Background to the whole thing is: I have to migrate a lot of very special checks to Icinga and, because in my mind service sets/apply rules for just a single server do not make too much sense, i wanted to implement them as single services, . But currently, every mistake i make during the implementation phase leads to a deletion/recreation of the single service. Creating a template for every single service would be an option, but, from my point of view, is just a duplication of config elements.

Greetings Andreas

[Thomas-Gelf]

An admin should not be allowed to choose "the command" when creating a single service. If you create a single service from a Hosts "Services" list (the usual approach), this works as expected. If you create a Host from the global services list AND you are an admin - then you get fields you shouldn't see: Command and Check Interval. This is a bug and slipped my attention. Seems that I rarely ever use "Add" single Services from the global Services list, doing so from the Host feels more "natural" (to me).

Using single services is fine, I often do so. But their common logic (command, intervals) should be in the related template.

[alamp1360]

So, unfortunately, by opening this issue, i have, as we say in Austria, woke up sleeping dogs :)

Of course you need keep the whole picture in your mind and i partly agree with the restrictions. But, apart from the command definition, which has to be in a template, all the other parameters like check frequency, number of checks, etc, can also not be defined or changed in the single service. So if i have a common check, for example something i do with NRPE, and i need to check it once per minute for one host, twice per day for another host and every 555 seconds for a third host, i need to create either three different templates or one template for the command and at least two templates for the check interval and then import a combination of "check command template" and "check frequency template" in the right order. I am not so sure that this is more transparent than just specify all those parameters in the single service...

Greetings Andreas

[Thomas-Gelf]

Check intervals are not accessible to the "common user" for similar reasons:

• they could easily be used for DoS-attacks
• they are hard to get right

Different NRPE commands IMHO belong to different service templates. The Monitoring Administrator takes care of working out his check logic: how often does something need to be polled? Does the interval fit into the related slots of my graphing solution, or would I loose data/precision?

The "common user" should then be able to happily assign what the admin prepared for him to his single hosts. Like "Let's add a Certificate Check", and not "let's add check_http" - being lost in a bazillion of parameters.

To give the user the possibility to choose between "Fast Checks", "Normal Checks" and "Slow Checks", the admin can create "Choices", and assign them to the related base templates. This makes such parameters accessible in a safe way.