Nagios Support Forum

--Apple-Mail-311-1052352028
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit


On 31 Jul 2009, at 16:10, Ethan Galstad wrote:

> Ton Voon wrote:
>> I've raised a bug report in Mantis re: double escaping: http://tracker.nagios.org/view.php?id=56
>>
>> I'm convinced this is bad behaviour, but want some confirmation
>> (Ethan? Andreas?) that this is correct action before I spend the time
>> in making changes, especially as it is likely to break existing
>> configurations too.
>>
> I believe this behavior was requested by users quite a while back.
> Changing it will likely break many configurations. Better to make
> sure
> the current behavior is well documented, than change it I think...

Can I propose that we have a new nagios.cfg option called
"use_backward_compatible_arg_escaping". This will default to 1 on
configurations that do not have this set. However, new installs will
have this configured in nagios.cfg to 0, so new systems can benefit
from more obvious arguments, while older systems from a straight
upgrade will work as is.

I think the change for the sample nagios.cfg will be:

# This option controls the argument escaping for host/service
check_command definitions. Only the exclamation mark (!) will
# require escaping - everything else is passed through "as-is" to the
check command definition. This simplifies situations where
# there are other escaped characters (such as \ or $). Macros are
passed "as-is" to the check command definition but will be expanded
# when expanding the check command
# If you are upgrading, you should set this to 1 to retain existing
behaviour
# The default option is 1 if this parameter is not set
use_backwards_compatible_arg_escaping=0

The documentation update for the main configuration variables will be:

If use_backwards_compatible_arg_escaping is set to 0, this will avoid
double escaping for arguments in a host/service check_command
definition. For example:

define command {
command_name check_nrpe
command_line $USER1$/check_nrpe $ARG1$
}

define service {
...
check_command check_nrpe!-H windows.opsera.com -c CheckFileSize -a
ShowAll 'File:PageFile=c:\\pagefile.sys'
}


With use_backward_compatible_arg_escaping=0, the command executed will
be: check_nrpe -H windows.opsera.com -c CheckFileSize -a ShowAll
'File:PageFile=c:\\pagefile.sys'

With use_backward_compatible_arg_escaping=1, the command executed will
be: check_nrpe -H windows.opsera.com -c CheckFileSize -a ShowAll
'File:PageFile=c:\pagefile.sys'



Thomas writes:
> A bit off-topic, but I believe it would be nice to have a way to
> execute
> commands directly rather than using the shell. I'm thinking of a
> different command option that could be used instead of
> "command_line"...
> i.e.:
>
> command_exec $USER1$/check_dummy!1!WARNING: $SERVICEDESC$ is stale.
>
> Basically, the first argument is the full path to the executable, and
> following ones are the argument array passed to execve. Bangs (!)
> would
> be argument separators (like in service definitions) with maybe the
> possibility of escaping them (otherwise a bang in a macro can do the
> trick).
>
> That would give much more flexibility when complex parameters must be
> passed.


That's a good idea. I was thinking something like:

command_arg $USER1$/check_dummy
command_arg 1
command_arg WARNING

But the exclamation mark is a nice way of doing it. In fact, the
escaping code would be the same as above, so we can reuse that. I'd
like to add this for all host and service check commands as a new
feature.


Andreas writes:
> Why use the exclamation mark at all? It's quite straightforward to
> parse
> shell-style quoting into arguments, and that way users can just cut-
> n-paste
> the commands to verify that they work (assuming they replace the
> macros,
> that is).


That's wrong. You use execve to avoid the shell quoting and to pass in
arguments "as-is" to the plugin without interpretation at the shell
level. For instance:

check_command $USER1$/check_by_ssh!-H!$HOSTADDRESS$!-C!echo $PATH

The documentation for command de

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]