Using ! in check_command - part 2

[Cook, Garry]

Michael Eck wrote:
> Interestingly enough, I can't seem to make my $USERn$ macros work at
> all - although I assume $USER1$ is working as my libexec path. Even
> with the !, I can't get a check to return OK when using my macro as
> the community string   
> 
> I've got
> resource.cfg:
> $USER2$=public
> 
> services.cfg:
> check_command check_plugin!$USER2$!75!85
> 
> All is well when $USER2$ is replaced with "public"

Unless I've misread your post, you are saying that using the community string 'public' works when checking the device.
So, I have to ask, are you sure that you have the community string containing the '!' setup on the agent/device?
If so, I would think that you would have removed the 'public' string, unless it was put back for testing purposes.

In my resource.cfg '$USERn$' is set to the community string containing the '!' without backslash escaping the character like so (not my real string, but you get the point...):
$USER6$=public!

In my checkcommands.cfg I have the following to check CPU usage on a Cisco router (the command_line is going to word wrap):
# 'cisco_cpu' command definition
define command{
        command_name    cisco_cpu
        command_line    $USER1$/check_snmp -H $HOSTADDRESS$ -o .1.3.6.1.4.1.9.2.1.58.0 -w 84:70 -c 100:85 -C $USER6$ -l CPU\ Utilization -u%
        
Finally, in my services.cfg I just call the 'cisco_cpu' plugin and voila!, instant CPU utilization checking.

If a setup like this does not work for you, I would go back to what I said earlier - check your device and make sure that the community string is actually configured properly at that end as well.

Also, read these docs about macros: 
http://nagios.sourceforge.net/docs/1_0/macros.html

Make sure permissions are set correctly for your resource file, as outlined by:
http://nagios.sourceforge.net/docs/1_0/configmain.html#resource_file


> On Jun 17, 2004, at 6:34 PM, Cook, Garry wrote:
> 
> 
> 
> SNMP checks work for me with a '!' in the community string. Now, I
> don't remember if I needed to escape it or not, and I can't get to
> the box to check it right now, so you may need to try it both ways.
> However, I did NOT put the community string in the services.cfg or
> checkcommands.cfg. I wanted to be a little bit more safe, so I
> assigned it to one of the user variables in resource.cfg. I then
> added this variable (ie. $USER9$) to my check command as an argument.
> 
> Whether or not this should really be considered 'safe' might be
> disputed by some. It's never been compromised and it works in my
> check commands, so I'm happy.  
> 
> HTH.
> -g
> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net on behalf of Michael
> Eck 
> Sent: Thu 6/17/2004 12:20 PM
> To: nagios-users
> Cc:
> Subject: [Nagios-users] Using ! in check_command - part 2
> 
> Original Post:
> Greetings,
> Is there a trick than anybody knows of the use a ! as a character in a
> password for a check_command?
> The obvious problem is that it's also the field delimiter.
> 
> 
> Ok, I got lots of replies suggesting that I try to escape my !.  I
> didn't mention it in my first post but I did indeed try that.  I tried
> quotes of several varieties with no luck as well.
> 
> Has anybody actually gotten this to work or does anybody know that
> this 
> will work or were they just shots in the dark?  Of course I can change
> the community strings but that's just a cop-out.
> 
> Any ideas?
> 


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null