Macro with dot in the name not found

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 found this page and it looked really promising:

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:

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:

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.


Thanks for the fast reply!

The reason for doing this in the first place was that I found this page:

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:

So that’s the main reason for doing it.
When I have set the data fields to:

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.*

So you want to hide all command parameters in the web interface or even all custom variables?

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. :slight_smile:

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.

Reading the docs makes me think that this should still work. Maybe @nilmerg can share more expertise on that :slight_smile:

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.

That’s a whitelist. Though, blacklists are the only supported thing atm.

Role adjustments are only applied once users log-out and back -in. This way it should work, just tested it myself.


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 :slight_smile:

So this works:

This, as I had in the role when tested it last time yesterday, doesn’t work:

Thank you for your excellent help!

1 Like