![[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.23
Date: Tue, 5 Jun 2001 22:44:03 -0400 (EDT)
====================
OpenNMS Update
====================
Vol 2., Issue 23
====================
June 5, 2001
====================
In this week's installment...
* Project Status
+ Prepping for 0.7.6
+ Early Adopter Program Back in Swing
+ Managing CAPSD
+ Coding Projects Underway
* Upcoming Road Shows
* Early Adopter Program Status
* The Wish List
==============
Project Status
==============
Prepping for 0.7.6:
As the number of minor fixes has grown, and some additional
functionality has been rolled in, we're about to package, release,
and announce OpenNMS 0.7.6.
We're going to classify 0.7.6 as a minor bug-fix, minor feature
enhancement release, and the only real reason for its existence is
that there are some kinda cool things in CVS that we'd like to get
tested prior to 0.8.0.
"What might those be?", you ask? Well the short list includes:
* A DHCP poller, and a corresponding isDHCP service.
* An SMB/NetBIOS poller, and a corresponding isSMB service (for the
M$-dependent amongst us)
* Many SCM updates/fixes.
* HTTP poller tweaks/tunes/fixes.
* Significant WebUI feature enhancements and bug fixes.
* A completion of migration to Log4J
Current plans are to package and test late this week and likely
release over the weekend or Monday.
As always, enjoy, with our compliments.
Early Adopter Program Back in Swing:
As Jeff will attest later in this very missive, the Early Adopters
Program is again nearing full-bore. This pass will bring all Early
Adopters up to the latest 0.7.x release (yes, we have some
installed that are not quite there yet...)
With remote access requests pending for some and human cycles being
limited for others, we are also in the process of weeding out the
ranks, which may mean some additional spots for other interested
folks. So if you are interested and want to capitalize on the
business decisions/misfortunes of others, feel free to bounce on
over to our signup page at
http://www.opennms.org/sections/get_involved/eap
We will only have, at best, limited availability and will be
selecting new EAP members based on the types and numbers of devices
in their respective networks. We try to keep the program balanced
with both large and small environments, and we'll continue to
maintain that balance.
Thanks again to everyone currently in the program and thanks in
advance to everyone interested in participating in the future.
Managing CAPSD:
For the uninitiated, OpenNMS goes through a few little gyrations
when it first comes up and starts cooking on your network:
* It takes a look at the local config files to determine what IP
addresses and ranges you have configured it to be responsible for
monitoring
* It compares a complete list of all possible interfaces in this
list to the interfaces it already knows about (previously
discovered interfaces in the database)
* A list of "new" interfaces is built by the discovery process which
will then embark on a journey through the list and will attempt to
"ping" each of the addresses
* For addresses that respond to a "ping", an event is generated,
known affectionately as the "Suspect Node Event", which CAPSD (the
Capabilities Checking Daemon) is listening for.
* CAPSD, upon receiving the event, notes which node is considered
"suspect" and schedules it for a capabilities check.
* When it's time arrives, the node is then scanned for the services
currently configured in data/common/conf/services.xml and if they
are discovered, the interface is flagged in the database as
supporting these services.
This presents several interesting possibilities. First off, what
happens if a device is behind a firewall (or some packet filtering
device) that prevents a "ping" from being successful? Will we ever
discover it?
And even more interesting, and surprisingly common, what if the
device is rather "finicky" about the traffic it wants to receive?
For example, what if the the device suffers from the "spinning
ifTable" problem (e.g., where you walk the ifTable and when you get
to the end, the GET-NEXT returns the OID for the top of the table,
thus creating an infinite loop)? What if all of your user
authentications are handled via some centralized mechanism (via
LDAP, for example), and when an SSH session is requested (as is
done by our OpenSSH poller) it fires up the authentication server,
which is left hanging when we don't try to log in. Oh, and by the
way, once successfully receiving the banner we expected, we've
moved on to the next box and have replicated that behavior, leaving
the authentication server to handle potentially hundreds of
requests, each of which are left hanging.
What DO we do?
In an effort to address these situations, Mike (the Good Mike, that
is), recently added a new configuration file that CAPSD reads prior
to initiating any capability checks that allows us to manipulate
the behavior of the CAPSD plug-ins. He also cleverly called it the
CapsdPluginBehavior.xml, and like the rest of our config files, it
is stored in data/common/conf.
The CapsdPluginBehavior.xml file consists of a few basic sections:
* The file's DTD
* A generic "header"
* A series of "behavior" elements, each of which include:
+ A "type" attribute (one per "behavior"), which can be either
"explicit" or "implicit"
+ An IP address ("specific") or IP address range ("range")
+ A list of one or more CAPSD plug-ins that this behavior is to
effect
So let's go right to an example of how we might use this. Let's
say, that we've got a particular node (1.2.3.4) that has our
"spinning ifTable" problem and we know it going in (I didn't say
this had to be realistic...). So the behavior we are really looking
for is to force CAPSD to explicitly NOT check for SNMP on the node
(since we try to walk the ifTable as part of our capabilities
check). What do we build into this file to make it happen?
We already know all of the key information we need to to make this
work: what node, what plug-in, and how we want CAPSD to behave. So
let's look at the construct that solves this dilemma.
<behavior type="explicit">
<specific>
<address>1.2.3.4</address>
</specific>
<plugins>
<plugin scan="no">SNMP</plugin>
</plugins>
</behavior>
What we have here is an exercise in logic. We determine that we
want to affect CAPSD's behavior for the interface listed within,
and we want that behavior to be reflected by all plug-ins
explicitly listed in the plugins element, thus the type="explicit".
And for the "specific" interface we reference, 1.2.3.4, we want to
NOT SCAN (scan="no") this device for the SNMP service.
Pretty straight-forward (with the exception that the "type"
attribute seems like it should be associated with the <plugins>
element, but we'll get past that for now and look at the resultant
behavior).
The important thing to note is that all of the power of this file
lies in the attributes of the elements. And since there are only
two attributes to worry about, we need only discuss them in depth
(as the rest are pretty self-defining).
The "type" attribute on the behavior element provides two options:
implicit or explicit. A value of "explicit" means that the plugins
listed in the ensuing plugins element will be acted on, and only
those listed. "implicit" means that all other registered plugins
will be acted on, and NOT those listed. So if we had listed all of
the services aside from SNMP and switched the attribute to
"implicit", we would've ended up with the same result.
Now the real power, and in turn, the confusion. The "scan"
attribute on the plugin element has three potential values: yes,
no, and bypass. If the attribute value is "yes", CAPSD will scan
only the plugins listed and no others. If the value is "no", CAPSD
will specifically NOT scan the plugins listed and in turn, not flag
the service as supported.
But an interesting value is "bypass". Using this value for the scan
attribute, you can force CAPSD to ignore the testing of the
service, but flag it as supported nonetheless, from a database
perspective. This allows you to get past test that CAPSD might
performing that could be detrimental to a remote device, yet still
allow you to poll the device, as it's flagged as supporting the
service in the database.
So with this combination of attributes, elements, and the existence
of the file in the first place, you should now have a means of
controlling some of the more subtle behaviors of CAPSD. And now you
know.
And knowing is half the battle. Go Joe!
Coding Projects Underway:
* CDP/L2/Mapping -- Pete is alive and kicking and actively looking
for someone in the Boulder, CO area to do some part-time work on
this, perhaps even for pay. If you are a Java/Linux/Network-type
in that area and are looking for a part-time gig for the next year
or so, drop me a line and I'll get you in touch with Pete.
* Snort Integration -- With the IDMEF output plug-in announcement,
it seems our work should be minimal. Still looking for someone to
do this minimal work.
* Solaris Port -- Fred Reimer has offered up his hardware and
assistance to get OpenNMS up and running on a Sparc box. Thanks,
Fred!
* NT/2K Port -- Weave is looking for someone to help with
autoconf/automake-ing the new ICMPD, and part of this effort will
eventually lead to getting it built for Win32. Any takers?
* SNMP Poller/Data Collection -- Evidently, no one has ever
collected data via SNMP. Ever.
* Logging (Conversion to Log4J) -- Complete.
* User Interfaces -- Larry, Jacinta, and Jason are wailing on the
interfaces. Looking good!
* Configuration -- Any feedback on the event configurator?
* New Pollers/Plug-Ins -- SMB and DHCP are in for 0.7.6.
* Agent Technologies -- We have two efforts at play here. Craig is
looking for someone to hand his Jabber-based agent architecture
off to, and I'd like to talk to anyone interested in building out
a compatible interface to allow us to use the NetSaint agents.
Anyone out there familiar enough to help here?
* Bug Fixing, RTC-Style -- We are digging in to RTC to validate that
the right data is getting to the right place at the right time. If
you see any circumstances where the total number of Outages and
the Category information doesn't jibe, please let us know. If this
doesn't make sense, drop me an email.
===================
Upcoming Road Shows
===================
Between Karl's cookin' and Chuck's beer, the rain didn't really matter
much. Thanks to the GNU/Linux BBQ folks for your hospitality and good
company!
* 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
* October 30-November 1 (UNCONFIRMED) - Linux World Expo, Frankfurt,
Germany
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
======================================================
This week we started the process of upgrading eveyone to the "latest
and greatest" version of OpenNMS. Of course, this was also the day
Shane again said "Hey, new release by the end of the week." Sigh.
We should have two of the Early Adopters working with the "latest and
greatest" by the end of next week. Both of these will be on RedHat
7.0, but we'll be upgrading our friends on Debian quickly enough.
* Tip Of The Week *
One thing that can get confusing is the difference between polling
packages and views.
It's important to remember that views dictate how you see the
information from your network. You can get as granular as "show me
the SNMP availability for the printers in my Dallas office" if you
can create the rules correctly.
Of course, it's useful if you have a configuration "package" that
happens to check the SNMP availability of the printers in the
Dallas office.
Packages include two things. First, which nodes get discovered.
Second, what services are polled for each node or groups of nodes.
For instance, "Check the availability of HTTP for all existing
nodes between and including 192.168.0.1 and 192.168.0.10."
Multiple polling packages may be used (but remember to update the
poller to include all the packages). The results from all polling
packages are evaluated by the view rules and the appropriate data
is then presented to the user.
So it's fair to think of it like this: packages get data INTO the
database, while views get data OUT of the database. And the data
must first get in, before it can get out.
Good luck, and until next week -- EAP members, I'll be in touch!
=============
The Wish List
=============
And now, on with the list...
* We need someone to "autoconf" the ICMPD build.
* Stefan Wasilewski has bellied up to the DEB-building bar. I'm sure
he'd appreciate your help.
* Our new ICMPD needs to be compiled for Win32. Got an appropriate
environment that you can help?
* In the 0.7.5 release (and CVS), checkout the TODO file
* Any progress reports on testing notifications?
* New Data Collection configs wanted for the DataCollection.xml
* Any interest in more TCP pollers? Let us know (or better yet,
build one yourself...)
* Want to build some bridges between NetSaint and OpenNMS?
* 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
It's late and I'm still catching up on sleep from the big GNU/Linux
BBQ and NOVALUG weekend! Thus, I'll be brief.
In deference to both personal safety and public mockery, Jason has
disassembled his loft and now sleeps a far healthier six inches off
the floor.
Yes, I know I sent five copies of the same email to the [discuss] list
this week. It was a combination email client/stupid user error. So sue
me.
Anybody going to be in N'awlins next week? I'm on a short schedule, so
let me know now if you want to hook up. See you there!
<< Previous Issue || Latest Issue || At Last Issue >>
_________________________________________________________________
Copyright © 1999-2001 PlatformWorks, Inc. OpenNMS.org is a project
supported by PlatformWorks, Inc.
--
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