From: announce-admin@opennms.org
To: announce@www.opennms.org
Date: Tue, 27 Feb 2001 19:33:14 -0600 (CST)
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
==================
_______________________________________________
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to:
http://www.opennms.org/mailman/listinfo/announce