Acknowledge Nagios Alerts thru Email 1

[ponoodle]

I have a VM running Ubuntu 8.04 that we use as our Nagios server. I have been trying to set it up so that I can reply to the alert emails I receive and acknowledge problems. I am using the directions from this page.

http://www.techopsguys.com/2010/01/05/acknowledge-nagios-alerts-via-email-replies/

But it is not working. I think the problem is that whoever setup the Ubuntu machine, installed and runs Nagios as root. I can reply to the alerts I get, and they are delivered to Ubuntu through fetchmail. It seems that the email is getting to Procmail, but then nothing happens. I can read the mail I sent in /var/mail/nobody.
Does anybody have any ideas? I am too new to Linux to know what other info you might need, so just let me know.

Thanks all.

 

[Noway2]

I can read the mail I sent in /var/mail/nobody.

This suggests that the the problem is, at least in part, that mail is not being directed to the nagios user. Do you have a nagios user and are the nagios processes running under that user account?

Typically, applications that require elevated privileges will launch the the startup process as root, and then drop the root privilege for the applications.

 

[ponoodle]

As far as I can tell, there is no nagios user. I think it is running as root.

 

[ponoodle]

I could be wrong. I tried "ps -u nagios" and it did show the nagios process, but I don't see a nagios directory in /home/.

 

[Noway2]

Normally, when you have applications that drop root privilege and run as a non-privileged user the account is locked or set to a bin/false shell. This is to prevent someone from being able to pwn this account and use it to further compromise the machine. If the account is locked, there will be no /home directory.

I think one of the first things that you would need to do would be to unlock this account, which would also involve creating a VERY STRONG user password. Per those instructions, it looks like you need to have mail sent to the nagios user with it delivered to a maildir located in the home directory. A PERL script is used to process this email and handle the alerts.

While I can appreciate the convenience of being able to acknowledge alerts via email, I personally question the practice of opening up a nagios user. I have seen reports indicating that the root is the most commonly attempted user to brute force compromise, with nagios being a close second. Given this statistic, I am not sure it is wise to create a nagios user and if you do make sure it has a strong password.

 

[ponoodle]

Thanks for your help. I'm not too worried about the security, since this server doesn't touch the outside world. And I'll take your advice about the strong password. Do you think that unlocking the nagios user would affect how nagios itself runs? Everything is pretty much automated and works as it is now.

 

[Noway2]

I doubt that it would have any effect on the impact. It is more a security concern than anything else.

 

[ponoodle]

Thanks again for your help. Unlocking the account did the trick, but I have one more problem. This works for services but not for hosts. In the syslog, I get this: "nagios: EXTERNAL COMMAND: ACKNOWLEDGE_HOST_PROBLEM;;1;1;1;email;email;acknowledged through email"
It seems that the $host variable is not working for host problems. Here is my command.cfg entries for hosts and services. They look the same to me. Can anybody see where the problem is?

# 'notify-host-by-email' command definition
define command{
command_name notify-host-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
}

# 'notify-service-by-email' command definition
define command{
command_name notify-service-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTNAME$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}

Thanks

 

[ponoodle]

I don't know if this will help, but here is what the .procmailrc.log says.

procmail: [17841] Mon Mar 28 11:36:42 2011
procmail: Assigning "PATH=/usr/bin"
procmail: Assigning "MATCH="
procmail: Matched ""PASSWORD" ack RE: ** PROBLEM Host Alert: "HOSTNAME" is DOWN **"
procmail: Match on "^Subject:[    ]*\/[^  ].*"
procmail: Executing "/usr/lib/nagios/eventhandlers/processmail,"PASSWORD" ack RE: ** PROBLEM Host Alert: "HOSTNAME" is DOWN **"
procmail: Assigning "LASTFOLDER=/usr/lib/nagios/eventhandlers/processmail "PASSWORD" ack RE: ** PROBLEM Host Alert: "HOSTNAME" is DOWN **"
procmail: Notified comsat: "nagios@:/usr/lib/nagios/eventhandlers/processmail "PASSWORD" ack RE: ** PROBLEM Host Alert: "HOSTNAME" is DOWN **"
From ME@MYEMAIL.COM  Mon Mar 28 11:36:42 2011
 Subject: "PASSWORD" ack RE: ** PROBLEM Host Alert: "HOSTNAME" is DOWN **
  Folder: /usr/lib/nagios/eventhandlers/processmail "PASSWORD" ack RE: ** PRO     1685

 

[ponoodle]

I think the OS issues have been resolved here, and this is now a Perl issue. So, I am going to take this to the Perl forum. I hope that's OK.

Thanks all.