We want to restrict access to custom variables for parts of our organization. Mainly to make it easier for our first line support people so they only see what they really need to handle escalations etc.
I want to hide all command arguments in the GUI for certain groups and the page above gave me an ide of how to do it.
So what I did (all is done in Director) was to first create a couple of new data fields called:
commands.nrpe_arguments
commands.nrpe_command
Then I created a command looking like this:
object CheckCommand “nrpe_checks” {
import “plugin-check-command”
command = [ PluginDir + “/check_nrpe” ]
arguments += {
“-H” = {
order = 1
required = true
value = “$host.address$”
}
“-a” = {
order = 3
repeat_key = false
required = false
value = “$commands.nrpe_arguments$”
}
“-c” = {
order = 2
required = true
value = “$commands.nrpe_command$”
}
}
}
Next step was to create a service template looking like this:
template Service “_disk_usage” {
check_command = “nrpe_checks”
vars[“commands.nrpe_arguments”] = [ “15%”, “7%”, “/”, “MB” ]
vars[“commands.nrpe_command”] = “disk_usage”
}
Finally a service is created and it looks like this:
object Service “Disk usage /var” {
host_name = “the_host”
check_command = “nrpe_checks”
max_check_attempts = “3”
check_period = “24x7”
check_interval = 30s
retry_interval = 15s
check_timeout = 5s
enable_notifications = true
enable_active_checks = true
enable_passive_checks = true
enable_event_handler = true
enable_flapping = false
vars[“commands.nrpe_arguments”] = [ “15%”, “7%”, “/”, “MB” ]
vars[“commands.nrpe_command”] = “vgt_disk”
vars.environment = “validation”
vars.org_group = “unix-team”
}
When the service is checked I get the following result:
Error: Non-optional macro ‘commands.nrpe_command’ used in argument ‘-c’ is missing.
If I change the data fields and replace the dot between commands and nrpe so they look like this instead:
commands_nrpe_arguments
commands_nrpe_command
Then everything is working just fine.
So my question here is; what am I doing wrong or is it so that it’s a limititation or bug in Director?
That’s invalid notation, you cannot mix square brackets with the indexer notation for setting dictionary keys.
Either write that with one side, or the other.
Since you’re generating this via the Director, let’s start with a different question: Why are you using this syntax: “$commands.nrpe_arguments$" in the first place?
The ITL already provides nrpe and as such, this command is available inside the Director as external command. You just need to enable the fields for this command, and then use then in your service templates and arrays.
If you still want to keep your own Command definitions, ensure to use underscores for long names. Dots are DSL syntax and are meant for dictionary access.
And that’s what I want to use it for. I want to hide some properties of the monitored objects for certain groups by using monitoring/blacklist/properties with the following value:
service.vars.commands.*
So that’s the main reason for doing it.
When I have set the data fields to:
command_nrpe_address
and is using service.vars.command_* in monitoring/blacklist/properties in a role it doesn’t work. The user will still see all service.vars.*
Yes… I want to hide all command parameters for certain groups, which I have tried to do via roles in Icingaweb2. I probably want to hide a few other custom variables but not all of them.
Mainly it’s about the command parameters and arguments.
I guess I should add as well that I do not want to add every single data field name to the role configuration since that would most likely be a way too long list.
Ah… well, to be more precise I should probably say that there are just a few variables/data fields I would like to show. So if it would have been possible in Icingaweb2 to specify something like “hide all except for those” that would be really great.
Sorry guys for wasting your time on this… @nilmerg is correct, the way I wrote in the rule (service.vars.command_) is working just fine. The way I had written in in my config wasn’t exactly as I wrote here in the thread, which I found out now
So this works:
service.vars.command*
This, as I had in the role when tested it last time yesterday, doesn’t work: command
