Linux Today: Linux News On Internet Time.
Search Linux Today
Linux News Sections:  Developer -  High Performance -  Infrastructure -  IT Management -  Security -  Storage -
Linux Today Navigation
LT Home
Contribute
Contribute
Link to Us
Linux Jobs


Top White Papers

More on LinuxToday


OpenNMS Update v2.9

Feb 28, 2001, 06:46 (0 Talkback[s])
(Other stories by Shane O'Donnell)

Date: Tue, 27 Feb 2001 19:33:14 -0600 (CST)
From: announce-admin@opennms.org
To: announce@www.opennms.org
Subject: [OpenNMS-Announce] OpenNMS Update v2.9


OpenNMS Update
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

Project Status

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
http://www.opennms.org/fom-serve/cache/20.html

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
which is basically from the same project as the Java RPC libraries we are using. This is probably worth a look for those of you interested in running on NT.

* 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 luke@opennms.org

* May 5th - Twin Cities LUG, Minneapolis, MN
* June 2nd - Northern Virginia LUG (NOVALUG), Alexandria, VA
* June 11-15 - OpenView Forum 2001, New Orleans, LA
* July 23-27 - O'Reilly Open Source Convention, San Diego, CA

For additional details on these appearances and others, check out the web site at
http://www.opennms.org/sections/opennms/events


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
http://www.opennms.org/sections/get_involved/eap/

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?


Afterthoughts

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,

Shane O.
========
Shane O'Donnell
OpenNMS.org
shaneo@opennms.org