I'm wondering if this could be some sort of authentication problem.  When I run the ssh command as nagios, I get the expected reponse:
 
dev02: # su - nagios
[EMAIL PROTECTED]:~> ssh -i /usr/local/nagios/.ssh/id_dsa olympus "/usr/local/nagios/libexec/check_oracle --tablespace mwmt01 nagios password TS01 98 96"
mwmt01 : TS01 OK - 18.80% used [ 487 / 600 MB available ]|TS01=18.80%;96;98;0;100
[EMAIL PROTECTED]:~>
 
When I run the ssh command as root, this is where I get the failure:
 
[EMAIL PROTECTED]:~> su - root
dev02: #  ssh -i /usr/local/nagios/.ssh/id_dsa olympus "/usr/local/nagios/libexec/check_oracle --tablespace mwmt01 nagios password TS01 98 96"
CRITICAL - ORA-12154: TNS:could not resolve service name
 
Now, notice when I switch back to nagios and run check_by_ssh (not to be confused with ssh), I get the same error as above:
 
dev02: # su - nagios
[EMAIL PROTECTED]:~> /usr/local/nagios/libexec/check_by_ssh -H olympus -i /usr/local/nagios/.ssh/id_dsa -C "/usr/local/nagios/libexec/check_oracle --tablespace mwmt01 nagios password TS01 98 96" -l nagios
CRITICAL - ORA-12154: TNS:could not resolve service name
[EMAIL PROTECTED]:~>
 
Notice that the last two commands have the same result.  The first is using ssh as user root, and the second is using check_by_ssh as user nagios.  Yet, if I run ssh as user nagios I then get the expected response.  Any ideas?

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bret Goodfellow
Sent: Friday, October 06, 2006 4:29 PM
To: [email protected]
Subject: [Nagios-users] check_oracle plugin returns - CRITICAL - ORA-12154:TNS: count not resolve service name

My Nagios server is returning this error when executing the check_by_ssh plugin, which also includes the check_oracle plugin. 
 
Here's the scenario.  I have a remote server, called olympus, that is running Oracle 9.2.0.6.  I want to be able to monitor tablespace size using the check_oracle plugin.  I have copied the check_oracle plugin to the remote server, olympus, and have successfully run the plugin on olympus. When I run the check_oracle plugin I am logged in as nagios.  e.g.
 
[EMAIL PROTECTED]:~> /usr/local/nagios/libexec/check_oracle --tablespace mwmt01 nagios password TS01 98 96
mwmt01 : TS01 OK - 18.80% used [ 487 / 600 MB available ]|TS01=18.80%;96;98;0;100
[EMAIL PROTECTED]:~>
 
This is what I expected.  Now, from my Nagios Server, dev02, I would like to be able to monitor the oracle tablespace on olympus.  I first tested ssh by executing the following command from dev02:
 
dev02: # su - nagios
[EMAIL PROTECTED]:~> ssh -i /usr/local/nagios/.ssh/id_dsa olympus "/usr/local/nagios/libexec/check_oracle --tablespace mwmt01 nagios password TS01 98 96"
mwmt01 : TS01 OK - 18.80% used [ 487 / 600 MB available ]|TS01=18.80%;96;98;0;100
[EMAIL PROTECTED]:~>
 
As you can see, I can ssh from my Nagios server and have it execute the check_oracle plugin on olympus.  Everything is good so far.  My goal is to to setup Nagios to run this.  I now want to check the tabespace on olympus by using the Nagios plugin: check_by_ssh.  Below is the command that is executed on dev02 :
 
[EMAIL PROTECTED]:~> /usr/local/nagios/libexec/check_by_ssh -H olympus -i /usr/local/nagios/.ssh/id_dsa -C "/usr/local/nagios/libexec/check_oracle --tablespace mwmt01 nagios password TS01 98 96"
CRITICAL - ORA-12154: TNS:could not resolve service name
[EMAIL PROTECTED]:~>
 
The last 2 commands are both run from the Nagios Server.  Why doesn't the check_by_ssh work, yet the native ssh command does work?
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nagios-users mailing list
[email protected]
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

Reply via email to