Feature Request: ability to override ARGs on templates

[ericloyd]

This behavior is identified on Nagios XI 5.3.3 and 5.3.4 but we have not yet tested on 5.4.0:

We have a service (DNS check) that includes an XI Wizard template (xiwizard_website_dns_service). The service has the check command blank and arg1 blank.

The issue is that if we add something to arg1 in the service, but still leave check command blank, then the argument is not actually added to the service check. This can be confirmed by a diff of the before and after versions of objects.cache.

If we add the check_xi_service_dns command to check_command on the service (this is the check command from the template) then both the blue "run check command" appears and the argument gets processed correctly.

We believe you should be able to specify/override arguments at the service level without having to specify the check command if it's being placed in the template.

[BanditBBS]

The second part of this is the Core issue and I agree, it makes perfect sense for it to work as Eric wishes. Locally defined always trumps template stuff, except for arguments when the check command is defined in template instead of service definition.

[ericloyd]

Sorry. Should have left the XI stuff out. Edited and removed.

[hedenface]

I'll get around to reproducing this, as if that's what is happening (I believe you I just want to see it) then you're absolutely right.

[ericloyd]

"as if" you do, I look forward to a new haiku! :-)

[hedenface]

Verified. Let me walk you through how:

commands.cfg:

# test_cmd
define command{
        command_name    test_cmd
        command_line    /bin/echo "1: $ARG1$" >> /tmp/file && /bin/echo "2: $ARG2$" >> /tmp/file && echo date >> /tmp/file && echo "-" >> /tmp/file && /bin/echo output
        }

templates.cfg:

define service{
    name             test-cmd-service
    use              local-service
    register         0
    check_command    test_cmd
}

localhost.cfg:

define service{
    use                   test-cmd-service
    host_name             localhost
    service_description   Test CMD
    check_command         !arg1!arg2!
}

By golly, I think you're right.

[ericloyd]

Any chance of getting this implemented as a change in Core?

[hedenface]

Yes, actually. Still getting accustomed to the deep and dark corridors of code in Core. I found where the change needed to made, and got some quick hack working on my end. This should be in 4.4. I don't have a time frame for that, but it's close to the top of priorities. Right along with Plugins 2.3.

[ericloyd]

I haven't looked through change logs; I like my information to come from github. :-) Any word on this?

[sawolf]

I just learned about this now, so thanks for the ping.

As far as addressing your use-case/letting your customer do what they want, you should be able to use free variables in the check_command on the template, then set those free variables for each service. I didn't see that mentioned in the thread above so I just wanted to put that out, though I agree that it's not ideal.

I also don't think I have access to the code that @hedenface referred to. I'd like to say that we can put this in 4.5.0, but without knowing why it didn't get into 4.4 I can't promise that.

[ericloyd]

Free variables is not the solution to templates that behave badly. The problem presented in the forums is not the same problem listed in this ticket. Related, but not the same. The solution, here, is to allow the parameters (check_command or ARGX variables) defined at the service to override what's in the template, but if there's nothing in the service, then inherit what's in the template.

In other words. If template check_command is check_dummy and ARG1 is set to 0, then on a service which inherits that template and check_command is left blank but ARG1 is set to 2, then the check_command should be inherited as check_dummy and ARG1 should be set to 2 as specified.

[everwatch]

To every thing there is a season, and a time to every purpose under the heaven. I guess just not Nagios Core feature requests.

Any idea if this is going to be done sometime before Y2K38?