Nagios Support Forum

Hi everyone,

New user here. I'm prototyping Nagiox XI, and the only issue I'm having is setting up Nagios email notifications.
I run an Exchange 2010 server infrastructure, and I've added the Nagios IP address to the Exchange server to allow it to relay.

So, I go to Manage Email Settings, my mail method is SMTP. I have an exchange mailbox with a secondary email, which I'm using as part of the mail settings.
For host, I type the FQDN for my exchange server, port 25. No username and no password.

Her's what I get when I try to send a test message:

A test email was sent to [email protected]
----
Mailer said: SMTP Error: Could not connect to SMTP host. (method=smtp;host=myexchangeserver.mydomain.com;port=25;security=none)
An error occurred sending a test email!

Also, if I add my own exchange username and password account, now I get the following error:

A test email was sent to [email protected]
----
Mailer said: SMTP Error: Could not connect to SMTP host. (method=smtp;host=myexchangeserver.mydomain.com;port=25;smtpauth=true;security=none)
An error occurred sending a test email!

What am I missing here?

Thanks for your time.

Let's check your mail logs. Run this right after trying to send a test message:
and post the results here (censoring any sensitive information).

Well since we are only doing test emails at this point, we don't need to worry about which notification settings you are using. So, do you have the mail settings set to send from sendmail or smtp within the admin page? Do you have a valid internal mx record that would point nagios to your mail server? From the nagios server run "nslookup --querytype=MX yourdomain.com" and see if it responds with the proper IP. You might also try a telnet to port 25 from the nagios system to make sure that the exchange server is responding correctly.

Those commands all together would be:

Here are the results.

[root@nagios1 sysconfig]# nslookup -querytype=MX mydomain.com
Server: 10.11.5.21
Address: 10.11.5.21#53

*** Can't find mydomain.com: No answer

I don't know the reason why it can't query this information when the Exchange server is in the same network as nagios, and not mention that this is a working Exchange infrastructure for the entire company.

====
[root@nagios1 sysconfig]# nmap -p 25 myexchangeserver.mydomain.com

Starting Nmap 5.51 ( http://nmap.org ) at 2014-03-07 13:40 UTC
Nmap scan report for myexchangeserver.mydomain.com (10.11.22.11)
Host is up (0.00024s latency).
rDNS record for 10.11.22.11: myexchangeserver.mydomain.com
PORT STATE SERVICE
25/tcp filtered smtp
MAC Address: 00:50:56:A7:00:72 (VMware)

This looks about right, unless there's something else that's expected that it's not showing here.
===

Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds
[root@nagios1 sysconfig]# telnet myexchangeserver.mydomain.com
-bash: telnet: command not found

Looks like telnet isn't loaded on the appliance by default.

Looks like a firewall might be blocking you even though you have allowed the Nagios IP in the Exchange config. Can you post the logs I requested? They might be able to lend some more evidence to this hypothesis.

Hi, thanks for your quick reply.

Here's the info you requested.

[root@nagios1 ~]# tail -20 /var/log/maillog
Mar 7 13:35:07 nagios1 postfix/qmgr[1444]: ABAC515F0: removed
Mar 7 13:40:07 nagios1 postfix/pickup[10007]: CBDC31623: uid=0 from=<root>
Mar 7 13:40:07 nagios1 postfix/cleanup[10008]: CBDC31623: message-id=<[email protected]>
Mar 7 13:40:07 nagios1 postfix/qmgr[1444]: CBDC31623: from=<[email protected]>, size=170869, nrcpt=1 (queue active)
Mar 7 13:40:07 nagios1 postfix/local[10010]: CBDC31623: to=<[email protected]>, orig_to=<root>, relay=local, delay=0.29, delays=0.27/0/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox)
Mar 7 13:40:07 nagios1 postfix/qmgr[1444]: CBDC31623: removed
Mar 7 13:45:10 nagios1 postfix/pickup[1580]: E464A165B: uid=0 from=<root>
Mar 7 13:45:10 nagios1 postfix/cleanup[1581]: E464A165B: message-id=<[email protected]>
Mar 7 13:45:10 nagios1 postfix/qmgr[1444]: E464A165B: from=<[email protected]>, size=170869, nrcpt=1 (queue active)
Mar 7 13:45:10 nagios1 postfix/local[1583]: E464A165B: to=<[email protected]>, orig_to=<root>, relay=local, delay=1.2, delays=1.2/0/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox)
Mar 7 13:45:10 nagios1 postfix/qmgr[1444]: E464A165B: removed
Mar 7 13:50:08 nagios1 postfix/pickup[22143]: 0AF413536: uid=0 from=<root>
Mar 7 13:50:08 nagios1 postfix/cleanup[22144]: 0AF413536: message-id=<[email protected]>
Mar 7 13:50:08 nagios1 postfix/qmgr[1444]: 0AF413536: from=<[email protected]>, size=170869, nrcpt=1 (queue active)
Mar 7 13:50:08 nagios1 postfix/local[22146]: 0AF413536: to=<[email protected]>, orig_to=<root>, relay=local, delay=0.29, delays=0.27/0/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox)
Mar 7 13:50:08 nagios1 postfix/qmgr[1444]: 0AF413536: removed
Mar 7 13:51:19 nagios1 postfix/postfix-script[28984]: stopping the Postfix mail system
Mar 7 13:51:19 nagios1 postfix/master[1435]: terminating on signal 15
Mar 7 13:52:22 nagios1 postfix/postfix-script[1443]: starting the Postfix mail system
Mar 7 13:52:22 nagios1 postfix/master[1444]: daemon started -- version 2.6.6, configuration /etc/postfix

I think we have a couple things. The filtered result on nmap generally indicates that it can tell that the connection was recieved but closed right away, usually indicating either the service rejected it or a firewall blocked it.

Second, the nslookup for the mx record seems to state that you do not have an internal mx record setup to point at the mail server. Outlook and such would not need it, as they use rpc or rpc over https, however postfix definitely will.

Third, it seems that postfix is presently trying to send to the server nagios1.mydomain.com instead of myexchangeserver.mydomain.com, unless you have already configured the internal dns to point nagios1... to myexchangeserver... which would be fine. If this has already been setup with a cname or a record, you probably want to look at the exchange queues or any software spam filter to see if it got accepted but blocked somewhere internal to the software.

Okay, I figured this one out. I asked my Exchange admin and I was using the wrong FQDN for our Exchange infrastructure.

Thanks again!