On May 6, 2008, at 9:18 PM, Adrian Overbury wrote: > 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.
I see. > 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. You're almost wandering into configuration management here, which is a sufficiently large discipline with enough existing good tools that we are beginning to pursue integrations with those tools. I'm curious what work you're doing in OpenNMS to support this effort, and whether you would be interested in comparing notes with the folks who are working on the "official" interfaces and implementations for configuration management integrations in OpenNMS. > 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? Right. In your case, alarm-type will probably always be "1" (for "problem"), and I imagine you would not want to auto-clean the underlying events. As far as automagic escalation, there's actually a default automation in recent OpenNMS releases that does this for alarms that are not cleared or acknowledged. > 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. Right -- or you could have one alarm per node, or one alarm per vulnerable package, or... just as long as the event you send into OpenNMS conveys the necessary information. > 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. We're big fans here of using what works for you :) Another advantage to externalizing the heavy lifting is that you won't need to maintain a set of patches against the official OpenNMS code base. In fact, if you're able to unify your package management support infrastructure with the existing config management work already underway, you could run totally pristine OpenNMS sources. That way you would avoid Dave's axiom that "if you're forked, you're forked." -jeff ------------------------------------------------------------------------- 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
