[LWN Logo]
From: announce-admin@opennms.org
To: announce@opennms.org
Subject: [OpenNMS-Announce] OpenNMS Update v2.15
Date: Tue, 10 Apr 2001 18:52:48 -0400 (EDT)

   OpenNMS Update
  Vol 2., Issue 15
   April 10, 2001

   In this week's installment...
     * Project Status
          + 0.7.2 Released
          + Web UI Authentication Problems in 0.7.2
          + Notification Configuration
          + Coding Projects Underway
     * Upcoming Road Shows
     * Early Adopter Program Status
     * The Wish List

Project Status

0.7.2 Released:

     The final release was prepared and the RPMs available on Friday, on
     target and as planned. This release should be pretty compelling for
     most users and should justify an immediate upgrade, given some of
     the features that we've packed in:

     * SNMP Thresholding (new config format in DataCollection.xml
       provides example of Cisco Router CPU thresholding)

     * Detailed event configuration (see eventconf.xml)

     * Basic event correlation (see eventconf.xml)

     * An Overhaul of the Notification System (discussed below)

     * Ant 1.3 (for the build process)

     * RRDs created to allow for adding "expansion" data, as well as
       storing more data overall.

     * A Lynx-based installer

     * Changes to the Web UI

     * A suite of fixes/improvements to SCM

     If you haven't yet done the upgrade, try it. You can use the new
     installer, whether it's an upgrade or a new install, just type:

           lynx -source install.opennms.org | sh

     as root and you should be up and running in no time flat. And if
     you get errors, take 'em to the [discuss] list, where the whole
     team is hangin' out, waiting for something to fix...

     0.7.2 -- enjoy, with our compliments.

Web UI Authentication Problems in 0.7.2:

     Currently, it appears that there may be some issues with upgrading,
     in terms of authentication via the Web UI. Here's the scoop:

     Within the server.xml file (/var/tomcat4/conf/server.xml, usually),
     we used to provide a path to the users.xml
     (data/common/conf/users.xml, under your $BB_HOME directory, which
     contains user IDs and passwords) within the "opennms" context for
     Tomcat. We've now changed this to be relative to $BB_HOME, rather
     than hard-coded, but the change isn't always getting made (why? got

     Anyway, if you are having authentication problems in the Web UI,
     check this out, and the full explanation and answer are available
     in the FAQ at: http://www.opennms.org/cgi-bin/fom?file=45

