Network:
Nagios Bug and Feature Tracker
Bug and Feature Tracker
Main | My View | View Issues | Change Log | Roadmap
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000174 [Nagios Core] Configuration Parsing feature N/A 2010-11-09 20:23 2012-11-12 06:04
Reporter bostjan View Status public  
Assigned To
Priority normal Resolution reopened  
Status feedback   Product Version
Summary 0000174: Default argument/macro values for nagios check commands
Description I would like my nagios configuration to be as transparent as possible, which also means it should be as small as possible (no duplicated definitions). This works fine if you have homogenic host family. Once you start hitting diversity things are not that simple anymore. Anyway...

Currently I have to have two similar command definitions to achieve the effect desired, one is fixed with default check command argument values. The other has variable arguments, like this:

###### Start of current config ###############################################
### First command
define command{
  command_name check-metric_sys-intr
  command_line $USER3$/check_ganglia $HOSTNAME$ sys_intr less 2000 5000
}
### Second command for hosts that do not fall into the average
define command{
  command_name check-metric_sys-intr_custom
  command_line $USER3$/check_ganglia $HOSTNAME$ sys_intr less $ARG1$ $ARG2$
}


##### Then there are service definitions
### For average host
define service{
  use service_check-metric_sys-intr # Defined as template with "register 0"
  host_name host-average.example.net
}
### For not-so-average host
define service{
  use service_check-metric_sys-intr
  host_name host-exception.example.net
  check_command check-metric_sys-intr_custom!5000!10000
}
###### End of current config #################################################



Now it would be splendid if those arguments ARG1 and ARG2 had some way of defining default values, and the final config should look something like this (note the equal sign operator for default check command argument values and only one command definition):

###### Start of desired config ###############################################
define command{
  command_name check-metric_sys-intr
  command_line $USER3$/check_ganglia $HOSTNAME$ sys_intr less $ARG1=2000$ $ARG2=5000$
}

##### Then there are service definitions
### For average host
define service{
        use service_check-metric_sys-intr
        host_name host-average.example.net
}
### For not-so-average host
define service{
        use service_check-metric_sys-intr
        host_name host-exception.example.net
        check_command check-metric_sys-intr!5000!10000
}
###### End of desired config #################################################
Additional Information
Tags No tags attached.
Nagios Version /
OS /
OS Version /
Attached Files

- Relationships

-  Notes
(0000446)
oernii (reporter)
2012-05-29 04:59
edited on: 2012-05-29 04:59

 I'd love this too. Multiple checkcommands are driving me crazy.
(0000447)
oernii (reporter)
2012-05-29 05:27

 I have found a workaround. use custom variables like this:

# define defaults in generic service
define service{
        name generic-service
        use graphed-service
        ...
        __CHECK_HTTP_ENHANCED_PORT 80
        __CHECK_HTTP_ENHANCED_SSL off
        __CHECK_HTTP_ENHANCED_AGENT "check_http_enhanced"
        __CHECK_HTTP_ENHANCED_URL "/"
        __CHECK_HTTP_ENHANCED_HOST $HOSTADDRESS$
        }


# use defaults in ONE service check
define command{
        command_name check_http_enhanced
        command_line /etc/nagios/scripts/check_http_enhanced.pl -H $HOSTADDRESS$ \
                  -n $_SERVICE_CHECK_HTTP_ENHANCED_HOST$ -u $_SERVICE_CHECK_HTTP_ENHANCED_URL$ \
                  -p $_SERVICE_CHECK_HTTP_ENHANCED_PORT$ -s $_SERVICE_CHECK_HTTP_ENHANCED_SSL$ \
                  -A $_SERVICE_CHECK_HTTP_ENHANCED_AGENT$
        }

# override defaults in service
define service{
        __CHECK_HTTP_ENHANCED_URL "/devel/"
        __CHECK_HTTP_ENHANCED_HOST "www.customsite.com"
        use generic-service
        host_name serverXZ
        service_description description
        check_command check_http_enhanced
        }
(0000587)
ageric (administrator)
2012-09-17 23:47

 While it's an interesting idea, it brings with it all the problems everything that handles default arguments does, like "what if you want the first argument to have its default value and set it for the second?" and "how do I do if argument 3 and 5 should have defaults, but 1, 2 and 4 are required?"

So no, this won't get implemented.
(0000612)
ageric (administrator)
2012-09-18 07:55

 Feedback from Christoph Anton Mitterer regarding this:
-----------------------------------------------
Unfortunately one cannot update a bug in **** Mantis, once it was
closed.



I don't see a particular reasons that should cause any problem, because
as far as I can see we already _have_ kind of a default for ARGn macros.

Perhaps, however, what I have in mind is much simpler than what the
original author intended.


Consider the following:
Right now, when I have e.g.:
  command_name bar
  command_line /foo/bar $ARG1$ $ARG2$
and I use:
  check_command bar!4
or even just:
  check_command bar
I'll get:
"/foo/bar 4 "
respectively:
"/foo/bar "
(notice the spaces).

So $ARGn$ missing ARGn are already substituted with "" as are empty
ARGn, e.g.
  check_command bar!!

Right?

Now my idea for default arguments would simply be: take the defined
default value, if
- either the ARGn is missing at all
- the ARGn is empty


In that case one should have any of the problems you describe above,
e.g.:
"how do I do if argument 3 and 5 should have defaults, but 1, 2 and 4
are required":
  command_name bar
  command_line /foo/bar $ARG1$ $ARG2$ $ARG3:="SOMEdefault"$ $ARG4$ $ARG5:="someDefault"$
with:
  check_command bar!required!required!!reuired!
OR
  check_command bar!required!required!!reuired ;(no trailing "!")


Of course one sees that if such for which you want defaults are "in the
middle" of the arguments list,... you still need to set an empty "!!".

Also, it is not longer possible to "intentionally" set and ARGn to the
empty string "", IF a default is set for it.

While these sound like disadvantages, I think it's no problem in
reality, because one just requires that admin who defines the commands,
to do reasonable things.


When I found that bug at Nagios, I cloned it over at Icinga:
https://dev.icinga.org/issues/2508 [^]
and Michael already did some work, IIRC.
Perhaps you want to have a look


In case you reopen the ticket now, feel free to add my ideas in that
email to it
----------------------------------------------------------------
(0000613)
ageric (administrator)
2012-09-18 08:01

 ok, I agree that it's not that hard provided you have either all variables or 3 out of 4 and the 4th has a default argument.

However, this:
------------
"how do I do if argument 3 and 5 should have defaults, but 1, 2 and 4
are required":
  command_name bar
  command_line /foo/bar $ARG1$ $ARG2$ $ARG3:="SOMEdefault"$ $ARG4$ $ARG5:="someDefault"$
with:
  check_command bar!required!required!!reuired!
OR
  check_command bar!required!required!!reuired ;(no trailing "!")
-----------

... just doesn't fly. If you want defaults vars you live with the fact that the nul string exists and your ARG3 does NOT get a default value. Provided we do "all or nothing" substitution of ARG macros (where "all" is actually "all exclamation marks point into an ARG value"), this could be done in a somewhat sensible manner, and people who want ARG1 to have a default while ARG2, ARG3 and ARG4 are required can just go hang themselves.
(0000626)
calestyo (reporter)
2012-09-23 12:18

 Ok let me see whether I understand you...

> ok, I agree that it's not that hard provided
> you have either all variables or 3 out of 4 and
> the 4th has a default argument.
Don't understand... or well perhaps my "implementation" would be just much more stupid.
In my idea, it's not like default parameters in C/C++...
You need the "!!" if you want to use the default value of a middle-parameter
e.g.
check_command load!foo!bar!!baz
Now ARG3 would use the default value... AND... if there _were_ any ARG5, 6, 7... they would use them, too.


> If you want defaults vars you live with
> the fact that the nul string exists and
> your ARG3 does NOT get a default value.
Don't quite understand, why it couldn't work like this...:
pseudo-code:
if (n < numberOfUsedArgs)
   if ((Arg[n].value == "") && Arg[n].hasDefault)
      Arg[n].value = Arg[n].default;
   else
      //nothing,... the string remains empty
else
   //nothing, this ARGn wasn't used at all in the command definition



Perhaps I just don't see your point ;-)
(0000641)
omnikron (reporter)
2012-11-12 06:04

 Hi,

This is very interesting and I'd love to see that in Nagios. However, why not simply inplement standard shell expansion. If you look at the Bash manual :

${parameter:-word}
If parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted.

So for instance, "$_SERVICEVIA:-$HOSTADDRESS$$" would :
- expand to macros $_SERVICEVIA$ if set and non empty
- expand to $HOSTADDRESS$ otherwise

You see also that kind of syntax in syslog-ng. Implementing the + expansion would be great as weel. Again from the Bash manual :

${parameter:+word}
If parameter is null or unset, nothing is substituted, otherwise the expansion of word is substituted.

- Issue History
Date Modified Username Field Change
2010-11-09 20:23 bostjan New Issue
2010-11-09 20:23 bostjan Nagios Version => /
2010-11-09 20:23 bostjan OS => /
2010-11-09 20:23 bostjan OS Version => /
2012-04-08 20:10 calestyo Issue Monitored: calestyo
2012-05-29 04:59 oernii Note Added: 0000446
2012-05-29 04:59 oernii Note Edited: 0000446
2012-05-29 04:59 oernii Issue Monitored: oernii
2012-05-29 05:27 oernii Note Added: 0000447
2012-09-17 23:45 ageric Status new => assigned
2012-09-17 23:45 ageric Assigned To => ageric
2012-09-17 23:47 ageric Note Added: 0000587
2012-09-17 23:47 ageric Status assigned => closed
2012-09-17 23:47 ageric Resolution open => won't fix
2012-09-18 07:55 ageric Assigned To ageric =>
2012-09-18 07:55 ageric Note Added: 0000612
2012-09-18 07:55 ageric Status closed => feedback
2012-09-18 07:55 ageric Resolution won't fix => reopened
2012-09-18 08:01 ageric Note Added: 0000613
2012-09-23 12:18 calestyo Note Added: 0000626
2012-11-12 05:58 omnikron Issue Monitored: omnikron
2012-11-12 06:04 omnikron Note Added: 0000641

Mantis 1.1.7[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker