[Nagiosplug-devel] RFC: New threshold syntax

[Andreas Ericsson]

Ton Voon wrote:
> On 18 Mar 2008, at 15:01, Max wrote:
> 
>> On Tue, Mar 18, 2008 at 9:41 AM, Andreas Ericsson <ae at op5.se> wrote:
>>> Sensible. With '>' in arguments every argument needs to be escaped,
>>> which is just plain stupid.
>> Having operators match normal math vs. learning a different syntax
>> just to indicate normal operators with a trade off of having to quote
>> arguments is stupid?

Yes, because many people will forget the quotes lots and lots of
times. Syntaxes that so obviously will lead to irritation is stupid.

>  Interesting opinion, especially since command
>> definitions are codified in configuration files that don't change
>> much, in my (to you, stupid) mind making the warning and critical
>> conditional syntax more readable and maintainable for more complex
>> thresholds is more important than saving a plugin writer a few quote
>> key strokes here and there.  We all test and test plugins from the
>> command line before we


Well, the huge grey mass is infinitely more important than the singular
individual here, I think, and you can't possibly mean "we, the entire
community" when you say "we", so the argument is moot without a clearer
definition. I know from personal experience that people will almost
always omit quoting the first time a program is run if they're not
a) 100% alert
b) very used to Unix
c) the developer who wrote the app
d) previously bitten numerous times by the same issue

The problem with overloading a shell operator is that the plugin
author gets zero chance of giving decent feedback to the user what
he did wrong, because he can't see the entire commandline the user
gave, and someone not savvy enough with unix but still wishing to
run Nagios won't have any idea what so ever that <> are input/output
redirection commands for the shell to interpret.

So yes, the idea of using shell operators in command arguments is
clearly bogus.

As an example, can you tell me which one of these works, and why,
with a reasonable current version of, oh, let's say bash:

if ! test -d /etc; then echo "no such dir /etc"; fi
if test ! -d /etc; then echo "no such dir /etc"; fi

goodie. Now do the test again, but with zsh, and then with tcsh.

Then try it on Solaris, and then with korn shell. Now do the same
exercise with your syntax. For some (ancient) shells, <> will override
quoting (yes, retarded, isn't it?), but you will never know, and the
user will have no way out except from upgrading both his login
shell *and* his /bin/sh (as that's what popen(3) uses to run commands
with).

Now, hands up everyone who knew that popen(3) can use a different
shell than you do when you're logged in, and that that shell can parse
a command line totally different from your login shell. Then tell the
user to "be more careful when creating his command definitions" and
you'll just have made one HP openview sales rep very happy.

> codify them in command definitions, not like
>> most Nagios admins are doing tons of new checks a day for
>> configurations where missing a quote is a huge risk.
> 
> Decent argument.
> 
> Using "<" is more clear. Using "<=" will also sort out the inclusion/ 
> exclusion issue too.
> 

Except that '<' is *also* bogus, and will break horribly for any program
running a script that can accept input on stdin.

> Your example uses the -w and -c flags, rather than using the metric.  
> How would we say "show me time, but I don't want thresholds set  
> against it"?
> 
> Maybe this in combination with the ordered command line options?
> 
> --threshold=number -w '>5' -c '>7' --threshold=cpu -c '40<=x<=60'
> 
> I can see this being much harder to parse. There's merit in this, but  
> needs fleshing out.
> 
>>> just rip an SQL-parsing implementation directly, with subquery  
>>> support
>>> tucked right in.
>> This I really like.  This would let the syntax for threshold
>> specifications get as complex as needed for people who want to do
>> complex thresholds, use a paradigm for syntax that is very well
>> understood, while the specifications at the same time could maintain
>> as well the very simple integer specifications that are documented now
>> for people who don't want to go that path.
> 
> As lovely as that sounds, what would it look like in practise?
> 

Ugly, since SQL has different quoting / escape rules than shell, so
you have to mix the two in order to be able to utilize it fully. Iow,
same can of worms that Max wants to open, but opened from underneath
and only powerusers will get bitten, as opposed to everyone.

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