Arguments to check commands

[Andreas Ericsson]

On 02/27/2013 02:59 PM, Ton Voon wrote:
> Hi,
> 
> It seems like Nagios 4 has changed the way that check_command arguments are parsed. Overall, this looks like a good thing as I think it looks easier to understand as it seems to be much more similar to how the shell would evaluate a command. However, I'm worried about the migration of existing Nagios configurations.
> 
> For instance, this worked in Nagios 3:
> 
> ----
> define service {
>    ...
>    check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application \"filter=generated gt -2d AND severity NOT IN ('success', 'informational')\" MaxWarn=1 MaxCrit=10
>   }
> 

That looks slightly insane, tbh, and it's one of those commands that should
trigger a command anomaly (CMD_HAS_PAREN), which we shouldn't handle in the
runcmd library but instead paw off to the shell the same way we did in
Nagios 3.

> define command {
>          command_name    check_nrpe
>          command_line    /usr/local/nagios/libexec/check_nrpe $ARG1$
>          }
> ----
> 
> In Nagios 4, this fails. To get the same result, you need to configure it as:
> ----
> define service {
>    ...
>    check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application "filter=generated gt -2d AND severity NOT IN ('success', 'informational')" MaxWarn=1 MaxCrit=10
>   }

And that looks much more sane, as shell (and runcmd) can properly parse
both escaped and quoted parentheses without problem.

> ----
> 
> I can't quite understand the Nagios 3 rules versus the Nagios 4 rules
> or what the conversion process should be.

runcmd strives to be shell-compatible, but Nagios 4 should pass a
string to its worker that makes it parse that string so the result is
the same as what Nagios 3 would have gotten.

I just added a lot of tests to make it a whole lot easier to see
how the runcmd library parses arguments, so if you find anything that
doesn't work as per Nagios 3, you can add tests for it and I'll see
what can be done.

You may have to enable debug-logging to get to see processed_command
as it gets gets passed to runcmd though. If that's different from the
one passed for Nagios 3, we have a very fixable problem. If it's the
same, we're in standoff mode and shell.

A pretty simple workaround is to use single-quotes around arguments
you want to pass unmolested to the script or program you're running
though. shell and Nagios 3 has always handled those two alike.


> Is there anything that is going to be provided for Nagios 4 to ease
> migrating existing configurations?
> 

Most likely not. We haven't noticed anything like this with any of our
about 1000 running configurations, so it's unlikely to be so big a
problem that it warrants tool-assistance to fix.

What I could do is add a "wproc runcmd" thing for the query handler,
which would let one issue commands as processed, and perhaps with
some different macro settings so one can test various commands while
Nagios is running. That would make it trivial to see exactly what
Nagios gets back from a worker when a check has been run, which could
be nice as a debug tool. That's really the only way I can think of to
make Nagios' entire chain of command execution testable from command
line.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb