From: announce-admin@opennms.org
To: announce@www.opennms.org
Date: Tue, 6 Feb 2001 17:26:35 -0600 (CST)
Subject: [opennms-announce] OpenNMS Update v2.6

================
 OpenNMS Update
================
 Vol 2., Iss. 6
================
  Feb. 6, 2001
================
   
   In this week's installment...

     * Project Status
          + Another Addition to the Team
          + SNMP Data Collection Approach
          + Coding Projects Underway
     * Upcoming Road Shows
     * Web Site Questions
     * The Wish List
       

==============
Project Status
==============
   
Another Addition to the Team:
     
     We are all exceedingly pleased to announce that Jeff Schneider,
     network and systems management consultant par excellence, has
     joined the OpenNMS team as an "Implementation Consultant". For
     documentation purposes, let it be known that we just made up that
     title at the last minute. We had been planning to call him the
     "Deputy Assistant Undersecretary for Gruntwork", but we couldn't
     decide if the "s" in Undersecretary should be capitalized, and it
     was easier to make up a new title than to log on to dictionary.com.
     
     For those of you that may have heard Jeff's name, you may have seen
     him in any number of places over the past few years:
     
     * Presenting at the OpenView Forum
     * Teaching NNM & IT/O classes for HP
     * Consulting for Onion Peel/Tavve
     * Working as Roadie & Sound Tech for Dokken
       
     Obviously, we're interested in the last one...
     
     Seriously, we are thrilled to add Jeff to the roster. Jeff will be
     in charge of delivering services within and helping to extend the
     OpenNMS Early Adopter Program. With his extensive background, and
     willingness to approach problems from a process/workflow
     perspective, Jeff would be a great addition to any team. We're just
     glad that it's ours!
     
     A hearty welcome to Jeff!
     
SNMP Data Collection Approach:
     
     For those of you that haven't had time to dig into the data
     collection, I wanted to take a minute to give you a peak under the
     covers as to how it will do its thing.
     
     First, it's implemented as just another poller. It uses the same
     scheduling mechanism as the other pollers for scheduling and is
     just as configurable as the others, with timeouts, retries, and
     community strings available to be set. Once you decide to engage
     this poller, it jumps out and does its thing, which roughly, is as
     follows:
     
     * Reads the DataCollection.xml file, which maps the SysObjectID of
       the device in question to a set of OIDs which will be collected
       from the device.

     * When the scheduler invokes the poller with a target interface,
       those OIDs are SNMP GETted (SNMP GOT?) and slammed into an RRDTool
       RRD database.

     * The RRDTool database is responsible then for archiving the data in
       appropriate fashions. By default, the RRD will save the following
       types and amounts of data:

          + 2016 5-minute Intervals
          + 744 1-Hour Intervals
          + 93 1-Day Intervals
          + 105 1-Week Intervals
          + 60 1-Month Intervals

       Please note that this is the data that will be gathered and stored
       by default. THIS IS CONFIGURABLE! Do you have a better plan for
       what data should be stored? Drop me a line...

     * Once in the RRD, the data is queriable by the lightweight
       interface, which will display a list of available interfaces, and
       upon selecting one, you'll be presented with a graph(s) that
       reflect the data stored.

     * Since the roll-up and archival of data is automatic within the
       RRD, the databases will never grow beyond their initial size. The
       databases, depending on the number of data points collected, will
       each be about 50K per data point, or 500-700K per each interface.

     * And since the underlying data source is open source as well, you
       can also use any of the existing RRDTool front-ends to view the
       data within. You can find a list at http://www.rrdtool.org/
       
     Cool? Yeah, we think so. RRDTool is a powerful thing.
     
