search

Icinga / icinga-core

Icinga 1.x, the old core (EOL 31.12.2018)
GNU General Public License v2.0
45 stars 27 forks source link

[dev.icinga.com #8430] Classic UI fails to display Host Commands panel #1541

Closed icinga-migration closed 9 years ago

icinga-migration commented 9 years ago

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

Created by barry.quiel on 2015-02-12 17:29:01 +00:00

Assignee: (none) Status: Rejected (closed on 2015-03-12 18:59:59 +00:00) Target Version: (none) Last Update: 2015-03-12 18:59:59 +00:00 (in Redmine)

Icinga Version: Core 2.2.4 UI 1.12.1
OS Version: CentOS release 6.5 (Final)

When looking at hosts details from a list returned from the search box, the host commands panel is occasionally not displayed. It is displayed for some hosts but not for others

Attachments

icinga-migration commented 9 years ago

Updated by mfriedrich on 2015-02-14 16:06:23 +00:00

The commands panel is only shown for users authorized for these actions. Grep for that inside the cgi.cfg config file and ensure that this is the same user which is logged in (and post the details).

icinga-migration commented 9 years ago

Updated by barry.quiel on 2015-02-17 17:52:03 +00:00

So under normal situations access to the service/host commands would be covered by two aspects. Applied notifications would include the group that I am a member which would give me access to service/host commands. The other that would cover me would be authorized_contactgroup_for_all_host_commands/authorized_contactgroup_for_all_service_commands in cgi.cfg. Unfortunately I didn't write down the names of all the devices that were showing this issue so I don't have a lot of data to compare the different objects. I did hunt and peck through and found a device. Looking at the device my access should be covered by both settings. This host object has a notification assigned to it. The object cache shows that I am a contact for the host object. The object also shows the expected group that enables the authorized_contactgroup_for_all_host_commands setting.

icinga-migration commented 9 years ago

Updated by mfriedrich on 2015-03-12 18:59:59 +00:00

It's more of a compat issue with icinga2 collecting contacts from all notifications and puts them onto the hosts/services which are then evaluated by the Classic UI for authorization types. That is something which cannot be fixed, neither in Classic UI nor Icinga 2. Please consider using Icinga Web 1.x or 2.x allowing you to define more fine granular permissions and roles, not based on contacts.

I'll close this one as wontfix.