Search Exchange
Search All Sites
Nagios Live Webinars
Let our experts show you how Nagios can help your organization.Login
New ListingsDirectory Tree
NagiosMailACK
Current Version
1.1
Compatible With
- Nagios 2.x
- Nagios 3.x
Owner
Website
Hits
104306
Files:
| File | Description |
|---|---|
| nagiosMailAck v1.1.zip | first of all read "README" file |
Meet The New Nagios Core Services Platform
Built on over 25 years of monitoring experience, the Nagios Core Services Platform provides insightful monitoring dashboards, time-saving monitoring wizards, and unmatched ease of use. Use it for free indefinitely.
Monitoring Made Magically Better
- Nagios Core on Overdrive
- Powerful Monitoring Dashboards
- Time-Saving Configuration Wizards
- Open Source Powered Monitoring On Steroids
- And So Much More!
Currently this service supports only GMail IDs; and a single ID can be used for multiple Nagios Servers.
Edited to v1.1
Change: there was an issue with Service Script's wrong Status being shown... it got fixed in v1.1
We all know that Nagios has this nice feature of Alerts/Notifications being mailed to Contacts specified in configuration file.
To ACK these Notifications currently there are two main ways:
[] Admin need the Nagios Web Interface to ack the alert, not a god idea to link Nagios Server (with internal details) to Public Network
[] Install service like ProcMail, etc. and act like a MX and run your own MailBox on that machine to receive direct ack via mail
I just tweaked the 2nd option to a much easy and quick alternative of using any existing Mail Service to receive ACK mails and check that mailBox instead.
We'll be assigning a unique NagiosID to each of our Nagios Server and that will be mentioned in the Ruby Script installed.
Then any Admin to ACK the Alert; will Prefix the generated Forwarding Mail Subject with that NagiosID and Space; and forward it to the desired Mail-Id which is configured in Script to listen to.
This will help Service identify the ACK MAil for its box.
What we are providing here is a simple service entirely scripted in Ruby; that runs as a daemon and checks for a mails recieved at a specified Mail-ID; if the subject has its NagiosID... it removes the mail from InBox; moves it to a Nagios Label and Acknowledged the Notification on Server.
To ACK these Notifications currently there are two main ways:
[] Admin need the Nagios Web Interface to ack the alert, not a god idea to link Nagios Server (with internal details) to Public Network
[] Install service like ProcMail, etc. and act like a MX and run your own MailBox on that machine to receive direct ack via mail
I just tweaked the 2nd option to a much easy and quick alternative of using any existing Mail Service to receive ACK mails and check that mailBox instead.
We'll be assigning a unique NagiosID to each of our Nagios Server and that will be mentioned in the Ruby Script installed.
Then any Admin to ACK the Alert; will Prefix the generated Forwarding Mail Subject with that NagiosID and Space; and forward it to the desired Mail-Id which is configured in Script to listen to.
This will help Service identify the ACK MAil for its box.
What we are providing here is a simple service entirely scripted in Ruby; that runs as a daemon and checks for a mails recieved at a specified Mail-ID; if the subject has its NagiosID... it removes the mail from InBox; moves it to a Nagios Label and Acknowledged the Notification on Server.
Reviews (4)
byJohnFLi1, July 22, 2014
it is not getting the emails from my gmail account. Had to manaully follow what the install script did so I knew what and where to put the various files.
WHen starting the service I get the message:
[root@centos65 nagMailAck]# /usr/lib/ruby/1.8/net/imap.rb:905:in `connect': SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A (OpenSSL::SSL::SSLError)
from /usr/lib/ruby/1.8/net/imap.rb:905:in `initialize'
from /usr/local/bin/nagMailAck/nagMailACK.rb:96:in `new'
from /usr/local/bin/nagMailAck/nagMailACK.rb:96
from /usr/local/bin/nagMailAck/nagMailACK.rb:94:in `loop'
from /usr/local/bin/nagMailAck/nagMailACK.rb:94
I can only assume that isnt suppose to happen. Any ideas?
WHen starting the service I get the message:
[root@centos65 nagMailAck]# /usr/lib/ruby/1.8/net/imap.rb:905:in `connect': SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A (OpenSSL::SSL::SSLError)
from /usr/lib/ruby/1.8/net/imap.rb:905:in `initialize'
from /usr/local/bin/nagMailAck/nagMailACK.rb:96:in `new'
from /usr/local/bin/nagMailAck/nagMailACK.rb:96
from /usr/local/bin/nagMailAck/nagMailACK.rb:94:in `loop'
from /usr/local/bin/nagMailAck/nagMailACK.rb:94
I can only assume that isnt suppose to happen. Any ideas?
byroman_empire, September 24, 2013
Thank you for a very useful script!
Here is what I've modified to make it working:
Removed the following strings from nagMailAck file:
elif [ ! -e $nagPath/nagiosACK.pl ]; then
echo "nagioACK.pl not found @"$nagPath"/"
exit 1
Modified nagMailACK.rb file to suit our Nagios alert message subject in "composing acknowledgement string for nagios.cmd" part.
Here is what I've modified to make it working:
Removed the following strings from nagMailAck file:
elif [ ! -e $nagPath/nagiosACK.pl ]; then
echo "nagioACK.pl not found @"$nagPath"/"
exit 1
Modified nagMailACK.rb file to suit our Nagios alert message subject in "composing acknowledgement string for nagios.cmd" part.
Great plugin. Worked at my end on RHEL 6 and I can acknowledge fine. Only trouble I have at the moment is when I start the /etc/init.d script it doesn't say OKAY. It shows FAILED but in reality service is started.
/etc/init.d/nagMailAck stop
Stopping Nagios Mail ACK
-----
root@server:~ # 10:29 AM]/etc/init.d/nagMailAck start
Starting Nagios Mail ACK
: command not foundailAck/nagMailAck.sh: line 1:
-----root@server:~ # 10:29 AM] [FAILED]
/etc/init.d/nagMailAck stop
Stopping Nagios Mail ACK
-----
root@server:~ # 10:29 AM]/etc/init.d/nagMailAck start
Starting Nagios Mail ACK
: command not foundailAck/nagMailAck.sh: line 1:
-----root@server:~ # 10:29 AM] [FAILED]
Thanks for putting this together. I had to modify it for my organization because we use a different format for the email subject.
