OpenNMS Update v2.9Feb 28, 2001, 06:46 (0 Talkback[s])
(Other stories by Shane O'Donnell)
No-Size-Fits-All! An Application-Down Approach for Your Cloud Transformation REGISTER >
Date: Tue, 27 Feb 2001 19:33:14 -0600 (CST)
Vol 2, Issue 9
Feb 27, 2001
In this week's installment...
* Project Status + 0.6.1 Patched Almost Immediately + New Approach to Releases + OpenNMS & Win2K + Coding Projects Underway * Upcoming Road Shows * Early Adopter Program Status * The Wish List
0.6.1 Patched Almost Immediately:
Because our releases just haven't been changing enough recently...
We discovered a minor yet significant bug in the 0.6.1 release, the RPMs were almost immediately rebundled as 0.6.1-2 with the fix incorporated.
The bug was basically that when we checked in the other fixes and features for 0.6.1, we also accidentally checked in a development configuration file that effectively broke the release.
The details of the bug and fix (as well as many other common
errors and their fixes) can be found in the OpenNMS FAQ at
New Approach to Releases:
We've screwed up twice recently in our hurry to push releases out the door. In both cases, these were honest mistakes, but at the same time, extremely painful ones for people trying to use the OpenNMS software.
While we believe wholeheartedly in the "Release early, release often" philosophy, we also believe in letting our distributions fully reflect the quality of the effort that has gone into them.
Henceforth, all releases will be "field-tested" internally prior to general release. This process will take, at most, two days, and is an absolute minimum level of QA that needs to happen before inflicting the pain of upgrades on the masses.
In reality, this will only impact the announced dates of the releases and their subsequent announcements in places like Freshmeat, etc. The actual bits that you might be interested will be tagged in CVS and the nightly builds will be, effectively, a release candidate. We should even be able to name them appropriately--given we still have our heads about us during release time.
So rest easy in that the overall quality of the installations will improve, and coupled with some of the stuff we've got coming down the pike (e.g., easier installation, etc.), the pain factor should be reduced considerably.
Coding Projects Underway:
* Snort Integration -- Initial design work is underway, with some pre-alpha functionality demo'd in Perl. Need to do some serious nuts-and-bolts analysis of this integration before proceeding. Still very early in this effort.
* Solaris Port Postgres Procedures -- Underway. No update.
* Postgres for NT -- As far as we know, this will work, but we still haven't heard back definitively from someone who has tested it. There are some additional hurdles to jump for the Win32 platform, now that we have a dependency on a portmap service for NT...
* Portmap for NT -- There is one that ships with NT/2000 that
_should_ work, but we haven't tested it. There is another one
referenced at http://www.plt.rwth-aachen.de/ks/english/oncrpc.html
* SNMP Poller/Data Collection -- The Web UI is alive, and we are talking about some tweaks to the default RRD formats. Thoughts on this? Let us know.
* Event DTD -- Changed yet again.
* Tuning -- Still haven't had a chance to get some decent benchmarks. However, we still targeting A = 440hz.
* User Interfaces -- Some bug fixes are in. Others pending. Larry's still adding features/functionality to the Web UI. And JSPs are Scriptlets.
* SCM UI -- Replaced with "./opennms.sh scm status"
* LDAP Poller -- We're in the infancy of this one. If you want in, let me know.
* Maji Prelim Work -- Rick is building Perl code that is successfully parsing MIB files. Check him out, in all his glory, on the "events" list.
* Notification Configuration -- Actively being moved to the Web UI.
* Swing Interface -- Fighting random oddities. Proceed with caution.
* Discovery/CAPSD/Database Review -- Revisiting the way Discovery and capsd communicate, verifying that stuff is accurately written to the database, and adding some maintenance functionality we didn't have previously. Mike's the man (and he hasn't broken the build recently, either!)
Upcoming Road Shows
Interested in having an OpenNMS speaker for your group? Of course you are. Email Luke at email@example.com
* May 5th - Twin Cities LUG, Minneapolis, MN
For additional details on these appearances and others, check
out the web site at
Early Adopter Program Status
We are nearing the saturation point for the Early Adopter
Program, so if you are interested, make sure you check out the web
page and signup form at
Our current status provides naught but good news. Jeff currently has our earliest of early adopters, etrials, up and running with some initial levels of functionality. Granted, there is considerable configuration and customization yet to go there (as well as at the rest of our EAP sites), but hey--baby steps.
For both EAP members and the world at large, the key features we are currently working on allow for more usability and configurability of the base product, and more specifically, the event handling subsystem.
Currently, events are identified by their universal event identifier (UEI), but in the case that the UEI and the source of the event are both critical, we don't handle it well. In other words, if you want to get paged when a node goes down--easy. Configure the "NodeDown" UEI to map to a paging notification. But if you want to be paged if only your core router goes down, tough. It's either notification feast or famine. But we're fixing that. Look for that in an upcoming release.
The Wish List
A lot of positive email and community support this week. We've already had offers from some folks (who'll remain anonymous until they either publish code with their name in it or tell me otherwise) to do both the Snort integration piece as well as some testing on Win2K.
If you'd like to help on either of these fronts (or anything else listed below), drop me a line. And as always, thank you for your support.
* In the 0.6.x release (and CVS), checkout the TODO file
* More Data Collection configs wanted for the DataCollection.xml
* Any interest in more TCP pollers? Let us know (or better yet, build one yourself...)
* LDAP Poller
* nmap Poller (That idea came in via email this week. Cool!)
* Documentation and development your game? How about a white paper on how to extend OpenNMS with custom pollers, custom configs, and/or your own scripts/code.
* Testing on new, exciting platforms is always appreciated. Somebody want to mess with the Cygwin port of our Postgres stored procedures and see where we stand?
* Any additional help we can get proving our documentation either right or wrong is appreciated. Thanks.
* Got any creative applications for OpenNMS that we haven't considered? Let us know!
* A Security analysis of OpenNMS?
I no more than get the Update sent last week and BAM! Three Meatloaf CDs burned into the archive, and Steve professing his love for Meatloaf (not the food, the man...well, not the man, but the music).
The process of moving into the new office is, shall we say, a pain. I've always known that provisioning circuits is a huge pain, but you forget just how huge a pain that is until you have to do it again.
Open-ended Question of the Week: What's the right balance of name resolution in a network management product? Mandate it all over the place, and you can kill yourself in performance, let alone if DNS mysteriously "goes away". Don't implement it and suddenly everybody complains that the tool is unusable. I've worked with tools that were crippled if they couldn't do name resolution, and I've worked with others that were spiffy, so long as you had an nslookup session up in another window (read: PITA).
So what's the right answer? Take it to the [discuss] list.
Catch ya on the flipside,
0 Talkback[s] (click to add your comment)