[dev.icinga.com #8315] Use Icinga 2 API to expand commands

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/8315

Created by bsheqa on 2015-01-29 15:29:40 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2016-12-07 12:35:51 +00:00 (in Redmine)

---

As the configuration of icinga2 is getting more and more complicated, it would be nice to see the resulting command of a service in the webinterface. This feature was available in icnga-classicui, but only works for icinga1.x

---

Relations:

• duplicates #6879
• duplicates #8315

[icinga-migration]

Updated by gbeutner on 2015-01-30 08:56:20 +00:00

FWIW Icinga 2 has all the information we'd need for this (that is, our internal CheckResult object has a copy of the exact command we executed). Last time we proposed exporting this in the IDO there were some concerns about security (i.e. because the commands might contain passwords...).

[icinga-migration]

Updated by tgelf on 2015-02-02 22:49:58 +00:00

One of the major differences between 1.x and 2.x is, that in 1.x given command params are exported in the icinga_host/servicestatus table. It's essential to be able to distinct between command structure and command params to be able to show them in a safe and secure way.

We are currently doing a bad job when it goes to resolve commands for 1.x and 2.x. We have everything we need for 1.x in the IDO (all but USERx, they are available only when parsing resource.cfg), but we miss one part from 2.x. Command parameters are available, but the command structure is afaik incomplete. Simple command definitions like [ "check_tcp", ..., "-p", "$tcp_port$" ] are available, extended argument definitions are not. Access to them would allow us to resolve the command and to decide which parameters (e.g. db password, community strings) to hide from non-privileged users.

While still strongly opting against an exported "resolved string" I guess this issue can be fixed once the "full" command definition will find it's way to the IDO. And as soon as we find some time to implement it, of course ;-)

Cheers,
Thomas

[icinga-migration]

Updated by mfriedrich on 2015-02-18 12:07:08 +00:00

Imho it's not reasonable to calculate the executed command from ingredients dumped into a backend. That works well with Classic UI since it uses the same shared code base as the core does. Furthermore Icinga 1.x is simple and stupid using a command line with only macros being replaced compared to Icinga 2.x with command arguments and functions. Still - both cores share the same problem with runtime value access, be it runtime macros or function calls.

I had the executed command line implemented in Icinga Core 1.x a while ago in #3810 but had to revert that patch due to security concerns.
Although these backends already provide quite a lot of security relevant information to be filtered from the user (like custom variables filtering passwords, even in the setup wizard as extra step).

Apart from that you wouldn't be able to support the entire set of an expanded command from the web interface. To be able to do that you would need to understand the configuration (sub)set of each core, have all the object and status information available. In the end you wouldn't be able to implement 100% of the available possibilities.

Since we have the command line with Icinga 1.x and 2.x it would be more reasonable to have access to the executed command in the available backends. Apart from that I could imagine an on-demand command simulator from an api call in the future, but that's to-be-discussed. Btw - if the upcoming config tool is that good, no-one will need a command expander imho.

[icinga-migration]

Updated by elippmann on 2015-03-31 14:20:23 +00:00

• Subject changed from Command Expander to Command expander
• Category set to Monitoring
• Target Version set to Backlog

[icinga-migration]

Updated by elippmann on 2015-03-31 14:21:32 +00:00

• Duplicates set to 6879

[icinga-migration]

Updated by purplecarrot on 2015-04-05 12:33:47 +00:00

I don't know all the ins and outs of how the Web UI works but I think It would be really useful if it could just show the last executed command.
As for how it should be done, maybe storing it in the database would be the easiest thing to do? It might not be the most beautiful solution but it would work for now, at least until the config tool is out.
Also, if showing the whole command is a security issue, let's just hide it from non-admin users, they don't need it anyway.

[icinga-migration]

Updated by elippmann on 2016-03-09 09:10:38 +00:00

• Priority changed from Normal to High

[icinga-migration]

Updated by elippmann on 2016-03-09 09:11:18 +00:00

• Duplicated set to 11324

[icinga-migration]

Updated by elippmann on 2016-09-05 06:10:39 +00:00

• Subject changed from Command expander to Use Icinga 2's API to expand commands
• Priority changed from High to Normal

[icinga-migration]

Updated by elippmann on 2016-09-05 06:12:36 +00:00

• Subject changed from Use Icinga 2's API to expand commands to Use Icinga 2 API to expand commands

[icinga-migration]

Updated by fred9176 on 2016-09-22 12:53:19 +00:00

+1
This is one of the feature we use most with Icinga 1 classic UI.
We started a test of migrating to Icinga2 and this should be really nice to add it.

[icinga-migration]

Updated by thebigfoot on 2016-09-22 13:57:43 +00:00

+1
We are also using the CommandExpander Feature pretty often.
It's super helpful to copy&paste the expanded command for debugging the broken service/host.

[icinga-migration]

Updated by invidian1 on 2016-12-07 12:35:51 +00:00

+1
I really miss that feature in Icinga2, it's the best way to debug problems with commands.

[dnsmichi]

This requires certain changes.

• Make the API resource available
• Extend the queries and views
• Add proper permissions (i.e. to forbid the default non-admin user to view such command line, could contain sensitive information)

In the meantime you can use the REST API curl requests and the icinga2 console to extract the executed command line. This is described inside the docs.

https://docs.icinga.com/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/troubleshooting#checks-executed-command​

[craig]

Is anyone willing to work on this? It'd be extremely helpful to be able to easily copy & paste commands as it was possible before.

[baurmatt]

I've build a simple bash script for this:

response=$(curl "https://icinga2-master.example.org:5665/v1/objects/services/${host_name}!${service_name}" \
     --insecure --silent \
     --user "${user}:${password}" \
     --header "Accept: application/json" \
     --request GET)

echo $response | jq -r '.results[0].attrs.last_check_result.command'

Perhaps this helps for the implementation.

[dnsmichi]

As mentioned before, this requires the REST API resource being available with #3035

[Thomas-Gelf]

In case you're using the Icinga Director, it hooks into the monitoring module and provides command expansion as follows:

This also works fine for objects not created by the Director. Using the Director is no requirement for this, but you need to enable it and to go once through the initial Connection setup/kickstart wizard. Inspected objects might contain sensitive information, so this feature is available only to users which have been granted the director/inspect permission.

Cheers,
Thomas

[lippserd]

This issue is kind of overrun by time. Icinga DB and the new monitoring module will provide this information. Further, there is the Director with its inspect functionality