Jeff Gehlbach wrote: > On May 6, 2008, at 2:46 AM, Adrian Overbury wrote: > >> I've got a job I need OpenNMS to run on a regular basis -- say, once >> every ten minutes or so. It will collect mail from an inbox via pop3, >> and dump the entire headers (plus any decoded text/plain MIME body >> parts) into a queue for an administrator to come along and process >> later >> on. > > Knowing only what you've said above, I would question whether this job > is really suited to OpenNMS. How does it tie into the management of > your networks or systems? >
Well, given what you said, I'd have an external program fetch the mail and create the events (as well as a little before-usage parsing and putting the raw email itself into the database). This whole process -- whether the download of mail is performed by OpenNMS or a command-line utility -- is part of the management of my systems because these emails are security advisories from Ubuntu, RedHat and Debian. Every system we support runs one version or another of these operating systems. We're in the middle of extending OpenNMS to be able to support package management, to tell us what the latest advised version of a given package is, and which systems need to be updated. This requires me getting the advisory mails into the system through one method or another and parsing them to extract the relevant information. >> When it does this, I'd like it to fire off an event (a very, very >> low priority event, but still escalatable) to let the Administrators >> know that there's mail waiting to be processed. > > Events do not have an intrinsic priority (only a severity) and cannot > be escalated. Alarms can be escalated, though, and alarms begin life > as events. Okay, this was a misunderstanding on my part. I'm glad to have it clarified. On reflection, an event with a severity of Normal (or Warning at the most) would be all I need. If in future, though, I do want this event to trigger an alarm, and for that alarm to escalate if the task isn't resolved within a certain time-frame, I would need to define an alarm-data element in my event configuration that has the attributes reduction-key, alarm-type and auto-clean set to appropriate values, yes? I actually like this reduction-key thing. I'd configure it so that while an event would be fired off each time new mail comes in for processing, at any one time there'd only be one alarm related to the package management section. Also, there's a certain advantage to doing the grabbing of mail using something that *isn't* Java. I'm not JavaMail's biggest fan, and I know I can throw out a quick program in Perl or Python that will do the job I want in less time with less steps and definitely with less hair-pulling. Adrian ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
