Hi, NAV has been running on a Debian machine flawlessly for a while, but after I did a "aptitude update" and "aptitude upgrade" I ran into some problems. The updated NAV package warned me that I needed to edit in the db password manually, which I did.
Firstly I had to point apache into the right directory to get the webpage to work again. It seems to work properly. It detects devices going up and down and updates statuses on the frontpage/status page and logs per device seem fine as well. So as far as I can tell the database is working as it should as well as all the background processes.
Email alerts does not work though. Apparently the addresses are blacklisted according to the alertenginge.log, but I can't find any place where email addresses are blacklisted. New alert adresses also get blacklisted. From what I can see in our mailserver log, the mail alerts never get there, which is understandable since it looks like there is some setting in NAV somewhere that stop alerts from being sent.
Here is an example from the log.
[2009-07-27 00:48:19,368] [WARNING] [pid=5403 nav.alertengine.alertaddress.send] Not sending alert 4927 to xxxx@example.com as handler Email is blacklisted
(Email address edited out)
alertengine.err.log is empty.
Email from Cron daemon works fine. I tried changing the mailserver in the alertengine.conf file, but that did not change anything.
I am lost here. Anyone have any pointers?
Lars Marius Schjærin Brednett AS
On Mon, 27 Jul 2009 01:51:09 +0200 "Lars" lms-list@brednett.no wrote:
Firstly I had to point apache into the right directory to get the webpage to work again. It seems to work properly.
Yeah, if you upgraded from 3.4 to 3.5, the Debian package changed the location of the NAV virtualhost config file and the NAV web site document root.
Email alerts does not work though. Apparently the addresses are blacklisted according to the alertenginge.log, but I can't find any place where email addresses are blacklisted. New alert adresses also get blacklisted. From what I can see in our mailserver log, the mail alerts never get there, which is understandable since it looks like there is some setting in NAV somewhere that stop alerts from being sent.
Here is an example from the log.
[2009-07-27 00:48:19,368] [WARNING] [pid=5403 nav.alertengine.alertaddress.send] Not sending alert 4927 to xxxx@example.com as handler Email is blacklisted
(Email address edited out)
Ah, a slight misunderstanding here. It is not the email addresses that are being blacklisted, it's the Alertengine's email plugin itself. When an Alertengine plugin keeps failing to dispatch alerts, it is blacklisted. This is a measure to prevent large amounts of error email spam to the administrator.
When a plugin is blacklisted for failed dispatch attempts, an error message is mailed to the address configured in ADMIN_MAIL in nav.conf. Of course, the there is a general problem with sending email, you won't receive that email either.
If you can't find the error message that says why the email handler is blacklisted, please restart the alertengine and follow the log closely to see whether it is blacklisted again. Since it's the email plugin being blacklisted, it is likely some sort of SMTP error is causing it.
Maybe plugin blacklisting should be optional/configurable in alertengine.conf?
alertengine.err.log is empty.
You can safely delete alertengine.err.log, it belongs to the old Perl-version of alertengine, which no longer exists.
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Wednesday, August 12, 2009 10:57 AM If you can't find the error message that says why the email handler is blacklisted, please restart the alertengine and follow the log closely to see whether it is blacklisted again. Since it's the email plugin being blacklisted, it is likely some sort of SMTP error is causing it.
Maybe plugin blacklisting should be optional/configurable in alertengine.conf?
Thank you. Of course I broke my MTA as well during that Debian update. Did not think I did as I continued to get reports from cron jobs, but I did. Fixed the problem with the MTA, and now I get alerts again.
As for configuring blacklisting or not, I am not sure. Maybe include the error message causing the blacklist instead to make it easier to spot?
On Fri, 14 Aug 2009 19:02:32 +0200 "Lars" lms-list@brednett.no wrote:
As for configuring blacklisting or not, I am not sure. Maybe include the error message causing the blacklist instead to make it easier to spot?
That's a good idea, Lars. I'll add that to our Launchpad tracker :)
-
Lars -
Morten Brekkevold