Monitoring MSExchangeIS

[alceryes]

I am currently monitoring MSExchangeIS using check_nt.
Is there a way to monitor the mount-state of individual mail stores using Nagios? I had a store dismount and Nagios didn't report it because the store.exe process is for ALL stores.

TIA!

[jsmurphy]

There isn't a native plugin that I know of to do this (granted I haven't exhaustively looked), but you could probably pretty easily throw together a powershell script to do this and then add it to the NSClient config. Coding plugins for Nagios is easy, you only need to return two things...

1. Any text to standard out that describes the current state.
2. An exit code that Nagios understands... the exit codes are 0 = OK, 1 = Warning, 2 = Critical, 3 = Unknown.

I think this is probably going to be the best way to get the monitoring you want.

[alceryes]

http://exchange.nagios.org/directory/Pl ... sh/details

This looks like it might do two of the things I'm trying to accomplish in one. However, I can't get it to work. I keep on getting the error - ./check_exchange_webmail.sh: line 44: curl: command not found

I know it means that it doesn't like the curl command but the curl libs are installed so I'm not sure...any ideas? (Ubuntu 9.1)

Thanks!

[alceryes]

Okay, I was able to get curl installed properly so as not to get the above error but not I just get the 'CRITICAL - CRAP, SOMETHING HAPPENED' even though I know that the email with the key is there. Any ideas on how I can debug?

Note: I am a novice when it comes to Linux and Nagios but I am good at following instructions.

Thanks!

[jsmurphy]

It's possibly failing to authenticate... at the top of the script have you set the following variables?
user="[user]"
pass="[pass]"
key="[key]"

if you haven't, replace the text and square brackets with the relevant information. Beyond that you can try running the curl command on the command line and getting the error straight from the horses mouth:

Code: Select all

curl -s -k -u <username>:<password> https://<hostname>/exchange/<username>/Inbox/?Cmd=contents&Page=1

It's also possible this was written for a different version of exchange and the URI has changed.

[alceryes]

Thx jsmurphy, I can run the command manually now and it works!
The problem is that the command isn't working in Nagios. It's always giving me the CRITICAL "Crap, something happened..."

I'm getting closer...I can taste it! Any ideas?

Edit - I am testing it with the server it was designed for (Exchange 2003).

[jsmurphy]

My inadequate permissions senses are tingling.

The problem with a lot of shell scripts is that they will try to execute arbitrary command line utilities (such as curl in this instance) and often they are utilities that the Nagios account won't have permissions to access. You can test this by running "su - nagios" which will allow you to run commands as the nagios user (you can verify this by typing "whoami"), test the curl command again in my previous post and it should tell you that it can't.

First do a "whereis curl" which will tell you where it is, assuming it's in /usr/bin/ run the following: "chmod 755 /usr/bin/curl" which will allow any user to run the curl command. Hopefully this helps!

[alceryes]

Nope, I had already done a chmod 755 to try and fix it.
Any other ideas?

Edit - Is there a way that I can see exactly what nagios is executing?

[jsmurphy]

I need more of the information from the steps I asked you to try out in my previous post. What happens when you impersonate the Nagios user and try to run the script? Assuming that it fails, are there any other command line utilities from the script you can't execute as that user (echo, sed, cut, etc)?

You can turn on very verbose logging and probably find the exact execution... but it's unlikely to help you resolve your issue unless you are trying to locate a bug in the actual Nagios code during execution. The easiest way to find out what Nagios is going to execute is just to look at your commands.cfg.

[alceryes]

for some reason I can't impersonate the nagios user.
When I do 'su-nagios' it executes but a 'whoami' still responds with 'root'. Some searching on the www showed how to 'run as' and 'execute' the command in one line, and it passes, but I still think it's running as root.