Notification Configuration:

     As referenced above, the notification sub-system (or "Jason's
     notification subsystem", as we refer to it around here) got a
     serious overhaul over the past few weeks to make it a little more
     feature-rich, and usable. Here are the highlights that you need
     before we get into the configuration part:

     * OpenNMS notification relies, by default, on qpage under the
       covers. You can invoke qpage natively, but we provide some
       additional functionality on top of it.

     * If you have another notification tool you prefer, you can
       configure our notification to use it instead. Our only real
       constraint is that it be invokable from the command line.

     * We provide a mechanism to basically handle multiple users, groups,
       and notification techniques within the same notification.

     * We will provide some configuration tools for the whole thing, but
       right now, it's all XML. That's why we're explaining it.

     * This whole thing was done with the idea that you'll eventually
       invoke notification from the <notification> tags in the eventconf,
       but you can invoke it from wherever the hell you want. Currently,
       there are some issues with how our exec is handling quoted
       strings, but the fix for that will be in shortly.

     OK. So here is how it plays out:

     There are four key configuration files that the notification
     subsystem relies upon, all under $BB_HOME/data/common/conf:

     * eventconf.xml

       This is the file that allows you to configure the notification to
       happen based on receipt of an event.

     * users.xml

       This is the file that contains a user's ID and their email
       address. The user's ID is going to be a key for us in the other
       files, and the email address is simply going to be read in, in
       case our notification is to go out via email.

     * notifications.xml

       This is where we build and name our groups, specify the amount of
       time between outbound notifications (so that we can allow people
       to respond before they are "escalated"), and identify what system
       we are going to use to send the notification (email vs. text pager
       vs. numeric pager).

     * notificationCommands.xml

       This file is pretty utilitarian and likely won't need to be
       touched unless you decide to use a different tool (other than
       /bin/mail or qpage) for notification. The structure is pretty
       neat, and it provides a cool layer of abstraction, but for most,
       it works and you won't have to mess with it...

     So how does it work? Assuming that you're integrating notification
     with the event subsystem (as most will, we assume), this is the
     basic flow:

     An event is received and eventd will configure it with the
     appropriate configuration from eventconf.xml. When it gets handed
     to actiond, actiond will see that there is a configured
     <notification> element. This means that whatever is contained in
     the element will be executed on the command line. Here you have
     some flexibility on what you can pass, as in the eventconf.xml, you
     can specify some of the event expansion so you can send a
     meaningful message with text from the event, as opposed to having
     to try to hard code everything. Which would suck. But I digress...

     When actiond execs the command line, it will need to look something
     like this:

     $JAVA_HOME/java $CLASSPATH org.opennms.bb.dp.notification.Notify -d
     testNotification -tm "This is a text message" -subject "An Email

     There are currently some issues with how options are being passed,
     specifically surrounding the quoted strings, but for argument's
     sake, let's say this works...here's what happens next:

     When Notify gets run, the parms get read in off the command line.
     The -d indicates the destination--the logical "group" of users
     we've built in the notifications.xml file, which is identified by
     the <notification> tags. This "group", identified by the <name>
     tags, can include multiple "targets", which can be either users
     (from the users.xml file) or other notification destinations, which
     gives you the ability to nest "groups" in one another. Each
     notification can also be assigned an interval, which is the period
     of time that each notification thread should wait until it contacts
     the next target in the list. Note that there is a default of 10
     minutes if nothing is specified, and that if you nest
     notifications, each notification will adhere to its own interval if
     specified, but becomes its own thread and will escalate within
     itself while escalation occurs in parallel in the parent
     notification. I think we could handle an example now...

     Let's say our notifications.xml file contains two notifications,
     one called "parent" and one called "child". "parent" has an
     interval of 5 minutes (5m) and four targets:

     * user1 with a command of "email"

     * user2 with a command of "textService"

     * child

     * user3 with a command of "numericService"

     "child" has an interval of 1 minute and three targets:

     * childuser1 with a command of "textService"

     * childuser2 with a command of "email"

     * childuser1 with a command of "numericService"

       Note that childuser1 appears twice.

     You may at this point want to start drawing yourself a picture...

     When we invoke a notification of "parent", here's how things will
     happen. A list of targets will be calculated, which will basically
     be a positional list of all targets identified--user1, user2,
     childuser1, childuser2, childuser1, and user3. The notification
     will go to user1 via email. The command "email" will then be
     compared against the notificationCommands.xml file to determine
     what command line should be invoked to send an email, and what
     option substitutions should be made. Remember, this is done so that
     there is a layer of abstraction between us and the underlying
     notification subsystem. users.xml will provide the email address
     and notificationCommands.xml will then provide the mapping between
     "email" and /bin/mail, mapping the -subject parm which we use to
     the -s parm that /bin/mail expects, and our other parms will be
     swallowed and not passed to the command line.

     After we wait our interval, in this case 5 minutes, user2 will be
     notified via "textService", which notificationCommands.xml maps to
     our installation of qpage and the service information is pulled
     from users.xml. And again we wait another interval. Also note that
     via the Web UI, you can cancel this escalation process at any

     Next, we reach the "child" target, which is listed as a type
     "notif". This provides us enough information to know that it is a
     subgroup to parent and it should be handled on a new thread. So a
     new thread is spun up to handle all of the members of the "child"
     notification, and the interval is set to one minute for this
     thread. So the original thread now begins waiting its five minute
     interval before it moves on to user3 and independently, the "child"
     thread begins its notifications once a minute.

     Without going through the rest of the process, here are the
     critical pieces you need to note. Over the next three minutes, the
     three targets within child will be notified, and note that despite
     the same user name, the difference in the command on the two
     entries for childuser1 will make those independent notifications.
     As far as that goes, even if they had been the same, they would
     have been handled as unique notifications. Just note that the same
     user can appear multiple times in a group. Then, two minutes after
     the last notification in "child", the last notification in "parent"
     happens--because of the threading, their timers will overlap.

     Hopefully, the detail didn't bore you, but the critical piece to
     note is that there is a lot flexibility and power here, but you
     need to know how the inter-relations between config files works, as
     well as how the timing of nested notifications works too. You can
     get pretty complex with how your own notification schemes will
     work, so use these examples as a base to work from and let us know
     how complicated you make things.

     I noted earlier that we were having some problems with how the
     quoted strings are being passed via the exec. If you can figure out
     how to make this work, please let us know. We appreciate your help.

Coding Projects Underway:

     * CDP/L2/Mapping -- The Pete Siemsen show has begun and comments are
       directed to the [disc] (discovery, not discuss) list.

     * Snort Integration -- Matthew's new job is obviously taking more
       time than he anticipated.

     * Solaris Port -- If you didn't see a whole butt-load of information
       on this on the [discuss] list this week, you just weren't paying

     * NT/2K Port -- No update. The concerns are still with some of our

     * SNMP Poller/Data Collection -- Thresholding is in.

     * Event DTD -- Stable. For now.

     * User Interfaces -- Working on an advanced event display mechanism.
       Details to follow.

     * New Pollers -- No interest in CORBA.

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

     * Configuration -- Trading emails with a faithful member of the
       mailing list interested in perhaps open sourcing some libraries to
       aid in our configuration management processes. Haven't gotten the
       code yet.

     * Discovery/CAPSD/Database Review -- Sowmya has inherited
       "coalescence" and Mike's working on the re-scan.

     * Agent Technologies -- Nothing to report. We're assuming progress
       is continuing on schedule.

     * Reporting -- Jacinta is hacking something up and Larry is XSLTing
       it to display in the Web UI. Looks promising, with PDFs right
       around the corner.

     * Notification -- Details above.

     * New Installer -- Looking for feedback...

Upcoming Road Shows

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

     * May 5th - Twin Cities LUG, Minneapolis, MN

     * May 10th - Boulder LUG, Boulder, CO

     * June 1st - NOVALUG 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

   Effective this week, Dr. Jeffrey Schneider is taking over this
   section, much as he has taken over the EAP. Thanks, Jeff!

   The Early Adopter's program is starting the 0.7.2 rollout. The first
   install is up and running, and we're waiting to hear feedback.

   We're getting ready to start implementing the newest version of the
   notification feature in the wild, and are anxiously awaiting reports
   of paging services being overrun with traffic.

   Next week we should have more to say as we report all the flowers and
   letters telling us what a great product 0.7.2 is.

The Wish List

   And now, on with the list...

     * In the 0.7.x release (and CVS), checkout the TODO file

     * Testing on notification

     * New Data Collection configs wanted for the DataCollection.xml

     * Build some event configurations, you slackers!

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


   After the notification stuff above, my brain hurts.

   I keep hearing about an IEEE conference on network management that has
   an opportunity for presentations on open source tools.  Anybody going?
   Anybody want to do an OpenNMS presentation?

   See you next week.

Shane O.
Shane O'Donnell
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to: