OpenNMS Update v2.9

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

---