![[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.14
Date: Tue, 3 Apr 2001 18:49:14 -0400 (EDT)
====================
OpenNMS Update
====================
Vol 2., Issue 14
====================
April 3, 2001
====================
In this week's installment...
* Project Status
+ Preparing 0.7.2
+ Event Configuration and Correlation
+ OpenNMS.jar Splits
+ SCM Changes
+ Critical Tomcat Problem
+ Coding Projects Underway
* Upcoming Road Shows
* Early Adopter Program Status
* The Wish List
==============
Project Status
==============
Preparing 0.7.2:
We still look like we're on target for a 0.7.2 release late this
week. We're especially excited about this release, as it includes
the first drop of some cool features, as well as the addition of
some features to other components that we find pretty nifty and are
sure you will too.
The current list of major features which will ship in 0.7.2
includes but is not limited to the following:
* Ability to monitor SNMP values for thresholds with the SNMP Poller
* Event configuration and correlation
* A re-work of the Notification System
* Ant 1.3 (for the build process)
* Updated RRDs with room for expansion (NOTE: "Expansion" of an RRD
is currently a misnomer. We are working around this, not fixing
it.)
* A new easy-to-use installer (a handy POSIX-shell script, served to
you neatly via "lynx -source". It's cool!)
* Tweaks/changes to the Web UI based on feedback from our EAP
partners.
* A suite of fixes/improvements to SCM
As you can tell, there is a LOT going on in this release, and
correspondingly, a lot of major components are being "touched". We
anticipate some problems, but we're not releasing an untested
monster to the masses. Most of the major changes (including the
event configuration/correlation and SCM changes) have been in
testing in house for a little while now and have been tweaked since
their initial commit. We know we have to improve past 0.7.1, and we
believe that 0.7.2 does that quite handily.
And late this week, you'll agree. We're counting on it.
Event Configuration/Correlation:
Many of you have asked for some more specifics on the changes to
the event subsystem that are coming in 0.7.2. If you'll indulge me
for a moment, please allow me to get technical for a moment.
"Event configuration" takes place when an event is received by
eventd. To date, the configuration is driven by eventd's ability to
match the Universal Event Identifier (UEI) of an event with a
configuration in the eventconf.xml file. This has worked quite well
and quite efficiently, but it's also rather limiting, since your
only qualification for applying a configuration is the UEI.
For example, if you have a backbone router and a workstation and
are polling them both for availability with the ICMP poller, if
either go down, the same event will be generated (Service Lost) for
either device, with parameters that associate that event with the
particular interface that failed the poll. And if you intend to
page someone if your core router goes down, you will need to
associate a notification configuration with the configuration of
the Service Lost event. But since it's the same event that's
generated in either case, you have had only three options for
notification:
* Page someone when EITHER the workstation or router go down
* Don't page anyone in either case
* Use an automated action to catch the event, parse the event XML to
see which device is associated with the event, and then page
accordingly.
Obviously, the first option is not acceptable, as the tech will be
getting so many pages that mean nothing that soon, all pages will
mean nothing. The second option only works if you have dedicated
personnel sitting and staring at an event browser all day (NOTE: If
you do, I'd like to talk to you about other creative ways we can
waste your personnel budget...) And the third option can become a
maintenance nightmare, let alone a hassle to set up in the first
place.
So, the new event configuration will take situations like this into
account. First, when the event is received, it will be compared
against a new eventconf.xml file which leverages the concept of an
event mask, or a configuration which identifies which fields should
be evaluated and the corresponding values which should be matched
in each field. So in our earlier example, our mask would basically
have eventd evaluate both the UEI and the INTERFACE "maskelements"
for the value of each, with a specific configuration (including
notification) added for the core router and a generic
configuration, perhaps that only checks the UEI, which would match
as the event "falls through" the eventconf.xml file.
If that was clear (and that is in question), you can begin to see
how we'll trigger our event correlation configurations as well.
With 0.7.2, our event correlation will consist of two correlation
"paths": suppressDuplicates, cancellingEvent, and suppressAndCancel.
With an eventconf.xml configuration entry, a tag can be configured,
which will identify not only the correlation path, but also the
additional behaviors to be associated with this correlation as
well. For example, the suppressDuplicates path can be configured
with minimum and maximum count values, as well as a duration timer,
which indicates not only how many events to suppress, but for what
period of time. In lieu of any major documentation to accompany
this release, any additional implementation of the event
correlation (as well as creation of the documentation), is left as
an exercise for the reader. And that would be you.
This release does NOT ship with any out-of-the-box configurations.
We're counting on a "if we build, they will come approach", in
which we provide you the flexibility to add some stuff like this in
and you provide us with the configurations that you build around
it. That way, everybody benefits. And we don't lose time trying to
dream up the ways in which you'll want to use this.
Hope this helps. I'll stop being faux technical now.
OpenNMS.jar Splits:
As it would turn out, it was only staying together for the kids.
With 0.7.2, the behemoth that was OpenNMS.jar will now exist as
multiple jar files, split up by basic functionality. Why the split?
Three reasons:
* It was necessary to facilitate the split out of the bootstrap and
SCM stuff (see following blurb)
* Provides better insights on component interdependencies in testing
* Irreconcilable differences
Anyway, where you formerly saw one big-ass jar file (NOTE: "Big
ass" is a technical term, best known as a unit of measure for a
ham.), you will now see the following:
* oncrpc.jar - ACPLT ONC RPC Classes
* opennms_bootstrap.jar - SCM Bootstrap Classes
* opennms_common.jar - common codebase (jcommon)
* opennms_distpoller.jar - distributed poller codebase
* opennms_eui.jar - End User Interface codebase
* opennms_helpview.jar - Helpviewer codebase
* opennms_native.jar - RRDTool JNI stuff
* opennms_rtc.jar - Swing UI/Real-Time Console
* opennms_scm.jar - Service Control Manager
* opennms_snmp.jar - JoeSNMP
* opennms_soap.jar - SOAP changes
* opennms_web.jar - Web UI
* opennms_report.jar - Reporting code
Theoretically, this will also help improve build times on upgrades,
as we'll only have to build what we need to build. Of course, this
is merely an opportunity that we have yet to capitalize on. For
now, we're going to build it all and you're going to like it.
SCM Changes:
A number of you have also either experienced difficulties with the
current SCM, or have asked about what's going to be included in the
changes for the latest release. If you fall into either of these
categories, this Bud's for you.
If you are familiar with the DTD for the scmconfig.xml file, you
will have noted that there was an element that's not being used:
<classpath>. Well, now it is. When Weave originally built the
config file, he was secretly planning to add in this flexibility
(as well as plotting big trouble for moose and squirrel). But we've
got an interesting little twist with how it is used. Any data that
we find in the <classpath> element is searched for anything formatted
with a ${...} style bracketing. If something like this is found, we
use the internal value as a property key and substitute in the
appropriate key value. Not only is that pretty slick, it's very
*nix-like, as well as behaving much like Ant.
But this classpath stuff is just indicative of the much larger SCM
changes. SCM has been re-constructed from the ground up,
particularly with regards to how it loads (all due to some goofy
problems we had with trying to manage the system classpath from
multiple fork/exec'ed Java processes). When initially invoked
(whether through the command line or the opennms init.d script),
SCM only references the opennms_bootstrap.jar file, and the
CLASSPATH variable gets exported so that the bootstrap jar is
available for all subsequent JVMs spun up. Once this class is
loaded, it then loads the RPCManager class, which is the guts of
SCM. This is the class that gets around to loading and parsing the
scmconfig.xml, which now contains the critical components to not
only start the processes associated with SCM in the right order,
but also in the right virtual machine, and if the machine ain't
loaded, it loads it and goes. Nothing like being self-sufficient, I
always say.
But this whole convoluted re-work is all due to JSDT's behavior in
service-to-service communications within the same VM. This split
should help. JSDT didn't necessarily handle its environment
the way we though it should, so we changed its environment. Bigger
hammer theory at work.
Anyway, if this hasn't either bored you to tears or put you to
sleep, consider yourself all the better for knowing. And knowing is
half the battle.
Go Joe!
Critical Tomcat Problem:
For those of you that monitor BUGTRAQ, you may have noted the
recent posting that revealed a security hole in Tomcat that may
allow users to see the source code of a Tomcat-hosted servlet.
After some research, our very own Larry K. has uncovered another
exploit that will reveal the source code of any servlet on an
OpenNMS platform:
# export CVSROOT=":pserver:anonymous@cvs.opennms.org:/usr/local/cvsroot/bluebird"
# cvs login
# cvs co opennms-all
Open Source Rocks!
Coding Projects Underway:
* CDP/L2/Mapping -- The Pete Siemsen show has begun and comments are
directed to the [discovery] list.
* Snort Integration -- No update
* 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.
* Testing on NT/2K -- Still hear lots of effort is going on here,
but haven't heard much in terms of details this week.
* SNMP Poller/Data Collection -- Thresholding is just about
there...Watch for 0.7.2
* Event DTD -- Testing. Frantically.
* User Interfaces -- When Larry's not hacking for servlet source,
he's changing the Web UI faster than Jeff can test it.
* New Pollers -- I've asked for two consecutive weeks if there's any
interest in CORBA and I've heard nothing. Is that your final
answer?
* 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. Promising code this
week.
* Discovery/CAPSD/Database Review -- Sowmya has inherited
"coalescence".
* 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 -- Jason has re-worked this with some new config
files. Nothing to report from testing yet.
* New Installer -- Final drop hits tonight. Testing all day
tomorrow. Hope for the best.
===================
Upcoming Road Shows
===================
Just got our speaking time for the O'Reilly Open Source Conference in
San Diego in July - Try to free yourselves up Wednesday morning at
10:45. If you can try to make it, I can try to be sober.
So, on with the road shows...
* May 5th - Twin Cities LUG, Minneapolis, MN
* May 10th - Boulder LUG, Boulder, CO
* June 1st - NOVALUG BBQ!! Fire-eaters Unite!!
* 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
* August 28-30 - Linux World Expo, San Francisco, 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
============================
Things are cooking along here. Jeff is still installing 0.7.1 and
planning the upgrade to 0.7.2, when it is available.
Most of the user feedback on the UI has been incorporated. We're
anxious to hear the response to 0.7.2.
That is all.
=============
The Wish List
=============
And in the end, the love you make is equal to the code you contribute.
And now, on with the list...
* In the 0.7.x release (and CVS), checkout the TODO file
* 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
=============
Thanks to everyone for their thoughts and opinions on what we should
do for a PBX. Current plan is to go with a modernized string and tin
cans approach, where the string has been replaced with optical fiber.
A stunning silence on CORBA management. Is there no interest, or is no
one reading this far in the Update?
I've updated the project timeline in the FAQ. Feel free to check it
out. I hope to be adding a complementary feature/function list to
accompany that timeline soon. Remember, soon is relative.
This Update, in retrospect, is decidedly more technical than most. Do
you prefer this, or would you rather have the business-level glossing
as to what we are doing? Lemme know.
If Ben's phone doesn't stop beeping, I'm going to kill somebody,
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