![[LWN Logo]](/images/lcorner.png) |
|
![[LWN.net]](/images/Included.png) |
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
me.)
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
Subject"
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
point.
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
attention.
* NT/2K Port -- No update. The concerns are still with some of our
dependencies.
* 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?
=============
Afterthoughts
=============
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
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