From:	 announce-admin@opennms.org
To:	 announce@opennms.org
Subject: [OpenNMS-Announce] OpenNMS Update v2.19
Date:	 Tue, 8 May 2001 22:51:24 -0400 (EDT)

====================
   OpenNMS Update
====================
  Vol 2., Issue 19
====================
    May 8, 2001
====================

   In this week's installment...
     * Project Status
          + Preparing for 0.7.5
          + Minimum System Requirements
          + Notification Revisited
          + Coding Projects Underway
     * Upcoming Road Shows
     * Early Adopter Program Status
     * The Wish List


==============
Project Status
==============

Preparing for 0.7.5:

     We are slowly but surely putting the wraps on OpenNMS release
     0.7.5. This release contains all of the original features in 0.7.4,
     some polishing of both those features and existing features, and a
     few new tweaks that make the product notably more usable.

     As has been the case for some time now, our user interface
     improvements have been focused on the Web UI. This release is no
     exception. Additionally, we've rolled in some enhancements and
     minor bug fixes, plus a brand spanking new reporting mechanism.

     Probably the most interesting and monumental change from a user's
     perspective will be the addition of our Web-based Event
     Configurator. While the documentation on how to use it is somewhat
     (read: totally) lacking, if you combine the discussion of the
     eventconf.xml available in the April 3rd Update
     (http://www.opennms.org/sections/updates/update0214.xml) with a
     little clicking, typing, and general intuitivity (is that a word?),
     you should figure things out pretty quickly. I should point out
     that Jason did a very nice job with this, especially since this 
     was a learning foray into the wierd and wonderful world of JSPs.

     We anticipate a release date of sometime later this week or early
     next week. As always, you can watch the web site for availability,
     as well as the Freshmeat newsletter (or you can subscribe to the
     project at Freshmeat, as well). We look forward to your feedback
     and results of your testing.

     So when it's available, enjoy 0.7.5 with our regards.



Minimum System Requirements:

     This question seems to come up on a pretty regular basis, and I was
     reminded at the Twin Cities LUG that this information was a glaring
     omission in my presentation. So I thought I'd take a moment and not
     only tell you what they are, but some of the reasons why they are
     reasonably vague.

     First, the current minimum system requirements are as follows:

     * 400Mhz Processor or Higher (assuming Intel or compatible)

     * 25MB Disk Space, under the /opt partition (for default
       installation destination), plus 5MB under /var/lib/pgsql/data for
       the PostgreSQL database, and 9MB per interface you wish to collect
       SNMP data from.

     * 256MB RAM

     Now let's discuss the problem with identifying system requirements
     for an application such as OpenNMS. There are four major factors
     which are going to drastically impact the performance and
     scalability or our application (and these are pretty generic and
     can be applied to any network management package providing similar
     functionalities):

     * Number of nodes being managed

     * Number of services per node being managed

     * Number of concurrent operators

     * Event load (Number of events received over some period)

     Given these variables (and these are pretty BIG variables), the
     sizing of your system could vary widely--anywhere from the numbers
     above to GBs of RAM, GBs of disk, and multiple processors. Consider
     this the ultimate "Your Mileage May Vary" statement.

     What would be ideal at this stage is that instead of having a
     stated "Minimum System Requirements", instead we provide a
     calculation or a multi-dimensional matrix of determining what your
     system size should be. However, until we get a little benchmarking
     information back from the world in general, we'd be hard-pressed to
     create such a thing. Consider this a call to action. Any help you
     can provide is certainly appreciated.



Notification Revisited:

     We've discussed how wonderful our notification subsystem is in
     previous updates (see
     http://www.opennms.org/sections/updates/update0215.xml), and we've
     even talked about where it gets invoked (eventconf.xml, see
     http://www.opennms.org/sections/updates/update0214.xml), so now,
     let's pull the covers back and see what's actually happening when
     we configure a notification, which for argument's sake is paging,
     emailing, or otherwise contacting someone when a particular event
     happens.

     At its simplest, the <notification> element in eventconf.xml is
     basically a hook to an exec() call, much like <autoaction> and
     <tticket>. So the challenge comes in what you can invoke at the
     command line to accomplish the task at hand.

     Given the freedom of assigning any command line command to a
     notification gives you two interesting options:

     * Integration with any tool that will allow you to do notifications
       from the command line, e.g., Telamon Telalert.

     * Don't use this element for notifications at all, but simply for
       another automated action. They both get parsed out and executed by
       OpenNMS.actiond in exactly the same way.

     Since we're talking about notification in the first place, let's
     ignore the second option for now.

     So at this point, we know where to fire off a notification from and
     how it gets invoked. The question now is: Who do I notify and how
     do I get a notification to them?

     If you take a look at the users.xml file and the groups.xml, you'll
     see the critical pieces. You can refer to the the OpenNMS Update
     v2.15 (see link above) for more details on how those files work
     together for the notification ordering and escalation. I won't
     re-hash that here.

     In v2.15, I did allude to the fact that we use QuickPage under the
     covers as our hook to TAP/IXO. I also kind of skated out without
     talking about the qpage integration. So first, my apologies. Now, a
     crack at how all that plays out.

     QuickPage (http://www.qpage.org) is pretty cool in its own right,
     and for what it is and what it does, it's pretty functional. We've
     actually replicated some of its functionality (specifically,
     groups) outside of QuickPage, simply because we felt we needed more
     granular control of how group notification and escalation worked.
     You can manually configure QuickPage to work around this, but we
     don't recommend it. Because we've abstracted groups from QuickPage,
     the QuickPage configuration file has no need to know about the
     groups.xml file, so it doesn't. However, the data that we've stored
     in the users.xml file is critical to QuickPage. In an effort to
     keep things reasonably straight-forward and to give you a headstart
     on QuickPage configuration, we've provided the qpage-cf-gen.pl
     script (under /opt/OpenNMS/bin) to convert our users.xml file to a
     mostly functional QuickPage config. The script, in its current
     form, requires that you have expat installed
     (http://expat.sourceforge.net), requires the XML::Parser Perl
     module (perl -MCPAN -e 'install XML::Parser;'), and only generates
     a fragment of the file. This is slowly improving, but will not be
     complete for 0.7.5. In the interim, run it after you've built your
     users in the OpenNMS Admin GUI, and the config file will be built
     and sent to standard out. Redirect it to a file, and as root, save
     that file to as /etc/qpage.cf. Now, you'll need to edit the file to
     provide the critical system-specific information it will need,
     including where the modem is located, local phone number, etc. But
     you should also note that all of the users will be built for you
     based on the information you provided when you entered them in
     OpenNMS.

     So once QuickPage gets set up and is functional (and you might want
     to try using the /usr/local/bin/qpage utility to test it out), now
     comes the challenge of invoking it when an event comes in.

     We're providing, in 0.7.5, a script that gets you through some of
     the hard parts of invoking our Notify code (as described in Update
     v2.15). This script is entitled, appropriately enough, notify.sh
     and is available in /opt/OpenNMS/bin. While this script does little
     other than to abstract the ugliness of command line invocation of
     Java with fully qualified class paths, it does that particularly
     well and is actually pretty clean to both use and remember what you
     were trying to do. Here's the breakdown on how to use it:

       ./notify.sh -d <notificationName> [-nm "Numeric Message"] [-tm \
        "Text Message"] [-subject "Subject Line"]

     The above "Usage" line merits some explanation, but it's pretty
     intuitive on its own. -d is the "destination", which maps directly
     to a <name> from the notifications.xml config file. Depending on
     your destination, you can send either a -tm text message (for
     alphanumeric pagers or email destinations, or an -nm numeric
     message, for numeric pagers. The idea is that you could include
     both of these, in case your destination includes a mixture of
     numeric and text destinations, and the correct message type will
     end up in the right place. Or at least that's the idea.

     The -subject tag is just that -- the subject line of an email
     message, which obviously is going to an "email" destination. This
     tag is optional, even if going to an email destination, and if it
     is omitted, the subject line will appear as "Notification #X",
     where the X is replaced with the notification ID, as stored in the
     database.

     Once you've configured your pages to be sent, your users can then
     use the Web UI to acknowledge that they've received the event. This
     acknowledgement will be recorded in the database, and once it is
     entered, the escalation process will be stopped. Thus, if you set
     up your notification groups with a manager-type getting notified at
     the end, you've not only taken steps to keep them informed, but
     you've motivated your users to actually get in and acknowledge
     their pages. That'll teach 'em to screw with you...

     So why all this on notification again? Two main reasons:

     * The recent addition of the notify.sh should help clean up this
       whole process for most of you (aside from the upcoming
       housecleaning for the whole QuickPage installation/configuration)
       and make it relatively usable.

     * We're looking for folks to step up and run this thing through its
       paces. Any help is most appreciated.

     So that's all on notification this time around. Stay tuned for
     upcoming information on the next iteration of the qpage-cf-gen.pl,
     unless of course someone wants to take that piece on as well. ;-)



Coding Projects Underway:

     * CDP/L2/Mapping -- Pete is alive and well and getting into CIM and
       DEN. Neat technologies that are dying for someone to implement
       them. Pete's the man!

     * Snort Integration -- The effort has stagnated and Matthew has been
       sidetracked with his new job (and training!!) with the Evil
       Empire. This is going on the back-burner, until someone wants to
       step up to this task (or Matthew gets out of class...)

     * Solaris Port -- We're starting to look for Sparc hardware that we
       can build/test on. Anybody willing to take this one on?

     * NT/2K Port -- No update. Evidently all the Microsofties out there
       are as scared of this one as we are...

     * SNMP Poller/Data Collection -- Some of the Cricket/MRTG users in
       Minnesota have offered up some of their configs, converted to
       DataCollection.xml format. I'll keep you posted on this one.

     * Logging (Conversion to Log4J) -- Seth has completed all all of
       Discovery and capsd, and will be proceeding (once his brain starts
       to function outside of a Log4J context again).

     * User Interfaces -- Jacinta's PDFs are being tweaked further to
       support not just textual report generation, but she's working on
       SVGs within the FOP stuff. Anybody out there done anything like
       this with Xalan? Want to make yourself available to help, answer
       questions, or do some testing?

     * Configuration -- Event Configurator en route.

     * Discovery/CAPSD/Database Review -- Some early "re-parenting" code
       is now in. To us, re-parenting is when you discover five
       individual interfaces that don't support SNMP, then later, when
       the device DOES support SNMP, we find out that all five are on the
       same node. Re-parenting is the process by which the interfaces get
       associated with the correct node.

     * Agent Technologies -- Agent effort still on ice while Craig does
       Scoreboard-related stuff.

     * Development Environment -- Ben is starting to work on Tinderbox
       and LXR again.


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

   In case you've never seen us live and in person, here's your chance:

     * May 10th - Boulder LUG, Boulder, CO
     * June 1st - GNU/Linux BBQ!! Drink good beer and eat fire.
     * June 2nd - Northern Virginia LUG (NOVALUG), Alexandria, VA
     * June 13-14 - OpenView Forum 2001, New Orleans, LA
     * July 25 - O'Reilly Open Source Convention, San Diego, CA
     * August 28-30 - Linux World Expo, San Francisco, CA (BOOTH)

   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 - Courtesy Jeff Schneider
======================================================

   Shane: It's quiet out there.
   Jeff: Yeah, almost _too_ quiet
   Shane: I'll send for reinforcements

   Well, we're in a waiting mode as some of our early adopters regroup
   and redeploy, some are in a "burn in" period, and still others are out
   having children.

   While we're waiting for the deluge that is no doubt on it's way, we've
   decided it's a good time to get another consultant involved, as some
   of you may have noticed in the last update.

   In the meantime we're evaluating the newest cool stuff that's coming
   our way, determining how it fits into some of the early adopter
   environments.

   + Tip of the Week: Admin vs. User logins +

     This seems to have been a point of confusion over the last couple
     of weeks.

     Although all logins for the "swing" GUI are through the same login
     prompt, logging in as admin is much different from logging in as a
     usual user.

     When logging in as administrator, a gui front-end for editing the
     configuration XML files. It does not have any interaction with the
     OpenNMS core processes.

     When logging in as any other user (or through the web UI) you are
     connecting to RTCViewCategory Manager. This is why we often see "I
     can log in as admin, but get errors that say RTCViewCategory
     Manager may not be running when I log in as any other user." The
     problem is usually that SCM has not been started.


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

   And now, on with the list...

     * Rewrite the Quick Start guide so it's up to date.
     * In the 0.7.x release (and CVS), checkout the TODO file
     * Testing on notification. See above.
     * New Data Collection configs wanted for the DataCollection.xml
     * Build some event configurations.
     * Any interest in more TCP pollers? Let us know (or better yet,
       build one yourself...)
     * LDAP/POP3/nmap Pollers
     * 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.
     * 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?
     * Got an environment that could stress test OpenNMS, from a
       scalability perspective? We'd love the feedback!


=============
Afterthoughts
=============

   Last week to the Twin Cities (Minn/St. Paul) LUG was a blast. Not only
   did I get to meet Bob Tanner (although he sandbagged on me and was
   sniping from the audience before he introduced himself), but the crowd
   was pretty well populated with folks familiar with open source network
   management technologies, including Cricket, MRTG, RRDTool, Scotty,
   fping, and arpwatch. Cool! Got lots of good questions and great
   feedback. Look for some of the features we discussed coming sooner
   than later... Big thanks to Amy for the invite and setting up the
   meeting.

   Surprisingly, I also got someone to take me up on my "Available for
   Dinner" offer. This time around, it was mailing list lurker and
   network management consultant Chuck Craft. It's great to talk tech
   with somebody that knows their stuff, and Chuck certainly fills that
   bill. And it's even better when there's plenty of beer around...

   This week, we're off to the Boulder LUG. I'm planning to hook up with
   Pete Siemsen (CDP/L2 man) and Rick Casey (Events and Maji implementer,
   turned serious grad student) while I'm out there. We've also got an
   early adopter in that neck of the woods I might try to hunt up.  And
   I believe that good folks at LWN (http://lwn.net) are out that way too.
   It'd be nice to put faces with names, kids.  I'll buy the beer?

   A note of apology to everyone, including Jeff Schneider, that read
   into last week's job posting that Jeff had gone elsewhere. He hasn't,
   and as a matter of fact, is starting to gear up for the upcoming
   announcement of professional services and support available for
   OpenNMS. But there will be MUCH more on that later.

   In regards to the job posting, my thanks to everyone that expressed an
   interest. We've made an offer and it has been accepted, so the
   position has been filled, and we're excited about the experience that
   our newest newbie brings to the table--but more on that next week.

   And as for me, put a fork in me 'cuz I am done!
_______________________________________________
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to:
http://www.opennms.org/mailman/listinfo/announce