Coding Projects Underway:
     
     * Solaris Port Postgres Procedures -- Underway. No update.
       Apparently discovery is working.

     * Postgres for NT -- No update since last week.

     * SNMP Poller/Data Collection -- The data collection work is done,
       now we're working on the interface to generate the reports.

     * Event DTD -- Finalized. Should be checked in soon.

     * Tuning -- Down to memory requirement of about 128MB for the core
       processes to run with no swapping. Plenty of other tweaks coming
       as Weave finishes this one up (again).

     * User Interfaces -- Making great progress!

     * SCM -- Gutting and replacing JSDT with an RPC mechanism. ACPL Tea,
       for those of you keeping score at home.

     * SCM UI -- Will have to be re-tooled for the SCM change, but many
       of the problems will be avoided, if not eliminated.

     * TCP Poller -- Still waiting for some of the creative
       configurations that I know you all are capable of...

     * 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 -- Works in the U/G/V config panel, but
       not the Wizard. We're disabling the Wizard until the functionality
       is there.
       

===================
Upcoming Road Shows
===================

   
   For the upcoming trip to Albuquerque and SLC, Steve will be making the
   trip.
   
     * February 15th - Utah JUG, Salt Lake City, UT
     * May 5th - Twin Cities LUG, Minneapolis, MN
       
   For additional details on these appearances and others, check out the
   web site at http://www.opennms.org/sections/opennms/events
   

==================
Web Site Questions
==================
   

   I've gotten a couple of notes this week that our web server has been
   painfully slow.
   
   We are unable to duplicate this in-house, and was wondering if any of
   the rest of you have noticed this or not. So far, the reports seem to
   lean toward a "works for me" resolution, but I want to give PF the
   benefit of the doubt.
   
   If you are having problems or noticing poor performance, please let
   Ben know at ben@opennms.org
   

=============
The Wish List
=============
   

   First, a big thanks to everyone that's actively working with and
   trying out the product. There are a lot of cool innovations committed
   recently that you'll want to take a look at as well. Again, our thanks
   to the testers!
   
   Now, on with the list...
   
     * Test the install.pl script!!!

     * Our SNMP Data Collector will rely on a configuration file,
       DataCollection.xml (or something like that). This file will map
       what SNMP OIDs we should pull from a device with a given SysOID.
       Now the question is, "What should we pull?" Recommendations? Tips?
       I figure we'll pre-populate some canned collections for Cisco
       routers, Bay routers, and whatever else can be contributed. All
       ideas are appreciated, and especially ideas that come back in the
       format of the DataCollection.xml file (available at:
       http://www.opennms.org/cgi-bin/cvsweb.cgi/data/common/conf/DataCol
       lection.xml )

     * Now that we have a "generic" TCP Poller, we could use some help in
       building some configurations to test services that you may be
       concerned with. For example, is LDAP do-able? How about
       applications like Peoplesoft, SAP, Baan? Remember, you can deploy
       multiple of these pollers against multiple ports.

     * 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!

     * Anybody up for a security analysis of OpenNMS? We know we've got a
       lot of holes, but we'd rather have most of them identified before
       we start trying to plug them. Any security folks that are playing
       along, feel free to chime in here. Anytime, now. Go on. Anytime...
       

=============
Afterthoughts
=============
   
   This is promising to be another week where it's suddenly Friday at 8pm
   and I wish days and weeks were longer, since I feel like I've gotten
   nothing done but wage senseless battles on email. I wish I could just
   let that stuff go, but alas...
   
   Our office is now officially full. We've got more people than desks,
   and still only one phone. Which gets interesting when Luke needs to
   fax, Larry needs to take a call from his wife, and Jason is trying to
   test paging notifications. You've heard of playing "King of the Hill"?
   Around here it's "King of the Dial-Tone".
   
   0.6 is everso rapidly approaching. We're on target for our Valentine's
   Day release, and there are enough new and interesting features that
   you are DEFINITELY going to want to take a look.
   
   We just crossed the 200 mark in bugs registered with Bugzilla. I don't
   know if this is a good sign or bad, but the good news is that the
   better part of them have been addressed.
   
   Going to be in Boston and want to meet Luke & I for a beer at the
   airport? Let me know. Luke's buyin'.

Shane O.
========
Shane O'Donnell
shaneo@opennms.org
http://www.opennms.org/
=======================
There are few things I
like better than being
generous with Luke's 
beer money.
=======================
_______________________________________________
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to:
http://www.opennms.org/mailman/listinfo/announce