OpenNMS® Release Notes
Information About OpenNMS Release 1.2.9-1
OpenNMS Development TeamTarus Balog <tarus@opennms.org>Matt Brozowski <brozow@opennms.org>David Hustace <david@opennms.org>Ben Reed <ben@opennms.org>
OpenNMS® Release Notes: Information About OpenNMS Release 1.2.9-1
by OpenNMS Development Team, Tarus Balog, Matt Brozowski, David Hustace, and Ben Reed
Copyright © 2004-2005 The OpenNMS Group, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and with no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html

OpenNMS® Release Notes

OpenNMS® Release Notes

Table of Contents
Preface
1. Introduction
2. What's New?
Changes in OpenNMS 1.2.9
New Features
Bug Fixes
Changes in OpenNMS 1.2.8
New Features
Bug Fixes
Changes in OpenNMS 1.2.7
Bug Fixes
Changes in OpenNMS 1.2.6
New Features
Bug Fixes
Changes in OpenNMS 1.2.5
New Features
Bug Fixes
Changes in OpenNMS 1.2.4
New Features
Bug Fixes
Configuration Changes
Changes in OpenNMS 1.2.3
New Features
Bug Fixes
Changes in OpenNMS 1.2.2
Changes in OpenNMS 1.2.1
New Features
Bug Fixes
Changes in OpenNMS 1.2.0
Changes in OpenNMS 1.1.5
Changes in OpenNMS 1.1.4
Changes in OpenNMS 1.1.3 and above
Changes in OpenNMS 1.1.2 and Above
Changes in OpenNMS 1.1.1 and Above
Changes in OpenNMS 1.1.0 and Above
Changes in OpenNMS 1.0.0 and Above
3. Known Issues and Caveats
Notes About Java Version
Notes About Tomcat Version
Invalid Symbolic Link on Some Distros
The Installer is No Longer Automatic as of 1.1.5
Special Note for KSC Report Users
Necessary Changes to Tomcat for 1.1.4 for Upgrades
New Requirements for Tomcat and PostgreSQL
4. Supported Systems
Fully Supported
Unsupported

Preface

Preface

Preface
OpenNMS is the creation of numerous people and organizations, operating under the umbrella of the OpenNMS project. The original code base was developed and published under the GPL by the Oculan Corporation until 2002, when the project administration was passed on to Tarus Balog.
The current corporate sponsor of OpenNMS is The OpenNMS Group, which also owns the OpenNMS trademark.
OpenNMS is a derivative work, containing both original code, included code and modified code that was published under the GNU General Public License. Please see the source for detailed copyright notices, but some notable copyright owners are listed below:
•
Copyright © 2002-2005 The OpenNMS Group, Inc. [http://www.opennms.com].
•
Original code base for OpenNMS version 1.0.0 Copyright © 1999-2001 Oculan Corporation [http://www.oculan.com].
•
Mapping code Copyright © 2003 Networked Knowledge Systems, Inc [http://www.nksi.com].
•
ScriptD code Copyright © 2003 Tavve Software Company [http://www.tavve.com].
Please send any omissions or corrections to this document to Tarus Balog [mailto:tarus@opennms.org]

Introduction

Introduction

Chapter 1. Introduction
About This Release
1.2.9 is a bug fix release along with a few new small features. There are some instances on large systems where OpenNMS will be waiting for PostgreSQL while PostgreSQL will be waiting for OpenNMS. This has been fixed. Small improvements have been made to KSC reports and to the General Purpose monitor to make them both more flexible. The code word for 1.2.9 is "floss".
OpenNMS 1.2.8 contains a number of new features, most back-ported from the development version of OpenNMS. These include Nagios support, the "zoom" feature from Cacti and support for Tomcat 5. None of these features resulted in code changes to the main part of OpenNMS, so the stability of the production release should not be impacted. Numerous bug fixes, however, do add to the stability of this release, and it is recommended that all users of OpenNMS 1.2.x upgrade.
The code word for 1.2.8 is "galsteed".
Before 1.2.6 had time to really get out there, an issue was discovered with using the new SNMPv1 and SNMPv2 services. This was corrected, and since 1.2.6 had not been formally released, but had been tagged, the fixed release was labeled 1.2.7.
The code word for 1.2.7 is "birdshot".
OpenNMS 1.2.6 is another release in the stable, or production, branch of OpenNMS. It fixes at least one annoying bug and adds a number of new features designed to increase usability, speed and functionality.
The code word for 1.2.6 is "geneva".
Release 1.2.5 is a maintenance release for the stable branch of OpenNMS. It includes a fix for the "opennms status", "opennms stop", and "opennms restart" commands being broken when using Java 5.0 due to a problem with getting status information from the running OpenNMS daemon. Users will need to re-install the etc/service-configuration.xml file due to some changed class names inside of MX4J. See Bug #1330.
Release 1.2.5 is an important maintenance release for the stable branch of OpenNMS. It includes a major bug fix concerning possible polling deadlocks that can cause outages that are never resolved, as well as a large improvement to SNMP data collection speed and startup time.
The code word for 1.2.5 is "gromit".
Release 1.2.4 is yet another maintenance release for OpenNMS. It includes a few minor bug fixes, some new configurations, and a couple of small features.
The code word for 1.2.4 is "wootness".
Release 1.2.3 is another maintenance release in the OpenNMS stable branch. It addresses a polling issue that may cause polling to stop, as well as adding a final version of the poll-outages calendar. Also included are a number of new events and reports.
The code word for 1.2.3 is "sith".
Release 1.2.2 is 1.2.1 with one annoying webUI bug fixed.
Release 1.2.1 is a maintenance release in the OpenNMS stable branch. It contains a few bug fixes and several small features. "Stable" releases may contain new features, as long as it is determined that they pose a very small risk to current features. Usually, these features will add new functionality without modifying existing feature behavior.
The code word for 1.2.1 is "luckycharms".
Release 1.2.0 is the first stable, or production, release of OpenNMS in a long time. It is basically 1.1.5 with numerous bug fixes. With the release of 1.2.0, we will begin development on 1.3 - the next unstable release.
The code word for 1.2.0 is "valentine".
Release 1.1.5 is the second release candidate for 1.2. The biggest change involves poller code that has been nearly rewritten. This was in response to a new feature concerning notifications, and while we believe it to be very robust, it does represent a lot of code churn, so if you are using 1.1.4 in production, you may wish to wait a bit before upgrading to 1.1.5.
Also, with this version of the release notes, we are implementing a "code word". We try to make these notes useful, including tips on the majority of issues people will face while using the application, but still people tend to skip reading them. So now, if you want to post a 1.1.5-related question on the mailing lists, be sure to include the code word so people will know you have at least read this far into the release notes (grin).
The code word for 1.1.5 is "monsoon".
A quick summary of the new changes in 1.1.5, in no particular order:
•
New notification behavior - users can configure OpenNMS to send notices when an event is auto-acknowledged by notifd and they will only be sent to those people who received notice of the outage in the first place.
•
A new RADIUS poller
•
A number of new event definitions, including those from NetBotz, PATROL, Network Appliance and others.
•
Reorganized the datacollection-config.xml and snmp-graph.properties files to make them easier to manage. Also added a really cool CPU report for Net-SNMP agents.
•
KSC Reports can now be accessed from the main page.
•
Removed the need for a primary SNMP interface (i.e. the ability to map an ifIndex to an IP Address in the ipAddrTable. This will help with data collection from some devices.
•
Added database support for the ifAlias field.
•
Added a MATCH-ANY-UEI event. Useful in notifications, this event will cause a notification on any UEI. Now, for example, all events from a particular IP Address or Node can be sent as notifications.
There were also a large number of bug fixes and other small enhancements made to the code. Please test the heck out of this release and be sure to add issues to bugzilla (http://bugzilla.opennms.org) and we'll get 1.2.0 out as soon as possible.
Release 1.1.4 is the release candidate for 1.2 - the next stable branch of OpenNMS. It represents a tremendous amount of work in the areas of speed and performance. It incorporates many changes and bug fixes to make OpenNMS more Java centric - including a new installer. Current production users should note that this release contains a lot more changes to the underlying code than any release since 1.1.0, so if you are currently happy with 1.1.3 or an earlier version, you may want to wait a week or two before upgrading, or wait until 1.2.
OpenNMS 1.1.3 is a major milestone on the way to the next stable release, 1.2. It contains a number of improvements, especially under the covers, and is the first release created under the new build system.
OpenNMS 1.1.2 adds several new features and bug fixes. New features include a JDBC poller, a script-based poller and script-based event handler, as well as contributed support for a map.
OpenNMS 1.1.1 is the next step towards the production 1.2 release. It contains a number of new features and bug fixes.
OpenNMS 1.1 extends the work that was begun with 1.0 to make OpenNMS more powerful and easier to use. Almost all of the new functionality was suggested by current OpenNMS users. It is hoped that these improvements will prove useful, and will lead to even more suggestions on how to improve the product.
OpenNMS 1.0.2 is a maintenance release that fixes several code issues.
OpenNMS 1.0.1 is a maintenance release that fixes several code issues.
Please, let us know if you have any problems at all at the OpenNMS Bugzilla [http://bugzilla.opennms.org/] page.

What's New?

What's New?

Chapter 2. What's New?
Changes in This OpenNMS
OpenNMS 1.2.9 is the latest production or "stable" release of OpenNMS. It contains a few new features and one large bug fix. However, if you don't need the new features or are not experiences database problems, this release could be considered optional.
Please Note: The 1.2.x branch of OpenNMS is built against Java 1.4.2 and RRDTool 1.0. If you are using Java 5 or RRDTool 1.2 it is best to recompile the code against those versions. It is just not possible for us to provide RPMs for all possible combinations, so the older versions are chosen for the greatest compatibility. The only exception are the 64-bit RPMs, which are built against the 64-bit version of Java 5 but still RRDTool 1.0. The development branch, 1.3.x, is built against Java 5 and RRDTool 1.2.
Changes in OpenNMS 1.2.9
Changes in OpenNMS 1.2.9
New Features
New Features
General Purpose Monitor Improvements (i.e. more Nagios Support)
General Purpose Monitor Improvements (i.e. more Nagios Support)
While it is most efficient in OpenNMS to use the built-in monitors, sometimes it is just easier to call an external script. The General Purpose (GP) monitor was designed for just this purpose. As found below in the 1.1.4 release notes, OpenNMS will pass an IP address using "--hostname" and a timeout using "--timeout" to any external script. However, some scripts, like those used for Nagios, require different parameters such as "-H" for hostname and "-t" for timeout.
This feature adds the option to override the defaults for the flag for the IP address and the timeout. Here is an example of a capsd plugin configuration:
<protocol-plugin protocol="Nagios_ICMP" class-name="org.opennms.netmgt.capsd.GpPlugin" scan="on" user-defined="false"> <property key="timeout" value="3000"/> <property key="retry" value="1"/> <property key="script" value="/opt/OpenNMS/contrib/plugins/check_icmp"/> <property key="banner" value="OK"/> <property key="hoption" value="-H"/> <property key="toption" value="-t"/> </protocol-plugin>
Add this entry to the poller-configuration.xml file:
<service name="Nagios_ICMP" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="1"/> <parameter key="timeout" value="3000"/> <parameter key="script" value="/opt/OpenNMS/contrib/plugins/check_icmp"/> <parameter key="banner" value="OK"/> <parameter key="hoption" value="-H"/> <parameter key="toption" value="-t"/> </service>
Remember to add the monitor line at the bottom of the file:
<monitor service="Nagios_ICMP" class-name="org.opennms.netmgt.poller.monitors.GpMonitor"/>
KSC Performance Report Improvements
KSC Performance Report Improvements
A few small changes have been made to the KSC reports. First, the zoom feature present on performance reports has been ported to KSC reports. Just click on the image. The default link for the graph has now been moved to a "Details" button. This button can be overridden on a graph by graph basis - i.e. if the graph represents mail server traffic, the link can be used to take the user to another page (internal or external) that is related to mail servers. Finally, it is possible to arrange more than one graph per line. Cacti tends to list two graphs per row, but depending on the size of your graphs and the size of the monitor, you can have up to 6 per line. This is configured per report.
Vulnscand
Vulnscand
OpenNMS, as a platform, is designed to be integrated into other products, and one of those is the security product Nessus which is used to scan for vulnerabilities. In much the same way that capsd scans for services, vulscand uses Nessus to scan for security issues. This functionality is being fully developed in the development branch, but it exists in a rudimentary form in the stable branch. Visit http://www.opennms.org/index.php/Vulnscand for more information on how to enable it.
Bug Fixes
Bug Fixes
On large installations of OpenNMS there has been observed a problem where all database activity stops. Investigations revealed that OpenNMS was waiting for PostgreSQL and PostgreSQL was waiting for OpenNMS. This hung state caused all event activity to stop, although data collection would continue. The only way to get it running again was either to restart OpenNMS or get lucky and kill the offending process. While it is usually against the philosophy of the stable branch to change something this important, the database connections were changed to be managed by a library called C3PO [http://sourceforge.net/projects/c3p0]. This creates a pool of connections that always stay open. Since the bug was related to the establishment and tearing down of database connections, by having such a pool the bug no longer occurs.
Changes in OpenNMS 1.2.8
Changes in OpenNMS 1.2.8
New Features
New Features
Nagios Support
Nagios Support
Even though OpenNMS was started only a couple of years after Net-Saint, everywhere we go people want to compare us to Nagios. While we compete with Nagios, they aren't our enemy, and if anything they help drive us to build a better product. Since the goal of OpenNMS is to become a platform, we hope to integrate with as many tools as possible. In this release we have back-ported the Nagios support that was introduced into the development release last year.
There are two ways to use OpenNMS with Nagios.
Using the NRPE Plugin and Monitor
The Nagios Remote Plugin Executor (NRPE) allows Nagios check scripts to be run on remote systems. With the NRPE agent correctly installed on a device, OpenNMS is now able to query that agent and run a particular command. If the command executes without errors, the NRPE service is considered "up", otherwise it is considered "down". No parameters are passed with the NRPE query, just the name of the command to run. This is useful if it is desired to have different thresholds configured on different devices. For example, if the "check disk" query is run, it may pass if the disk is less that 90% utilized on some systems, but it may be less than 80% on others. No change needs to be made to OpenNMS since the thresholds are set at the agent level.
To configure the NRPE plugin, modify capsd-configuration.xml similar to below:
<protocol-plugin protocol="NRPE_DISK" class-name="org.opennms.netmgt.capsd.NrpePlugin" scan="on" user-defined="false"> <property key="banner" value="*" /> <property key="port" value="5666" /> <property key="timeout" value="3000" /> <property key="retry" value="2" /> <property key="command" value="check_disk" /> </protocol-plugin>
This will create a service called NRPE_DISK that will run the check_disk script.
To activate the NRPE monitor for the service above, make add this entry to the poller-configuration.xml file:
<service name="NRPE_DISK" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="3"/> <parameter key="timeout" value="3000"/> <parameter key="port" value="5666"/> <parameter key="command" value="check_disk"/> <parameter key="padding" value="2"/> </service>
Remember to add the monitor line at the bottom of the file:
<monitor service="NRPE_DISK" class-name="org.opennms.netmgt.poller.monitors.NrpeMonitor"/>
Restart OpenNMS, and it will then automatically discover that the service is running on the remote system and begin monitoring it.
Using the NSClient Plugin and Monitor
The Net-Saint Client provides a method from monitoring statistics on a Windows server. As with NRPE, OpenNMS can query the remote agent and based upon its response mark the service as being "up" or "down". To configure monitoring the space on the "C:" drive, first edit capsd-configuration.xml as follows:
<protocol-plugin protocol="NSC_C_SPACE" class-name="org.opennms.netmgt.capsd.NsclientPlugin" scan="on" user-defined="false"> <property key="port" value="1248" /> <property key="timeout" value="3000" /> <property key="retry" value="2" /> <property key="command" value="USEDDISKSPACE" /> <property key="parameter" value="C:" /> </protocol-plugin>
This will create a service called NSC_C_SPACE.
Then make the corresponding changes to the poller-configuration.xml file:
<service name="NSC_C_SPACE" interval="300000" user-defined="true" status="on"> <parameter key="retry" value="2"/> <parameter key="port" value="1248"/> <parameter key="timeout" value="3000"/> <parameter key="command" value="USEDDISKSPACE" /> <parameter key="warningPercent" value="80" /> <parameter key="criticalPercent" value="90" /> <parameter key="parameter" value="C:" /> </service>
and as before don't forget the monitor line at the bottom:
<monitor service="NSC_C_SPACE" class-name="org.opennms.netmgt.poller.monitors.NsclientMonitor"/>
then restart OpenNMS.
Note that OpenNMS services are either "up" or "down". At the moment, there is no concept of "warning". So if the poll fails at either the "warning" or "critical" level, the service will be marked as down.
As with NRPE, the OpenNMS discovery process will automatically discover the services, so once configured nothing more needs to be done.
Zoom Feature for Performance Graphs
Zoom Feature for Performance Graphs
Since we're on this integration kick, we borrowed the RRD "zoom" functionality from the Cacti project (again, a back-port from the development release). Now when viewing an SNMP performance graph it may appear as a link (there will be a box, probably blue, around it). Click on the graph and it will appear on a new page. Then click and drag across an interesting area of the graph, and it should be resized to show more detail for that area. The process can be repeated. To zoom back out, simply hit the "back" button of the browser.
Tomcat Version 5 Support
Tomcat Version 5 Support
Tomcat is the servlet container used for the OpenNMS web-based user interface. For years OpenNMS has only been supported on Tomcat version 4, which is now quite old. With this release, Tomcat version 5 is supported. Some distributions support Tomcat out of the box (SuSE comes to mind). For others getting Tomcat5 installed might be more of a challenge, so OpenNMS will work with either Tomcat4 or Tomcat5. There are slight differences to the install script when running on Tomcat5. Please check out the wiki page for more information: http://www.opennms.org/index.php/Tomcat_5.
Additional Parameters in Events and Notifications
Additional Parameters in Events and Notifications
A few new parameters have been added that can be used in event descriptions and notifications. %assetdescr% will return the description retrieved from the assets table for the node that caused the event. Similarly, %assetcomment% will return the comment field from the assets table. In addition, %logmsg% will now work in notifications to return the log message for the event.
Availability Reports by Date
Availability Reports by Date
When running an availability report, it is now possible to override the date that is used. This is helpful if, say, it is desired to run a report as of May 31, 2006 to see the availability for that month. By default OpenNMS will use the current date.
The "invert" parameter for the ICMP Monitor
The "invert" parameter for the ICMP Monitor
In some cases, such as an ISDN backup link, an error condition is indicated by the ability to ping an IP address, versus the usual error condition of not being about to ping the address. There is now a way to use OpenNMS to monitor those links, as long as they have an IP address that only works when the link is active.
First, the service has to be defined in capsd-configuration.xml:
<protocol-plugin protocol="ISDN_Backup" class-name="org.opennms.netmgt.capsd.IcmpPlugin" scan="off" user-defined="false"> <property key="timeout" value="2000" /> <property key="retry" value="2" /> <protocol-configuration scan="enable" user-defined="false"> <specific>172.20.1.17</specific> <specific>172.20.2.31</specific> <range begin="192.168.0.0" end="192.168.0.10"/> </protocol-configuration> </protocol-plugin>
A few things to notice. First, the main "scan" attribute is set to "off". Since these links act differently than normal links, they have to be specified explicitly. That's what the scan="enable" section does. In that section, individual IP addresses can be specified as well as a range of IP addresses. No include files or "iplike" functions at the moment.
Once that is complete, edit the poller-configuration.xml file to enable the monitor:
<service name="NotICMP" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="invert" value="true"/> </service>
The key difference here is the "invert" parameter. If the service is available, i.e. the link is up, it will be marked as down. Otherwise, it is marked as up.
Bug Fixes
Bug Fixes
There are a number of small bug fixes in this release, mainly dealing with capsd.
Changes in OpenNMS 1.2.7
Changes in OpenNMS 1.2.7
Bug Fixes
Bug Fixes
SNMP "select" Data Collection Reset
SNMP "select" Data Collection Reset
It turns out this issue, while fixed in 1.2.6, was still present if using "SNMPv1" and "SNMPv2" services versus the default "SNMP" service. This has been corrected.
Changes in OpenNMS 1.2.6
Changes in OpenNMS 1.2.6
New Features
New Features
New format for availability reports
New format for availability reports
Version 1.2.6 previews new format availability reports from the 1.3 tree of OpenNMS. Each availability report format (HTML, PDF and SVG) now has a new version of the Last Months Daily Availability and Month to Date Daily Availability report. These new reports have a tabular calendar look to them and have colour-coded cells to identify days that have fallen below "normal" and "warning" levels for the category displayed in the report. To generate these reports, select "Calendar Format" from the availability reports page in the WebUI. The original reports are still available (by default) as "Classic Format" reports.
Ability to have SNMPv1 and SNMPv2 as Separate Services
Ability to have SNMPv1 and SNMPv2 as Separate Services
A lot of changes have been made to SNMP. The most useful is the ability to view SNMP services by version, instead of as a generic "SNMP" service. This is in preparation for the SNMPv3 support that is available in the development branch - it would be nice to know which versions of SNMP are supported on a device.
In order to speed up collectd startup times, since 1.2.5 OpenNMS has defaulted to SNMPv1 if SNMPv2 was not specifically defined in snmp-config.xml. This allows collectd to start without having to query each device, but it created a number of issues at sites where the high capacity (64-bit) counters were being used to track traffic data. By defaulting to SNMPv1, those values were not accessible. Also, there is an existing bug where if SNMPv2 was supported without SNMPv1, the service would not be discovered (unless v2 was forced in the configuration file).
The approach taken to fix this was to create in capsd two new services, SNMPv1 and SNMPv2. By using the "force version" parameter, OpenNMS can discover which devices expressly support each version. Armed with that information, it should be possible to perform data collection using the most preferable version. However, there was the additional problem with devices that support both versions - how to prevent double collection?
The solution was to be able to use OpenNMS packages - one for SNMPv2 and one for SNMPv1. In any filter or rule, using "is[ServiceName]" will return all the IP addresses that support a particular service. Thus "isHTTP" will return all those interfaces with HTTP running on port 80, and "isSNMPv2" can return all of the devices that support SNMP version 2.
The problem is that having a package for "isSNMPv2" and another for "isSNMPv1" would result in duplicate collection on devices that supported both. There needed to be some way to say "return all the interfaces that support SNMPv1 but do not support SNMPv2". Using something like "!(isSNMPv2)" didn't work because that is true for any service that is not SNMPv2, instead of finding out "is SNMPv2 one of the supported services".
The solution was to create a new filter tool called "notis[ServiceName]". This will craft an SQL query such that it will only return true if "ServiceName" is not associated with the interface in question. The final piece was to add a "force version" parameter to collectd. Now it was possible to create two packages, one for SNMPv2 and one for SNMPv1, that would collect as desired.
There are only two steps needed to get this working. First, the two services must be added to the capsd-configuration.xml.
<protocol-plugin protocol="SNMPv1" class-name="org.opennms.netmgt.capsd.SnmpPlugin" scan="on" user-defined="false"> <property key="timeout" value="2000"/> <property key="force version" value="v1"/> <property key="retry" value="2"/> </protocol-plugin> <protocol-plugin protocol="SNMPv2" class-name="org.opennms.netmgt.capsd.SnmpPlugin" scan="on" user-defined="false"> <property key="timeout" value="2000"/> <property key="force version" value="v2c"/> <property key="retry" value="2"/> </protocol-plugin>
Now this is the important part - before switching over to using the new services, they have to be discovered on the devices. This takes time. If the default rescan frequency is being used, then at least 24 hours is needed until SNMPv1 and SNMPv2 will be discovered.
If you know your network, then some SQL trickery can be used to make this easier. First, update capsd as above and restart OpenNMS.
Get in to the database:
psql -U opennms opennms
and then select * from service;
Note the serviceIDs for SNMP, SNMPv1 and SNMPv2.
To add SNMPv1 to those devices that already have SNMP, use the following SQL:
INSERT INTO ifservices (nodeid, ipaddr, ifindex, serviceid, status, source, notify) SELECT nodeid, ipaddr, ifindex, [SNMPv1 ID], status, source, notify FROM ifservices WHERE serviceid=[SNMP ID] AND ipaddr NOT IN (SELECT ipaddr FROM ifservices WHERE serviceid=[SNMPv1 ID]);
replacing [SNMP ID] with the serviceID for SNMP and [SNMPv1 ID] with the serviceID for SNMPv1. Repeat as desired for SNMPv2.
Second, the collectd-configuration.xml file must be updated. Remember - only do this if SNMPv1 and SNMPv2 have been discovered.
<package name="collect-SNMPv2"> <filter>isSNMPv2</filter> <include-range begin="1.1.1.1" end="254.254.254.254"/>

<service name="SNMPv2" interval="300000" user-defined="false" status="on"> <parameter key="collection" value="default"/> <parameter key="force version" value="v2c"/> <parameter key="port" value="161"/> <parameter key="retry" value="3"/> <parameter key="timeout" value="3000"/> </service>

<outage-calendar>zzz from poll-outages.xml zzz</outage-calendar> </package>

<package name="collect-SNMPv1"> <filter>isSNMPv1 &amp; notisSNMPv2</filter> <include-range begin="1.1.1.1" end="254.254.254.254"/>

<service name="SNMPv1" interval="300000" user-defined="false" status="on"> <parameter key="collection" value="default"/> <parameter key="force version" value="v1"/> <parameter key="port" value="161"/> <parameter key="retry" value="3"/> <parameter key="timeout" value="3000"/> </service>

<outage-calendar>zzz from poll-outages.xml zzz</outage-calendar> </package>

<collector service="SNMPv1" class-name="org.opennms.netmgt.collectd.SnmpCollector"/> <collector service="SNMPv2" class-name="org.opennms.netmgt.collectd.SnmpCollector"/>
Note the use of the "notis" filter tool to only do collection via SNMPv1 if SNMPv2 is not present.
New JDBCStoredProcedureMonitor and JDBCStoredProcedurePlugin
New JDBCStoredProcedureMonitor and JDBCStoredProcedurePlugin
Tobey Pasheilich has added some new functionality to the JDBC monitoring code in OpenNMS.
In his environment, Oracle backups take their database(s) off-line. However, Oracle still responds to connections and the metadata poll as performed in JDBCMonitor passes even though the databases are not available. These changes allow testing via the execution of a stored procedure to insure that the database is actually working. This may also allow some application level rules to be evaluated.
Usage is typical of other plugins and pollers. Entries must be created for the new java plugins. As an extension of the JDBCPlugin and JDBCMonitor, it requires all the xml parameters those classes require. Additionally, a parameter 'stored-procedure' is required. The procedure name given in the xml is assumed to exist inside a package named 'test' on the database. It is hoped that this will help limit concerns about accidental stored procedure invokation. The stored procedure must return a bit and take no arguements.
An example capsd-configuration.xml entry would be something like:
<protocol-plugin protocol="Oracle-JDBC-ets" class-name="org.opennms.netmgt.capsd.JDBCStoredProcedurePlugin" scan="on" user-defined="false"> <property key="user" value="USERNAME"/> <property key="password" value="PASSWORD"/> <property key="retry" value="2"/> <property key="timeout" value="3000"/> <property key="driver" value="oracle.jdbc.OracleDriver"/> <property key="url" value="jdbc:oracle:thin:@OPENNMS_JDBC_HOSTNAME:1521:ets"/> <property key="stored-procedure" value="ets"/> </protocol-plugin>
And in poller-configuration.xml add:
<service name="Oracle-JDBC-ets" interval="300000" user-defined="false" status="on"> <parameter key="user" value="USERNAME"/> <parameter key="password" value="PASSWORD"/> <parameter key="timeout" value="3000"/> <parameter key="driver" value="oracle.jdbc.OracleDriver"/> <parameter key="url" value="jdbc:oracle:thin:@OPENNMS_JDBC_HOSTNAME:1521:ets"/> <parameter key="stored-procedure" value="ets"/> <parameter key="rrd-repository" value="/usr/local/opennms/share/rrd/response"/> <parameter key="ds-name" value="jdbc-ets"/> </service>
Remember to add the service definition at the bottom:
<monitor service="Oracle-JDBC-ets" class-name="org.opennms.netmgt.poller.monitors.JDBCStoredProcedureMonitor"/>
Capsd SNMP Plugin and Poller SNMP Monitor Changed Slightly
Capsd SNMP Plugin and Poller SNMP Monitor Changed Slightly
In addition to changes for the new SNMP services, the SNMP plugin and SNMP monitor where changed to use SNMP GET commands instead of SNMP GETNEXT commands. This will make it easier to build SNMP-based monitors, as the discovery of the SNMP-based service will be more accurate.
WebUI Speed Enhancements
WebUI Speed Enhancements
On large systems the OpenNMS GUI can become slow. In an attempt to fix that, most of the Admin functions for the system are also available under the Admin section for each node. This saves time waiting for the large system-wide pages to load. However, the "Configure SNMP Data Collection per Interface" would always return to the system-wide page after a change. Now it will return to the page for the node. Also, the "List Nodes" page will only list the node labels instead of the node labels and interfaces (that option is still available under "Search"). Also on that topic, the Manage/Unmanage screen no longer requires a restart (I should be hearing a collective cheer). When a service is unmanaged, the categories on the front page will be updated and all outstanding outages cleared.
Cosmetic Improvements
Cosmetic Improvements
There are a few cosmetic changes. There is a new color scheme for the default datacollection-config.xml reports. Please let us know if you like it. If not, the old colors can be found in the file snmp-graph.properties.oldcolors. Simply move it to snmp-graph.properties and restart Tomcat.
There is also a new stylesheet. The old stylesheet is called styles.css.orig and can be found in the $OPENNMS_HOME/webapps/opennms/includes directory. Move it back to styles.css if you don't like the new one. And a couple of the asset fields now appear on the main node page.
Bug Fixes
Bug Fixes
SNMP "select" Data Collection Reset
SNMP "select" Data Collection Reset
The biggest bug fixed in this release also involves SNMP data collection. It was discovered that if a device has an IP address configured, but SNMP is not supported on that particular interface, any collections set on those interfaces would be set to "N" on the next rescan. Very frustrating, but it is better now. Also fixed in the release is an issue with the primary SNMP interface being on a NIC with other addresses. It would rarely cause issues, so not too many people should have experienced issues with this.
New MX4J
New MX4J
The MX4J jars have been upgraded to 3.0.1 which should fix issues with opennms.sh -v status that some people were experiencing.
Changes in OpenNMS 1.2.5
Changes in OpenNMS 1.2.5
New Features
New Features
Simplify building on 32bit/64bit architectures
Simplify building on 32bit/64bit architectures
Some new options were added to build.xml to simplify support of specifying the target architecture for which the C files are compiled. They are build.jni.compiler.arg for JNI code and build.postgresql.compiler.arg for the PostgreSQL iplike module. You would use something like "-m32" or "-m64" to force compilation of 32 bit or 64 bit binaries. Note that the options may differ for your platform and/or version of GCC. See your GCC man page for details. Thanks to Jonathan Sartin who submitted a patch. Bug 1331.
Support for building on FreeBSD
Support for building on FreeBSD
Some bugs have been fixed, and OpenNMS can now compile and run on FreeBSD. Thanks to Dennis Berger and Brent Verner for supplying patches (bug 1315). You should be able to compile for FreeBSD with the following build.properties file, assuming that you have used the ports tree to install RRDTool and PostgreSQL:
build.postgresql.include.dir=/usr/local/include/postgresql/server build.postgresql.include2.dir=/usr/local/include build.rrdtool.include.dir=/usr/local/include build.rrdtool.lib.dir=/usr/local/lib build.rrdtool.bin=/usr/local/bin/rrdtool
XMPP Group Notifications
XMPP Group Notifications
Added the ability to notifiy groups (chat rooms) via XMPP. A shout out to Jonathan Sartin for this work.
Bug Fixes
Bug Fixes
Fixed Possible Poller Deadlock
Fixed Possible Poller Deadlock
Addressed a possible poller problem that would cause outages that would never clear. This was fixed in 1.3.0 and backported to 1.2.5.
SNMP Data Collection Improvements
SNMP Data Collection Improvements
Made some changes to make SNMP data collection faster as well as to improve startup time on systems with a large amount of data collection.
A number of small bug fixes have been added:
•
Fixed a number of documentation mistakes pointed out by Austin Tuan. Thank you very much, Austin! Bug 1303.
•
Some minor bugs in the JavaMailer have been fixed.
•
Added come configutation for Symbol, Netscreen, Novell and AirDefense events.
Changes in OpenNMS 1.2.4
Changes in OpenNMS 1.2.4
New Features
New Features
The Use of "~" For Regular Expressions
The Use of "~" For Regular Expressions
The ability to access the OpenNMS database via rules and filters is pretty powerful. With this release you can use the "~" character to imbed regular expressions on the right hand side of the rule or filter. Previously, the "~" character meant the same as "like". Note that this feature requires PostgreSQL 7.4 or higher. Earlier version will behave just like "like".
RESOLVED Behavior Options
RESOLVED Behavior Options
Currently, when a "down" event notification is auto-acknowledged with an "up" event, a "RESOLVED" message gets sent to anyone who got the original "down" notice. However, if the problem is manually acknowledged, the "RESOLVED" message is not sent.
With the release, when you configure a destination path, you can choose "on", "auto" or "off".
"on" will send RESOLVED notices to anyone who got the down notice.
"auto" will send RESOLVED notices to anyone who got the down notice, and the notice was auto-acknowledged (default).
"off" will not send RESOLVED notices to anyone.
Hats off to Bill for this one.
The Ability to use %descr% in Notifications
The Ability to use %descr% in Notifications
Suppose you have a SNMP Trap event that comes in with a huge description, including all the varbinds, etc. If you want to make a notification that triggers on that event, you will need to recreate or copy the description from the event into the notice. With this release, you can simply use %descr% to include the triggering event description in the notice.
Thanks to Vincent for this addition.
New "url" Parameter in the HTTP and HTTPS Plugins
New "url" Parameter in the HTTP and HTTPS Plugins
Prior to this release, it was hard to add service checks for web sites outside of the "root" directory. Now there is a "url" parameter to help with this. Suppose I wanted to monitor a wiki that was at "http://10.1.1.1/wiki". I'd add the following to capsd-configuration.xml:
<protocol-plugin protocol="HTTP-Wiki" class-name="org.opennms.netmgt.capsd.HttpPlugin" scan="on" user-defined="false"> <property key="port" value="80"/> <property key="url" value="/wiki"/> <property key="timeout" value="3000"/> <property key="retry" value="2"/> </protocol-plugin>
Then I would need to add a similar entry to poller-configuration.xml:
<service name="HTTP-Wiki" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="1"/> <parameter key="timeout" value="3000"/> <parameter key="port" value="80"/> <parameter key="url" value="/wiki"/> </service>
Don't forget the monitor line in the bottom section:
<monitor service="HTTP-Wiki" class-name="org.opennms.netmgt.poller.monitors.HttpMonitor"/>
This will test each server for a "/wiki" URL, and if the return code is less the 400 the test will pass. Note that this will not work on password protected URLs like the one OpenNMS uses. That will be addressed in a new monitor coming in the next release (Basic AUTH support).
Bug Fixes
Bug Fixes
A number of small bug fixes have been added:
•
A typo in the Schedule Outages GUI for "thusday" has been corrected.
•
Fixed an issue with acknowledging events via the GUI
•
Corrected a case where multiple "Update SNMP" links would appear
•
Modified the HTTP/HTTPS plugins to handle replies that included a newline (Thanks Tobey)
•
Fixed an issue where interfaces could be marked as "Secondary" even if they were excluded from collectd (Thanks Bill)
Configuration Changes
Configuration Changes
A number of configurations have been added:
•
Added support for RFC1628, the UPS MIB
•
Added MGE UPS collections and reports
•
Added SystemEdge and Fujitsu-Siemens events, as well as new MGE-UPS event definitions.
•
Added Netgear events.
•
64-bit counter support for ifHCInOctets and ifHCOutOctets was added.
Changes in OpenNMS 1.2.3
Changes in OpenNMS 1.2.3
New Features
New Features
Scheduled Outages Editor
Scheduled Outages Editor
The final version of Craig Miskell's (OGP) poll-outages editor is included in this release. Accessed from the Admin menu, it allows one to configure weekly, monthly and specific poll-outages from the webUI. A poll outage is where polling will stop for a particular set of devices or a package.
Choose "Scheduled Outages" from the admin page, and the GUI will display the currently configured outages. You can edit those or create your own. You can then apply them to notifications, or to particular packages in the threshd, collectd and poller configurations.
Please note that when applied to polling, no checks occur during the outage period. The services are not automatically considered "up". So if you have a maintenance window that starts at 2am and ends a 4am on Sundays, if you take the service down at 1:59 am and OpenNMS marks it as down, it will stay down until 4am.
Hat off to Craig for this feature.
Growl Support in OS X
Growl Support in OS X
If you happen to run OpenNMS on OS X, you can now send notifications via Growl. Simply use "growlMessage" as one of the services in your destination path. Note that you have to be on the machine running OpenNMS to see them.
New Events and Graphs
New Events and Graphs
There have been a number of event definitions added to OpenNMS, including those for NORTEL Contivity and Foundry devices. In addition, more support has been added for the SNMP Informant agent.
Bug Fixes
Bug Fixes
Some people have reported an issue with service polling stopping. It was determined that, for some reason on some systems, a particular device or devices will cause a polling thread to hang. This would block polling from occuring. While the root cause of the issue has not been found (i.e. why the thread hangs) the code was modified so that a hung thread would not block the whole queue.
Changes in OpenNMS 1.2.2
Changes in OpenNMS 1.2.2
There is only one bug addressed in 1.2.2 concerning possible webUI exceptions if there are null values in the issnmpprimary field in the interface table of the database.
Changes in OpenNMS 1.2.1
Changes in OpenNMS 1.2.1
New Features
New Features
XMPP Support
XMPP Support
Chris Abernethy contributed some code to allow notifications using the XMPP instant messaging protocol. This is most commonly associated with the Jabber open-source messaging project.
Edit the xmpp-configuration.properties file to include the username and password of the user you want to use as the originator of the notice. Also include the server you wish to connect to in order to send the notice.
Finally, add an XMPP Address to each user that should receive the notification, such as "myname@jabber.org".
If your destination path command includes xmppMessage, then the notification text will be sent via XMPP to the user's XMPP address. Note: be sure that the user has allowed messages from the OpenNMS XMPP user. When I first tested this, I was blocking all messages from people not on my "buddy" list and I never received the notice.
This was enhancement bug 1168.
Support for Labels in SNMP Performance Reports
Support for Labels in SNMP Performance Reports
Craig Miskell contributed some code that allows for text strings to be collected via SNMP and used to label SNMP Performance reports.
For example, the Net-SNMP agents allows one to collect on disk statistics:
disk / disk /boot disk /opt/distros
This will create a table where the first row is disk space on root, the second row is the disk space on /boot, etc.
The problem is that this configuration:
disk /boot disk / disk /opt/distros
Is also valid, but the /boot parition is now index one, and / is index two.
Previously, one had to be a little saavy about how to configure the order of disk volumes, but now the disk label can just be collected and displayed.
For example, we currently collect on the first instance of the Net-SNMP disk table, and just assume it's root:
<group name = "net-snmp-root-disk" ifType = "ignore"> <mibObj oid=".1.3.6.1.4.1.2021.9.1.6" instance="1" alias="ns-disk-root-tot" type="gauge"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.7" instance="1" alias="ns-disk-root-avail" type="gauge"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.8" instance="1" alias="ns-disk-root-used" type="gauge"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.9" instance="1" alias="ns-disk-root-pct" type="gauge"/> </group>
To use this feature, we convert it to something more generic, disk 1 instead of root:
<mibObj oid=".1.3.6.1.4.1.2021.9.1.2" instance="1" alias="ns-disk-1-name" type="string"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.6" instance="1" alias="ns-disk-1-tot" type="gauge"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.7" instance="1" alias="ns-disk-1-avail" type="gauge"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.8" instance="1" alias="ns-disk-1-used" type="gauge"/> <mibObj oid=".1.3.6.1.4.1.2021.9.1.9" instance="1" alias="ns-disk-1-pct" type="gauge"/>
Note the new first line. The ".2" OID in this table is the disk label, which we now collect. It gets stored in a file called $OPENNMS_HOME/share/rrd/snmp/$NODEID/strings.properties, where the $NODEID is the node number of the device being collected.
A sample string.properties file looks like this:
#Wed Mar 16 17:46:25 EST 2005 ns-disk-3-name=/opt/distros ns-disk-2-name=/boot ns-disk-1-name=/
Once the datacollection-config.xml file is changed, and OpenNMS is restarted, collectd will begin storing the collected strings.
So, how are they used? To display them in reports, edit the snmp-graph.properties file. Everything in this file that is in "curly braces" is something that OpenNMS supplied to RRDTool (or jRobin).
report.netsnmp.disk1percent.name=Percentage Disk Space on 1 report.netsnmp.disk1percent.columns=ns-disk-1-pct report.netsnmp.disk1percent.type=node report.netsnmp.disk1percent.propertiesValues=ns-disk-1-name report.netsnmp.disk1percent.command=--title="Percentage Disk Space on {ns-disk-1-name}" \ DEF:dpercent={rrd1}:ns-disk-1-pct:AVERAGE \ LINE2:dpercent#0000ff:"% Disk Space Used" \ GPRINT:dpercent:AVERAGE:"Avg \\: %8.2lf %s" \ GPRINT:dpercent:MIN:"Min \\: %8.2lf %s" \ GPRINT:dpercent:MAX:"Max \\: %8.2lf %s\n"
Note the new "properitesValues" line. This line will look for the value(s) listed in the appropriate strings.properties file, such as ns-disk-1-name. Then putting that value in curly braces, as in {ns-disk-1-name} will cause OpenNMS to replace it with the proper value.
By default, OpenNMS now collects on the first 5 disks defined by Net-SNMP and disks 2 through 4 as defined by the host-resources MIB. Please feel free to improve on this configurations, and post your diff as an enchancement bug on http://bugzilla.opennms.org for inclusion in a future release.
Some caveats: Currently this only works for node level information. Also, the labels can't be used in notifications or events, so if you get a highThreshold alert on disk usage, you won't be able to tell exactly which disk (but it should be easy to look up).
Many thanks to Craig for this work.
New DHCP Poller
New DHCP Poller
Bill Ayres (OGP) has improved the DHCP poller. The new default dhcp-configuration.xml file now looks like this:
<DhcpdConfiguration port="5818" macAddress="00:06:0D:BE:9C:B2" myIpAddress="127.0.0.1" extendedMode="false" requestIpAddress="127.0.0.1"> </DhcpdConfiguration>
The port and macAddress options were there before, but now you can add myIpAddress, extendedMode and a requestIpAddress.
With the default configuration, the DHCP poller should act as before (although on my test network it now correctly sees that my Airport Express does not have a DHCP server on it that is accessible from the "wired" side). This is "broadcast" mode.
The following describes each of the new variables:
myIpAddress
: This parameter will usually be set to the ip address of the OpenNMS server, which puts the DHCP poller in "relay" mode as opposed to "broadcast" mode. In "relay" mode, the DHCP server being polled will unicast its responses directly back to the specified ip address rather than broadcasting its responses. This allows DHCP servers to be polled even though they are not on the same subnet as the OpenNMS server, and without the aid of an external relay.
usage: myIpAddress="10.11.12.13" or myIpAddress="broadcast" (default)
extendedMode
: When extendedMode is false, the DHCP poller will send a DISCOVER and expect an OFFER in return. When extendedMode is true, the DHCP poller will first send a DISCOVER. If no valid response is received it will send an INFORM. If no valid response is received it will then send a REQUEST. OFFER, ACK, and NAK are all considered valid responses in extendedMode.
usage: extendedMode="true" or extendedMode="false" (default)
requestIpAddress
: This parameter only applies to REQUEST queries sent to the DHCP service when extendedMode is true. If an ip address is specified, that ip address will be requested in the query. If "targetHost" is specified, the DHCP server's own ip address will be requested. Since a well-managed server will probably not respond to a request for its own ip, this parameter can also be set to "targetSubnet". This is similar to "targetHost" except the DHCP server's ip address is incremented or decremented by 1 to obtain an ip address that is on the same subnet. (The resulting address will not be on the same subnet if the DHCP server's subnet is a /32 or /31. Otherwise, the algorithm used should be reliable.)
usage: requestIpAddress="10.77.88.99" or requestIpAddress="targetHost" or requestIpAddress="targetSubnet" (default)
Caution on usage:
If in extended mode, the time required to complete the poll for an unresponsive node is increased by a factor of 3. Thus it is a good idea to limit the number of retries to a small number.
Thanks to Bill for his hard work on this.
GUI for snmp-config.xml
GUI for snmp-config.xml
Gerald Turner has written a useful admin GUI for managing the snmp-config.xml file. It allows you to add specific IP addresses and IP address ranges and associate them with community strings.
For example, if you have the following default snmp-config.xml file:
<snmp-config retry="3" timeout="800" read-community="public" write-community="private">

</snmp-config>
this will use the default community string of "public" for SNMP requests. Using the GUI, one can add a range that, say, uses "public2":
<snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition read-community="public2"> <range begin="192.168.0.1" end="192.168.0.254"/> </definition> </snmp-config>
You can also add specific IP addresses, say this one for "public3":
<snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition read-community="public2"> <range begin="192.168.0.1" end="192.168.0.254"/> </definition> <definition read-community="public3"> <specific>192.168.1.1</specific> </definition> </snmp-config>
This feature will automatically do things like split ranges. For example, add "public4" as the string for 192.168.0.50:
<snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition read-community="public2"> <range begin="192.168.0.1" end="192.168.0.49"/> <range begin="192.168.0.51" end="192.168.0.254"/> </definition> <definition read-community="public3"> <specific>192.168.1.1</specific> </definition> <definition read-community="public4"> <specific>192.168.0.50</specific> </definition> </snmp-config>
There is a caveat. If you add a specific entry like 192.168.1.1 above, and then go back and add a range that includes that specific IP, the range will overwrite the specific entry, as in this example for "public5":
<snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition read-community="public2"> <range begin="192.168.0.1" end="192.168.0.49"/> <range begin="192.168.0.51" end="192.168.0.254"/> </definition> <definition read-community="public4"> <specific>192.168.0.50</specific> </definition> <definition read-community="public5"> <range begin="192.168.1.1" end="192.168.1.254"/> </definition> </snmp-config>
This feature was designed to help manage this file before discovery It will not update the community string for an SNMP agent that is already being collectd. In the case that the community string for a device changes, and this results in a data collection failure event, it is possible to change the community string to the correct one without restarting OpenNMS. Use this GUI to make sure the community string is correctly in the snmp-config.xml file, and then go to the device's node page. Click the link that says "Update SNMP" and collection should resume.
This was bug 1167, and I'm leaving it open as an enhancement because there is one thing left I'd like to see. I'd like to see the current contents of the snmp-config.xml file displayed on this page as well. It is hoped that it will be available for the next release.
Hats of to Gerald for this work.
Other Features
Other Features
There were a number of smaller features included in this release:
•
Added the RESOLVED tag to the body as well as the subject of notifications.
•
Added a Linksys event to stop connection traps from Linksys gear.
•
Added a "focus" to the Add Interface admin page so that it is no longer required to select the field before typing the IP address.
•
Greatly improved the execution speed of "Configure SNMP Data Collection per Interface" in the Admin webUI.
•
Added the ability to display the ifAlias in events or notifications using %ifalias%.
•
Improved the error message when entering an invalid Outage ID in a search.
•
Numerous small improvements to the node page in the web UI.
Bug Fixes
Bug Fixes
The following is a list of bug fixes included in this release:
•
There was an issue with SNMP version 2 data collection on large devices (i.e. lots of interfaces) where the ifIndex values weren't contiguous. This has been corrected. Bug 1141.
•
Applied the patch to help with 30 second outages. Bug 1180.
•
Many people reported issues with 1.2.0 errors with the new ifAlias field. It was too small to hold the entire string associated with some interfaces, so the size of this field has been increased to 256.
•
Fixed an issue with the service unresponsive behavior being active even when not configured. Bug 1151.
•
Corrected a problem with Top 20 availability reports including the wrong services. Bug 945.
•
The correct time is now shown in notifications, versus GMT. Bug 1114.
In addition, DJ Gregor (OGP) has done a number of improvements to the build system.
Changes in OpenNMS 1.2.0
Changes in OpenNMS 1.2.0
The only changes between 1.1.5 and 1.2.0 are some bug fixes and the addition of a few more datacollection values and reports.
Changes in OpenNMS 1.1.5
Changes in OpenNMS 1.1.5
The current development goal of the OpenNMS team is to get a new, stable release out as soon as time will allow. This will allow for a new development cycle that can be very daring in its scope while still providing a stable, production application. This release is our second release candidate for 1.2.0, and if testing goes well it will be released shortly.
The reason 1.1.4 did not become 1.2.0 was due to a lot of code changes to the poller. In fact, the poller has been pretty much rewritten and the code reorganized. Those who look at the new poller code should be impressed with the work Matt (OGP) did.
1.1.5 also represents a new development philosophy for the team. OpenNMS is now written using "test driven development". In a nutshell: when a new feature is desired, or a bug needs fixing, the first piece of code that is written is a test to insure that the feature works or that the bug does not occur. Since no change is made to the code at this point, the test obviously will fail. Then the feature is written or the bug fixed until the test passes, and the final step is to clean up the code to remove duplication, etc.
Over the next year, this main change in the development philosophy of OpenNMS will reap huge benefits in terms of speed of development and code quality.
Notifications on Auto-Acknowledged Events
Notifications on Auto-Acknowledged Events
The reason the poller code was rewritten was mainly in support of this one new feature. OpenNMS has three main functions: service polling, data collection and event management. This last feature was hampered by an issue with auto-acknowledgement.
Here's the scenario: A service is down and an event is generated. This event triggers a notification, which walks a destination path. The first step in the path is to wait for 2 minutes before doing anything, and then it is to page the on call person, and if the notification is not acknowledged in 15 minutes, the manager is to get paged.
Well, let's assume the outage occurs at 2 in the morning and lasts for four minutes. After the first two minutes, a page is sent to the on-call person and it wakes him up.
Now, prior to this release, when the service is restored two minutes later, the auto-acknowledge code would acknowledge the "down" notice, so the manager would not get paged. However, unless notices were configured for "up" events, the on call person would not know that the service has been restored, so they would have to wake up, get logged in and then notice that the problem had gone away.
If notices were configured for "up" events, the on call person would know that the service was up and could go back to bed. Unfortunately, if the "up" notice walked the same path as the "down" notice, it would have to be manually acknowledged or the manager would get a page saying that the service was now "up" without ever receiving the "down" page.
This obviously isn't very useful.
So now there is an option to send a "resolution" notice when a "down" event gets auto-acknowledged by an "up" event. The same notice that gets sent with the "down" will be sent with the "up" with the word "RESOLVED:" prefixed to the message. It will only be sent to those people who got the "down" notice and in the same manner, i.e. e-mail, page, etc.
There are a few things to consider:
•
Notices concerning "up" events will still get treated as separate notifications. This only concerns auto-acknowledged events. To avoid the scenario above, "up" notices should be turned off, and they have been in the default configuration.
•
OpenNMS "down" events, such as nodeLostService and nodeDown will now always be matched with the corresponding "up" event. For example: HTTP stops on a server, so a nodeLostService event is sent. A short while later the node itself goes down, causing a nodeDown event. When the server is restored, everything is running, so a nodeUp event gets generated and a nodeRegainedService event for HTTP. In the past this would not happen. Once the node came back up, if HTTP was running no event would be sent. If the service was still down, a second nodeLostService event would be generated.
For those of you who keep up with the code, notice that there is no longer a separate outage daemon. All of that functionality has been integrated into the poller.
To configure this functionality, look at the notifd-configuration.xml file. Here is an example:
<auto-acknowledge resolution-prefix="RESOLVED: " notify="true" uei="uei.opennms.org/nodes/nodeRegainedService" acknowledge="uei.opennms.org/nodes/nodeLostService"> <match>nodeid</match> <match>interfaceid</match> <match>serviceid</match> </auto-acknowledge>
This says "when a nodeRegainedService event is generated, auto-acknowledge all notices based on a nodeLostService event where the nodeid, interfaceid and serviceid match. In addition, send an notification to all parties who received the "down" notice prefixed with the word RESOLVED:".
To disable this feature, set notify="false". "true" is the default. The resolution-prefix can be changed to suit non-English languages or user preference.
A New RADIUS Poller
A New RADIUS Poller
Jonathan Sartin (OGP) has written a new poller to poll RADIUS servers. The relavent configuration in capsd is:
<protocol-plugin protocol="RadiusAuth" class-name="org.opennms.netmgt.capsd.RadiusAuthPlugin" scan="on" user-defined="false"> <property key="timeout" value="3000"/> <property key="user" value="TEST"/> <property key="password" value="test"/> <property key="secret" value="opennms"/> <property key="retry" value="2"/> </protocol-plugin>
Note that this requires that a username of "TEST" with a password of "test" and secret of "opennms" is configured on the server in order for this service to be discovered.
The poller configuration looks similar:
<service name="RadiusAuth" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="3"/> <parameter key="timeout" value="3000"/> <parameter key="user" value="TEST"/> <parameter key="password" value="test"/> <parameter key="secret" value="opennms"/> <parameter key="rrd-repository" value="/var/opennms/rrd/response"/> <parameter key="ds-name" value="radiusauth"/> </service>
This will also store and graph the response time.
SNMP Primary Interface Changes
SNMP Primary Interface Changes
Thanks to Bill Ayres (OGP) we have some new behavior in capsd with respect to the primary SNMP interface.
Previously, there had to be a way to map an IP Address from the ipAddrTable to an ifIndex in the ifTable. This was so interface-level statistics could be matched up with IP addresses. There were cases, however, especially with devices like firewalls where no valid primary interface could be determined and thus no data could be collected from the device.
This code will address this, and OpenNMS will still be able to poll some SNMP data without having the ifIndex mapping.
The MATCH-ANY-UEI Event
The MATCH-ANY-UEI Event
This new event will never be generated internally, but it does serve a useful purpose. Suppose there is a need to get all events from a particular server sent as notifications. By choosing this UEI when building the notification, it will match the UEI of any event generated by the system.
Note that this can be dangerous, especially on systems that receive a lot of SNMP traps. To use this properly, set up a limiting rule, such as:
<notification name="Test-Match-any" status="off"> <uei>MATCH-ANY-UEI</uei> <description>Test</description> <rule>(IPADDR == '10.1.4.10')</rule> <destinationPath>Email-Admin</destinationPath> <text-message>&lt;p>This is a generic notice to match any event UEI that matches the filter rule.&lt;/p&gt; &lt;ul&gt;&lt;li&gt;uei: %uei% </text-message> <subject>Notice #%noticeid%: Match Any event: %uei%</subject> </notification>
This will send a notice on any event where the IP address is 10.1.4.10.
Added Support for the ifAlias Field
Added Support for the ifAlias Field
A number of people use the ifAlias field to add a useful description to a particular interface. Bill Ayres (OGP), Mike Huot (OGP) and Wrolf Courtney are responsible for adding the field to the database and printing it out on various pages in the webUI.
Many Documentation Changes and Installer No Longer Automatic
Many Documentation Changes and Installer No Longer Automatic
DJ Gregor (OGP) has made a lot of changes to our documentation as well as the installer. Please, please read the installation guide and note that the install program that sets up the database, etc., is no longer run when the OpenNMS packages are installed. It will need to be run manually after every install. The command:
$OPENNMS_HOME/bin/install -disU
should get things working most of the time.
JavaMail Bug Fix for Availability Reports
JavaMail Bug Fix for Availability Reports
A bug was fixed with Availability Reports using the JavaMailer class. Some installations of Tomcat included the JavaMail API and therefore our JavaMailer would work with those installations. Some users are experiencing problems because their install does not have the API in the Tomcat common/lib directory. The build task was modified to include the appropriate jar files in our WEB-INF/lib directory in case they were missing.
An enhancement was also made to the JavaMailer include a Mail Transport Agent (MTA). This MTA is free to use and was provided by John Udell (found here: http://zoe.nu/). It's included in the OpenNMS libs as "jmta.jar". This enables OpenNMS to use a Java mailer without needing a relay SMTP host.
A new flag has been added to the javamail-configuration.properties file: "org.opennms.core.utils.useJMTA". It defaults to "true".
Other Minor Enhancements
Other Minor Enhancements
There are a number of other enhancements worth noting:
•
Custom KSC reports can now be accessed directly from the main page.
•
A number of new event definitions have been added, including those for BMC PATROL, MGE UPSs, Network Appliance, Snort, NetBotz, and Compaq Insight Manager.
•
Both the datacollection-config.xml and snmp-graph.properties files (responsible for data collection and display) have been enhanced and reorganized. The default loadavg report for Net-SNMP agents has been replaced with a really nifty CPU report by Ray Van Dolson.
•
OpenNMS will recognize if a web page is listening on the Dell OpenManage port, and there will be a link from the webUI if so.
There are other small fixes and improvements too numerous to list. Please feel free to check out CVS and the CHANGELOG for more.
Changes in OpenNMS 1.1.4
Changes in OpenNMS 1.1.4
Longtime users of OpenNMS will be pleasantly surprised at the speed enhancements of this release. Most of the new code changes focused on performance or our goal of making OpenNMS more purely Java (eliminating the need for JNI calls to C++ code and perl).
Data Collection Queuing System
Data Collection Queuing System
A new queuing system for writing the data collection RRD files has been added. Experimental tests have shown that the I/O subsystem is the bottle neck for Data Collector performance.
In order to increase the capacity of our data collector we have added an intelligent queuing system for all of our RRD Output. This improves performance for us in two ways. One is that it frees up the data collection threads to get back to the work of data collection right away. As a side benefit it also frees up the polling threads that output RRD data related to latency. This makes the data much more accurate.
The second way that the queuing system provides performance improvements is by queuing collected data on a per file basis. Since writing a few extra bytes to an RRD file while its open anyway adds very little to the update time, this causes the average update cost per data point to go down the further the collector gets behind. What this means is that you will not lose any data points if the collector is configured to collect more than you I/O system can read/write without queuing. It just means that the data that is in the files is behind the actual collection.
A last way the queuing system improves data collector performance is by giving priority to non-zero data. On many networks, as much as 60% of the collected data is zero valued. In most situations, data that has remained zero for a long period of time is unimportant data. For this reason we give files with non-zero data points priority over files that have only zero data points. Monitored interfaces that have only zero ifErrors or ifDiscards, for example, will not hold up writing of the data for systems that have positive ifErrors and ifDiscards. Please see $OPENNMS_HOME/etc/rrd-configuration.properties for configurations details.
Thanks to Rackspace and Eric Evans for providing equipment to help us implement this and to General Electric's John Lee and Neeraj Malve for helping to test this.
JRobin Support
JRobin Support
Though the Collection Queuing above provides a great deal of performance benefit, for very high capacity data collection environments it was not sufficient. We have found the JRobin 1.4.0 provides performs better than RRDTool in our environment. The primary reason for this is that JRobin reads a much smaller amount of data on an RRD Open than RRDTool does. This increases throughput on systems like ours that max out the I/O subsystem doing an open, update, and close on a huge number of RRDs. An additional benefit of JRobin is that it is multi-thread enabled (unlike our libjrrd.so shared library that interacts with RRDTool) however this does not impact performance very much because the contention is not the bottle neck. In fact, on some systems that have as many as 100 data collection threads, we found that have as few as 2-10 RRD write threads were sufficient to populate the RRD files.
The only unfortunate part of using JRobin is that the file format for JRobin is not the same as for RRDTool. This means other tools you may be using will not work with JRobin RRD files and will have to converted or replaced. JRobin does have some tools available and you should check out their website at www.jrobin.org to see what is available. Additionally, JRobin supports programmatically all of the features of RRDTool, so it should be easy to write a compatible tool. If you do so, please consider contributing it either to us or to the JRobin team.
The last benefit of JRobin is that is helps us to reach our goal of a 100% Pure Java version of OpenNMS that can work 'out of the box' on any system.
Thanks go to the JRobin team for providing this excellent RRD implementation. Thanks also to Rackspace for providing the equipment to let us implement this.
Filter Parser Performance Enhancements
Filter Parser Performance Enhancements
Thanks to Chris Fedde of On Command, we have found that the SQL queries produced by our filtering code were, at times, extremely inefficient. On a moderately sized network of only 15K interfaces the queries used to define categories could take as long as three minutes on a 4 CPU system. As a result of this, we have reworked the filter parser and now produce much better queries. The equivalent query would now only take about a second on the same system. Thanks a lot to Ted Kaczmarek and Alexander Hoogerhuis for helping us test it.
Delete Node, Interface and Service Improvements
Delete Node, Interface and Service Improvements
There have been a large number of bugs reported with respect to deleting nodes from the OpenNMS GUI. This code has been completely overhauled in OpenNMS 1.1.4. The new strategy has been to mark a node/interface/service deleted rather than actually deleting it. (The node completely removed from the database by Vacuumd discussed below.) This allows any web pages that are currently viewing the node to react properly. Additionally, deletes now happen as database transactions providing for performance and data integrity (i.e. no orphaned interface records) and you are not left with a half-deleted node.
In addition to overhauling node deletion, we have also added the ability to delete interfaces and services. Administrators have a delete link at the top of service and interface detail pages.
All the users of OpenNMS helped by writing defects and complaining about this bug. Special thanks to Ted Kaczmarek, Jonathan Sartin, and Mike Huot for their help testing and characterizing these problems and their solution.
Vacuumd
Vacuumd
Since nodes, interfaces and services are only marked deleted and not actually removed from the database when a delete occurs, some way was needed to ensure that the data actually got removed eventually. To do this Vacuumd was introduced to provide a mechanism to periodically run database maintenance operations. Vacuumd's configuration consists of a set of database statements to be run daily (or whichever period is preferable). There are four maintenance operations provided by OpenNMS by default. These are as follows: delete nodes that have been marked as deleted, delete interfaces that have been marked as deleted, delete services that have been marked as deleted, and delete any event that is not related to a current outage and is older than 6 weeks.
In order to make sure that Vacuumd properly deletes all the data associated with the nodes, interfaces, services or other entries that it deletes we have added cascading delete constraints to the database. With these if you do a 'DELETE FROM nodes WHERE nodeid=11', for example. You delete all the related information, its interfaces, the services on those interfaces, the outages related to the node, the events, etc., etc..
Database Connection 'Leak' Found
Database Connection 'Leak' Found
Though not an actual leak because the connections are garbage collected, we found a problem in the code where database connections were being dropped and left for the garbage collector to clean up. This problem, which occurred primarily during discovery, would result in an abnormally large number of outstanding connections to the database to be cleaned up by the garbage collector. Discovery of large networks caused the number of connections to the database to easily grow beyond the number allowed. Thanks to Chris Fedde and OnCommand for helping us track down this problem.
JavaMail
JavaMail
An OpenNMS objective to become a 100% Java application, requires elimination the following dependencies.
•
/bin/mail
•
Perl
•
Metamail package
These dependencies are used for two functions of the OpenNMS application: Notification and Availability reporting.
Installing a fresh copy of OpenNMS will now use the Java Mail API by default. Upgrade installs will create two new files that the user will have to merge into their existing configurations: destinationPaths.xml.rpmnew and notficationCommands.xml.rpmnew.
The javamail-configuration.properties file should be modified to specify the sender's address and the SMTP server address. This file also provides support for SMTP servers requiring user and password authentication.
There are also major changes to the notificationCommands.xml file. The schema definition for this file has changed requiring that the <command> tag now has an attribute called 'binary' and a value of either "true" or "false". This flag indicates to the OpenNMS notification processes that the command definition is either a system command (as it always has been prior to this release) or an OpenNMS Java class (see deveolper notes below). The 1.1.4 version of this file now has added the following new command definitions:
<command binary="false"> <name>javaPagerEmail</name> <execute>org.opennms.netmgt.notifd.JavaMailNotificationStrategy</execute> <comment>class for sending pager email notifications</comment> <argument streamed="false"> <switch>-subject</switch> </argument> <argument streamed="false"> <switch>-pemail</switch> </argument> <argument streamed="false"> <switch>-tm</switch> </argument> </command>

<command binary="false"> <name>javaEmail</name> <execute>org.opennms.netmgt.notifd.JavaMailNotificationStrategy</execute> <comment>class for sending email notifications</comment> <argument streamed="false"> <switch>-subject</switch> </argument> <argument streamed="false"> <switch>-email</switch> </argument> <argument streamed="false"> <switch>-tm</switch> </argument> </command>
Notice a few changes:
•
The <command> tag now has an attribute called 'binary' that when set to "true" will cause the notification process to attempt to execute a system command specified in the <execute> tag. When not set or set to anything other than "true", the notification process assumes it is an OpenNMS notification class and will instantiate it and execute its 'send()' method. By convention, the "binary" attribute will be set to "false" when new notification classes are implemented.
•
The <substitution> arguments are not used for notification classes but are still supported for notification commands. These "substitution" arguments (allthough not gramatially intuitive) are passed to system commands as a command line argument when the 'binary' attribute is set to "true" and is otherwise ignored.
•
The <execute> tag now allows the specification of an OpenNMS Java class name. This class name must implement the NotificationStrategy interface (see developer notes below). The new JavaMailNotificationStrategy class excepts the following <switch> tags: -subject, -email, -pemail, -tm.
The destinationPaths.xml file has changed making the default email and pager email notifications use the new Java Mail API. All 'email' and 'pagerEmail' <command> tags have been changed to the new 'javaEmail' and 'javaPagerEmail' commands in $OPENNMS_HOME/etc/notificationCommands.xml.
Installer / Build System Improvements
Installer / Build System Improvements
Thanks so much to new OpenNMS committer DJ Gregor for all his hard work on improving the OpenNMS build and install code. Thanks to DJ's efforts the installer has improved greatly and is now written completely in Java removing (along with the JavaMail feature and Dave Hustace) OpenNMS's dependency on Perl.
That said, we do expect some issues with this, as the installer does do a lot of database checks and conversions, and some users have large databases.
Using A Parameter for Notifications
Using A Parameter for Notifications
Some notifications, like one based on a highThresholdExceeded event, would benefit from being able to key off of not only the event UEI, but a value within the event itself.
With 1.1.4, the ability has been added to key off the parameter name and to match it with a particular value.
<notification name="HighThreshold" status="on"> <uei>uei.opennms.org/threshold/highThresholdExceeded</uei> <description>A high threshold event</description> <rule>(IPADDR IPLIKE *.*.*.*)</rule> <destinationPath>Email-Admin</destinationPath> <text-message>A high threshold was reached on data source %parm[#1]% with %parm[#2]% and %parm[#3]% and %parm[#4]%.</text-message> <subject>Notice #%noticeid%</subject> <varbind> <vbname>ds</vbname> <vbvalue>cpu</vbvalue> </varbind> </notification>
This will cause the notification to match if it is a high threshold event involving the data source name of "cpu" only.
Note that you must use the name of the parameter, and you can only use one. There is a TODO to add the ability to use more than one parameter for the match and to use a particular parameter number instead of just the name.
Other Improvements/Changes/Bug Fixes
Other Improvements/Changes/Bug Fixes
Here is a small list of other improvements in 1.1.4:
•
The OpenNMS Group is partnering with the creators of the SNMP Informant Windows SNMP agent (formally SNMP4PC), and so a number of SNMP Informant data collections and reports have been added.
•
A bug was fixed with respect to the RTC Categories section which could cause the services of new nodes to be counted more than once.
•
To make better use of Bill Ayres' displayCategory field in the Assets table, a new event was created that will update RTC when the Assets table is changed (which will cause such changes to be reflected without a restart).
•
Also to make this work better, new nodes are created with an empty asset record. Thus queries like displayCategory != "test" will work.
•
Michael Huot added some code that causes the webUI to turn to light blue, similar to "Calculating ..." when the webUI loses connectivity with OpenNMS. Code has also been added so the webUI will attempt to reconnect to OpenNMS when this happens. This should remove the dependency on needing to restart Tomcat after restarting OpenNMS.
•
RPM dependencies have been fixed (bug #906). A packaging error caused previous releases to only include a subset of package dependencies. Some dependencies have also been fixed for Mandrake distributions (bug #933).
•
A generalized solution has been implemented for choosing a proper Java Runtime Environment at runtime. See $OPENNMS_HOME/bin/runjava -h for details.
•
The OpenNMS startup script was rewritten to be more cross-platform friendly and uses the JRE chosen by runjava.
•
Upgraded to the latest PostgreSQL JDBC driver, pg74.215.jdbc3.jar.
•
WebUI to OpenNMS communication has been changed to use a separate connection for each request, instead of a single connection that persists until Tomcat is restarted (or the webapp is reloaded). This eliminates exceptions that are thrown when certain administrative actions are performed (e.g.: adding a new node through the webUI) if OpenNMS is restarted without restarting Tomcat. See bug #897.
Changes in OpenNMS 1.1.3 and above
Changes in OpenNMS 1.1.3 and above
A tremendous amount of work has been done "under the covers" to OpenNMS, and the following features were added in 1.1.3:
Support for Duplicate IP Addresses
Support for Duplicate IP Addresses
Prior to this release, the algorithm that OpenNMS used to determine if a particular interface belonged to a particular node was simple. An SNMP walk was done on the device, and all of the IP addresses on that device were associated with the node. If that walk discovered a "duplicate" address, say from a private network or some backup link, it would assume that all of the addresses on that device belonged to the device that was discovered with that IP address first.
This could result in "merged" nodes, especially in environments with HSRP.
This release now supports duplicate IP addresses. The nodes will not be merged and an event will be generated.
Note that networks are not supposed to have duplicate IP addresses. In other words, if there are two "10.1.1.1" addresses on a network, and OpenNMS sends a "ping" to 10.1.1.1, it will assume that a response means that interface 10.1.1.1 is "up", regardless of which "10.1.1.1" interface responds.
Since this feature was mainly written to support inactive or unreachable interfaces that were discovered by SNMP, this behavior should not present a problem, although it does have the added benefit of being able to monitor highly available IP addresses.
For example, if your website lives at 10.1.1.1, which lives on two devices, as long as an HTTP request to 10.1.1.1 is answered (by either machine) OpenNMS will mark the service as up.
New Asset Configuration "Categories"
New Asset Configuration "Categories"
The rules uses in categories and filter rules, usually along the lines of <rule>IPADDR IPLIKE *.*.*.*</rule> are actually quite flexible, and can be built on almost anything in the database. However it would be nice to easily place a particular device into a category for display on the main page, notifications, etc..
There are four categories:
•
Display Category (database field displayCategory): This is to be used for grouping devices into a particular category.
•
Poller Category (database field pollerCategory): This is to be used to define devices in a particular poller package.
•
Notification Category (database field notifyCategory): This could be something like "serverAdmin" or "networkAdmin" to be used for directing notifications.
•
Threshold Category (database field thresholdCategory): This is to be used to define devices in a particular thresholding package.
Note that there is no "hard coded" meaning to these categories, you could use "poller" for "threshold" etc.. They are just labeled for convenience.
How would you use them? Well, you would need to modify the <filter> or <rule> tags in the configuration files. Suppose you had two types of polling packages, like "Gold" and "Silver". You would then have a filter like <filter>pollerCategory == "Gold"</filter> for that package. By just adding the name "Gold" or "Silver" to the proper category on the asset screen you can place a particular device into that poller package.
Note that once you have sorted all of your devices, you will need to restart OpenNMS for the poller to reload the proper configuration.
Added an XML RPC daemon
Added an XML RPC daemon
One user of OpenNMS has integrated it into their provisioning/billing/support package. They use multiple instances of OpenNMS to poll the services on their network, and all of these instances talk to a single database. By sending events to eventd, they can affect changes in how these devices are polled (without a restart).
In order to alert this system to events from OpenNMS, like "nodeLostService", we send events out via xmlrpcd.
Unfortunately, there is not time to describe in detail how this system works, but it will be documented as soon as possible (the hope is by 1.2).
Support for Java 1.4.2
Support for Java 1.4.2
People who used previous versions of OpenNMS on Java 1.4.2 found out that it would use up all of the resources on the system and then die. This turned out to be due to a very obscure bug in Java. The code was re-written to avoid this and now we recommend that OpenNMS is run on 1.4.2.
MIB Compiler for Data Collection
MIB Compiler for Data Collection
John Rodriguez has created a great MIB Compiler to convert native MIB information into a format that can be used by datacollection-config.xml.
We hope to import into the webUI in the future. But for now it is located in the contrib directory under mibparser.
In that directory is the complete code (in Java) as well as a helpful README. In a nutshell this is how you would use it.
Change into the dist directory and run the parseMib.sh wrapper script. The format is:
Usage: parseMib.sh <MIB File 1> [<MIB file 2>...] Example: parseMib.sh RFC-1213.my
Thus:
$ ./parseMib.sh /usr/share/snmp/mibs/RFC1213-MIB.txt Looking for a good java... Using java in user's path... Checking Java version for 1.4+... Version is: java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) Checking for JAVA_HOME... JAVA_HOME not set, trying to find it... JAVA_HOME set to: . Calling parser...
will generate output that is very familiar to people used to modifying datacollection-config.xml. For example:
<mibObj oid=".1.3.6.1.2.1.11.1" instance="0" alias="snmpInPkts" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.2" instance="0" alias="snmpOutPkts" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.3" instance="0" alias="snmpInBadVersions" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.4" instance="0" alias="snmpInBadCommunityNamesTOOLONG" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.5" instance="0" alias="snmpInBadCommunityUsesTOOLONG" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.6" instance="0" alias="snmpInASNParseErrs" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.8" instance="0" alias="snmpInTooBigs" type="Counter" /> <mibObj oid=".1.3.6.1.2.1.11.9" instance="0" alias="snmpInNoSuchNames" type="Counter" />
This could be put into a new MIB group, snmp-stats or some such, directly without having to explore the MIB by hand.
I love this app.
There are some caveats. In using this I have sometimes seen errors where the MIB compiler could not find a referenced variable because it is defined in another MIB file. Simply list it first in the list of MIBs to parse.
I have also come across some MIBs that define custom object types and the parser does not handle it all that well. It is often possible just to delete the offending line from the MIB file (after making a copy of course) and try it again.
OpenNMS can only handle numeric data types, or DisplayStrings that can be converted into numbers, so keep that in mind when choosing which values to collect.
We use RRDTool, and RRDTool has a 19 character limit on filenames (the part before .rrd). Since the "alias" field becomes the file name, you cannot have an alias longer than 19 characters. The parser will append "TOOLONG" to overlength aliases, and you can edit them by hand (it would be possible to truncate the name, but you cannot have duplicate aliases and that might occur).
Finally, OpenNMS can handle a numeric instance (0, 1, 2, ... etc.) or an instance of "ifIndex". So an instance of "tcpConnState" would cause an error.
New Build System
New Build System
Our goal is to make OpenNMS as pure Java as possible. However, for a variety of reasons we cannot do that yet. When OpenNMS was started, ant (the program used to build other Java programs) had limitations that had to be worked around. This resulted in a workable, but somewhat confusing, build system.
DJ Gregor (building on work started by Edwin Buck) rebuilt the build system, making it almost pure ant. This was great for those doing development, so hats off to Deej and Edwin.
New NTP Poller
New NTP Poller
Mike Huot has written a new NTP poller. You will notice it in capsd-configuration.xml and poller-configuration.xml. Hat off to Mike.
Nice Little Things
Nice Little Things
Small additions that deserve mention:•APC data collection was added.•Added "maxval" and "minval" attributed to the mibObj definition in datacollection-config.xml to help eliminate spikes.•Started improving start up times on large systems.•Added a sort to KSC reports.•Added an initial delay to notification paths.
Bug Fixes
Bug Fixes
We have lots of bug fixes. I am really tired. Check out the CHANGELOG [http://cvs.sourceforge.net/viewcvs.py/opennms/opennms/CHANGELOG?rev=1.97&view=auto].
Changes in OpenNMS 1.1.2 and Above
Changes in OpenNMS 1.1.2 and Above
The following features were added in 1.1.2:
Poller Improvements
Poller Improvements
There are three new pollers available:
Ssh:
Previously, the SSH service was polled and discovered using the generic TCP class. This worked fine, except that SSH expects a version to be sent with the query. This causes numerous logs, thus the TCP class was modified into an SSH class that sends the correct version string.
JDBC:
The database pollers also use the TCP class to connect to well known ports. Jose Nunez Vicente Zuleta created a poller that uses the particular JDBC database driver to make a connection, get the system catelogs, and if successful, mark the database service as "up". Since this requires a valid username and password that can access the database, it is not the default class, but it is pretty simple to set up.
In order to automatically detect and monitor databases, a few changes need to be made to both the network and the OpenNMS configuration. First, be sure that the username and password you plan to use actually works from the OpenNMS server. This will involve changes to pg_hba.conf for PostgreSQL, and I am not sure about others.
Second, you will need to insure that you have a jar file with the JDBC driver for your particular database. Copy it to $OPENNMS_HOME/lib (the one for PostgreSQL is already included).
Okay, now you need to modify the capsd configuration to discover the service and modify the poller configuration to poll the service.
capsd: Here is an example for Sybase:
<protocol-plugin protocol="Sybase-JDBC" class-name="org.opennms.netmgt.capsd.JDBCPlugin" scan="on"> <property key="user" value="sa"/> <property key="password" value="XXXX"/> <property key="retry" value="3"/> <property key="timeout" value="5000"/> <property key="driver" value="com.sybase.jdbc2.jdbc.SybDriver"/> <!-- jdbc:sybase:Tds::/ --> <property key="url" value="jdbc:sybase:Tds:OPENNMS_JDBC_HOSTNAME:4100/tempdb"/> </protocol-plugin>
and one for MySql:<protocol-plugin protocol="MySQL-JDBC" class-name="org.opennms.netmgt.capsd.JDBCPlugin" scan="on"> <property key="user" value="root"/> <property key="password" value="XXXX"/> <property key="retry" value="3"/> <property key="timeout" value="5000"/> <property key="driver" value="org.gjt.mm.mysql.Driver"/> <!-- jdbc:mysql://[<:3306>]/ --> <property key="url" value="jdbc:mysql://OPENNMS_JDBC_HOSTNAME:3306/mysql"/> </protocol-plugin>
and one for PostgreSQL:
<protocol-plugin protocol="PostgreSQL-JDBC" class-name="org.opennms.netmgt.capsd.JDBCPlugin" scan="on"> <property key="user" value="opennms"/> <property key="password" value="opennms"/> <property key="retry" value="3"/> <property key="timeout" value="5000"/> <property key="driver" value="org.postgresql.Driver"/> <!-- jdbc:postgresql:[[:<5432>/]] --> <property key="url" value="jdbc:postgresql://OPENNMS_JDBC_HOSTNAME:5432/opennms"/> </protocol-plugin>
Note that the service names for all three of these examples have "-JDBC" added to the end of their names. This means you can run them separately from the standard database protocols, or if you like, you can completely replace the standard protocols. In fact, if you wish, you can use the standard port check in capsd, and then use the JDBC poller configuration to do the actual polling.
Here are the poller configuration examples:
<service name="Sybase-JDBC" user-defined="false" interval="6000" status="on"> <parameter key="user" value="sa"/> <parameter key="password" value="XXXX"/> <parameter key="timeout" value="3000"/> <parameter key="driver" value="com.sybase.jdbc2.jdbc.SybDriver"/> <!-- jdbc:sybase:Tds::/ --> <parameter key="url" value="jdbc:sybase:Tds:OPENNMS_JDBC_HOSTNAME:4100/tempdb"/> </service>
<service name="MySQL-JDBC" user-defined="false" interval="6000" status="on"> <parameter key="user" value="root"/> <parameter key="password" value="XXXX"/> <parameter key="timeout" value="3000"/> <parameter key="driver" value="org.gjt.mm.mysql.Driver"/> <!-- jdbc:mysql://[<:3306>]/ --> <parameter key="url" value="jdbc:mysql:// OPENNMS_JDBC_HOSTNAME:3306/mysql"/> </service>
<service name="PostgreSQL-JDBC" user-defined="false" interval="9000" status="on"> <parameter key="user" value="opennms"/> <parameter key="password" value="opennms"/> <parameter key="timeout" value="9000"/> <parameter key="driver" value="org.postgresql.Driver"/> <!-- jdbc:postgresql:[[:<5432>/]] --> <parameter key="url" value="jdbc:postgresql://OPENNMS_JDBC_HOSTNAME:5432/opennms"/> </service>
One more thing in the poller-configuration file, you will need to add <monitor> tags at the bottom:
<monitor service="Sybase-JDBC" class-name="org.opennms.netmgt.poller.monitors.JDBCMonitor"/> <monitor service="MySQL-JDBC" class-name="org.opennms.netmgt.poller.monitors.JDBCMonitor"/> <monitor service="PostgreSQL-JDBC" class-name="org.opennms.netmgt.poller.monitors.JDBCMonitor"/>
Hats off to Jose for this work.
General Purpose Script Poller:
Bill Ayres has written a poller that will execute a script, and based on the response from that script it will mark the service as being "up" or "down", called the "General Purpose" or "Gp" Poller. He has used it to monitor RADIUS servers, for example.
GpPlugin and GpMonitor work much like TcpPlugin and TcpMonitor in that you can use them to define as many custom services as you need, each with a unique service name.
GpPlugin and GpMonitor call an external script or program to test a particular service. The script will be passed the IP address of the interface OpenNMS is testing ( as --hostname [IP Address]), followed by the timeout (as --timeout [timeout]), followed by any optional arguments that may need to passed.
The script is expected to return a string as standard output which is then compared to the banner property or parameter to determine success or failure of the test.
The timeout is implemented in GpPlugin and GpMonitor. However, some scripts may want to know how long OpenNMS is going to wait for a reply, so the timeout value is passed to the script, and can be ignored by the script if it is not needed.
GpPlugin and GpMonitor also check the exit status of the script or program. If it is not zero, then the test fails. They will also gather and log any standard error output from the script, but the presence of error output does not prevent the test from succeeding if the banner matches the standard output.
Example poller parameters are shown below. All of these are optional except script, which is required, and will cause an exception to be logged if it is missing.
Example plugin properties are also shown below. All of these are optional except script, which is required, and will cause an exception to be logged if it is missing.
These programs use the exec method from Java's Runtime class. Exec is known to have pitfalls. (See When Runtime.exec() won't [http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html]) Also, exec does not have a built-in timeout feature. In deciding what to do about these shortcomings, Bill discovered that Scott McCrory has already done it with his ExecRunner class. ExecRunner and StreamGobbler are at SourceForge [http://sourceforge.net/] as part of Spumoni [http://spumoni.sourceforge.net/].
One more word about the timeout. ExecRunner expects the timeout in integer seconds, not milliseconds, and a value of zero means wait indefinitely. To avoid confusion, Bill maintained the OpenNMS practice of specifying the timeout in milliseconds. Before passing it on to ExecRunner, it gets converted to seconds in the following manner: Zero remains zero, 1 thru 1999 gets converted to 1 second, 2000 thru 2999 -> 2 seconds, 3000 thru 3999 -> 3 seconds, etc..
Included in contrib is a simple perl test script, gptest.pl, that is handy for testing, since it is easy to edit and change its behaviour.
To implement Gp, add the following entries, substituting your information as needed.
For capsd configuration:
<protocol-plugin protocol="GPtest" class-name="org.opennms.netmgt.capsd.GpPlugin" scan="on" user-defined="true"> <property key="script" value="/opt/OpenNMS/contrib/gptest.pl"/> <property key="banner" value="success"/> <property key="args" value="caps-arg1 caps-arg2"/> <property key="timeout" value="3000"/> <property key="retry" value="1"/> </protocol-plugin>
And for poller configuration:
<service name="GPtest" interval="300000" user-defined="false" status="on"> <parameter key="script" value="/opt/OpenNMS/contrib/gptest.pl"/> <parameter key="banner" value="successful"/> <parameter key="args" value="poll-arg1 poll-arg2"/> <parameter key="retry" value="1"/> <parameter key="timeout" value="2000"/> <parameter key="rrd-repository" value="/var/opennms/rrd/response"/> <parameter key="ds-name" value="GPtest"/> </service>
and the monitor service entry:
<monitor service="GPtest" class-name="org.opennms.netmgt.poller.monitors.GpMonitor"/>
Hats off to Bill for this work, and to Scott for ExecRunner.
Script Daemon
Script Daemon
Speaking of scripts, Jim Doble has written a daemon that will execute scripts based on events received or generated by OpenNMS, called ScriptD. This process, governed as usual from a configuration file, allows one to generally or specifically execute actions based on events in OpenNMS.
The scripting language, as I understand it, is beanshell [http://www.beanshell.org/]. As Jim writes: “You will notice that BeanShell is a lot like Java, but with some relaxed syntax. For example you do not have to define types for your variables, and attributes for which there are simple get methods can be accessed as properties (i.e. you can say event.uei or event.getUei() interchangably.) ”
There are 4 types of scripts that can be run: start-script, reload-script, stop-script, and event-script. When ScriptD starts it will run all of the commands in the <start-script> tags. Likewise, when ScriptD stops, it will run all of the commands in the <stop-script> tags. Also, there is a new event, uei.opennms.org/internal/reloadScriptConfig, which when received will run all of the <reload-script> tags.
The final script type, <event-script> gets run when events are received. Event scripts can have one or more UEI elements, which specify the UEI's for which that script should run. If no UEI element is present, the script will run for all events.
The scripts can make use of the SnmpTrapHelper class, which is a utility to make it easier to manipulate traps from a script.
There is an example scriptd-configuration.xml file included in the $OPENNMS_HOME/etc directory.
If you want to forward all SNMP traps to another machine as an SNMP trap, you would use the following event script:
<event-script language="beanshell">

import org.opennms.core.utils.ThreadCategory; import org.apache.log4j.Category;

ThreadCategory.setPrefix("scriptd-event"); Category log = ThreadCategory.getInstance();

event = bsf.lookupBean("event");

if (event.snmp != null) { log.debug("forwarding a trap"); snmpTrapHelper.forwardTrap(event, "10.1.1.1", 162); }

</event-script>
This will forward the trap to 10.1.1.1, port 162. Note that the event will have SNMP information if the event is indeed an SNMP trap. Since internal OpenNMS events do not, you could use that to forward OpenNMS events as an SNMP trap to another system:
<event-script language="beanshell">

import org.opennms.core.utils.ThreadCategory; import org.apache.log4j.Category;

ThreadCategory.setPrefix("scriptd-event"); Category log = ThreadCategory.getInstance();

event = bsf.lookupBean("event");

if (event.snmp == null) {

try {

log.debug("Forwarding an OpenNMS event.");

SnmpPduTrap trap = snmpTrapHelper.createV1Trap(".1.3.6.1.4.1.5813.1", "10.1.1.16", 6, 1, 0);

t_dbid = new Integer(event.dbid).toString(); if (t_dbid != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.1", "OctetString", "text", t_dbid); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.1", "OctetString", "text", "null"); if (event.distPoller != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.2", "OctetString", "text", event.distPoller); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.2", "OctetString", "text", "null"); if (event.creationTime != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.3", "OctetString", "text", event.creationTime); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.3", "OctetString", "text", "null"); if (event.masterStation != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.4", "OctetString", "text", event.masterStation); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.4", "OctetString", "text", "null"); if (event.uei != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.6", "OctetString", "text", event.uei); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.6", "OctetString", "text", "null"); if (event.source != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.7", "OctetString", "text", event.source); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.7", "OctetString", "text", "null"); t_nodeid = new Long(event.nodeid).toString(); if (t_nodeid != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.8", "OctetString", "text", t_nodeid); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.8", "OctetString", "text", "null"); if (event.time != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.9", "OctetString", "text", event.time); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.9", "OctetString", "text", "null"); if (event.host != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.10", "OctetString", "text", event.host); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.10", "OctetString", "text", "null"); t_interface = event.getInterface(); if (t_interface != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.11", "OctetString", "text", t_interface); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.11", "OctetString", "text", "null"); if (event.snmphost != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.12", "OctetString", "text", event.snmphost); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.12", "OctetString", "text", "forge.opennms.com"); if (event.service != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.13", "OctetString", "text", event.service); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.13", "OctetString", "text", "null"); if (event.descr != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.16", "OctetString", "text", event.descr); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.16", "OctetString", "text", "null"); if (event.severity != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.18", "OctetString", "text", event.severity); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.18", "OctetString", "text", "null"); if (event.pathoutage != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.19", "OctetString", "text", event.pathoutage); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.19", "OctetString", "text", "null"); if (event.operinstruct != null) snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.20", "OctetString", "text", event.operinstruct); else snmpTrapHelper.addVarBinding(trap, ".1.3.6.1.4.1.5813.2.20", "OctetString", "text", "null");

snmpTrapHelper.sendTrap("public", trap, "10.1.1.15", 162);

}

catch (e) { sw = new StringWriter(); pw = new PrintWriter(sw); e.printStackTrace(pw); log.debug(sw.toString()); } }

</event-script>
This will send an newly defined OpenNMS trap with the important event information embedded as varbinds.
If you wanted to limit the forwarded OpenNMS events to nodeLostService and nodeRegainedService, you can add a <uei> tag:
<event-script language="beanshell"> <uei name="uei.opennms.org/nodes/nodeLostService"/> <uei name="uei.opennms.org/nodes/nodeRegainedService"/>
To the first part of the <event-script> tag.
Hats off to Jim for this work.
Maps
Maps
Okay, let us get this out in the open. I do not care for maps in network management. Yes, they are nice looking, but truely useful maps cannot be automated, and the manual process of generating maps takes more time than they are worth.
That said, my opinions do not mean much in this project (grin) and if someone is willing to put in some work and write solid code I am more than willing to accept it. Thus, Derek Glidden decided to go and write a mapping system for OpenNMS.
This will display the nodes as icons, and the current availability is displayed in color underneath it. You can view it in a tree mode or just as a list of icons, and the image will automatically refresh. The parenting relationships have to be manually set.
The image is built and displayed using Scalable Vector Graphics (SVG). I think this is a great decision, but the downside is that the only SVG viewer I was able to get to work was from Adobe for Internet Explorer on Windows. I was not able to get SVG to work with Mozilla or Safari (on Mac). Using the system on IE was very clean and fast.
There is the option to convert the SVG image to a PNG image. This is extremely processor intensive, takes a long time on a network of any size, and often fails. It is not recommended.
Scared yet? (grin)
For these reasons I am treating the current map implementation as contributed code (i.e. not supported). It is hoped, however, that Derek and others will work to make more improvements to the system.
Okay, to get started, read the map.disable file in $OPENNMS_HOME/etc. You will need to copy this file to map.enable. This will add a "Map" menu item in the WebUI.
You will also have to make some changes to the tomcat4 configuration. First, you need to set headless equal to true, and second you should probably increase the memory available to Tomcat (especially if you are trying to use the SVG to PNG transcoder). OutOfMemory exceptions in Tomcat are indicative of a too small memory setting when trying to render the map.
I know this whole things sounds a bit negative, but that is no reflection on Derek's work. He wrote very clean code and I like the architecture (SVG especially) that he came up with. The icons are cool, too. So hats off to Derek.
But I am bracing myself for the onslaught of questions like “"Can I add a background?"”, “"Can I change the icons based on systemOID?"”, and “"Can I make submaps?"”. Patience, please.
Nice Little Things
Nice Little Things
The following little changes and improvements have been made:
•
Added RFC2325 to the data collection configuration
•
Added a "bits" report (to replace bytes) and made it the default report for KSC reports.
•
Added the ability to define a "null" filter (can speed up OpenNMS starting)
•
Added new Cisco and UCD-SNMP reports (Thanks Tony and Stuart)
•
Added new trap definitions for IBM and Intel
Bugs
Bugs
As we move toward the next stable release of OpenNMS, a number of bugs have been fixed, including:
•
Added a check to handle null terminated strings in traps (Thanks Dave W.)
•
Corrected issues with day/week/month/year buttons in WebUI on various browsers
•
Changed the open count in notifications to reflect those for the user instead of the system
•
Fixed a typo in mail.pl in the contrib directory
•
Added a small fix to the HTTP and HTTPS monitors that could cause a ClassCastException (Thanks Jim)
•
Added an ORDER BY statement to insure that categories reflect the correct values.
•
Added code to explicitly close sockets in plugins and monitors (see the Known Issues below for Java 1.4.2)
•
Bug 708: Fixed issues with viewing events when nodes are deleted
•
Bug 715: Added security roles to web.xml (Thanks DJ)
•
Bug 741: Fixed issues with the SNMP admin page and null issnmpprimary values.
•
Bug 748: Added code to catch rrdUpdate exceptions that could cause false nodeDown events
•
Bug 752: Fixed a bug that caused certain rules to match all events
Changes in OpenNMS 1.1.1 and Above
Changes in OpenNMS 1.1.1 and Above
The following features were added in 1.1.1:
Trap Handling
Trap Handling
SNMP Traps will now be associated with nodes if the IP address in the trap matches a known IP address in the database.
If the IP Address is not known, OpenNMS will generate a newSuspect event to attempt to discover the device. This behavior can be disabled in the trapd-configuration.xml file.
Added new trap definitions for Dell OpenManage, Foundry Networks and ADIC. Also added an updated mib2opennms program which improves the look of the output.
Reports
Reports
Added a new custom reporting module which allows one to create and save custom performance reports. It is called the Key SNMP Custom (KSC) Reporting Tool.
Added buttons on the standard Performance and Response Time pages to allow the range to be changed between the last Day/Week/Month/Year.
Response Time
Response Time
Added the ability to collect response time on the following pollers: Citrix, FTP, HTTPS, IMAP, POP3, SMTP and TCP.
The RRAs for Response Time data are now part of the poller configuration file.
Web Improvements
Web Improvements
There is now a Response Time link on the node and interface pages.
If a node or interface supports HTTP, there is now a link to that service.
Added a two minute refresh to the event listing page.
Other Features
Other Features
Added non-blocking I/O to the HTTPS service. Now all monitors and plug-ins should be non-blocking.
If you set the IP Address in a poll-outages calendar to "match-any" it will match all addresses in the poller package that uses that calendar.
Increased the size of the contactinfo field in the usersnotified table, and changed create.sql to make this easier.
Fixed Bugs
Fixed Bugs
Fixed numerous bugs, including 650 where "down" events could be written to the database after the corresponding "up" event. See the CHANGELOG for a full list.
Tomcat4
Tomcat4
For a variety of reasons, OpenNMS 1.1.1 and beyond will require Tomcat4 version 4.1.18 or higher.
Changes in OpenNMS 1.1.0 and Above
Changes in OpenNMS 1.1.0 and Above
There were many changes to OpenNMS between 1.0 and 1.1. Here are a few listed by functional area.
Events and Event Handling
Events and Event Handling
The events and notifications part of OpenNMS saw the most changes with 1.1.0. First, there was a new tag added to the eventconf.xml file called <event-file>. This allows for external files to be included in the event configuration.
Also, the order in which events appear is now strictly enforced. When trying to match an event with an event definition, OpenNMS takes the first match. The events in the eventconf.xml are read first, followed by the files identified by <event-file> tags (in the order in which they are listed). In the configuration that ships with OpenNMS, the file with the default events is loaded last. Be sure to add any custom files before that one.
Prior to this release, the SNMP generic traps 0-5 (coldStart, warmStart, linkDown, etc.) were hard-coded. Now they must be defined (and that definition is included in the default events file), but this allows for generic traps other than type 6 to be configured differently for, say, different hosts.
Speaking of event files, over 2750 events were added out of the box, including those from vendors such as Cisco, HP and 3Com. Please let us know if anything is misconfigured or if we need to add some events.
The ability to configure events based on parameters (varbinds) was also added. This is best demonstrated with an example. In the new HP event definitions there is an event called hpicfFaultFinderTrap. It is defined as: <event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.11.2.14.12.1</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>5</mevalue> </maskelement> </mask> <uei>uei.opennms.org/vendor/HP/traps/hpicfFaultFinderTrap</uei> <event-label>HP-ICF-FAULT-FINDER-MIB defined trap event: hpicfFaultFinderTrap</event-label> <descr> <p>This notification is sent whenever the Fault Finder creates an entry in the hpicfFfLogTable.</p> <table> <tr> <td><b>hpicfFfLogFaultType</b></td> <td>%parm[#1]%</td> <td><p> badDriver(1) badXcvr(2) badCable(3) tooLongCable(4) overBandwidth(5) bcastStorm(6) partition(7) misconfiguredSQE(8) polarityReversal(9) networkLoop(10) lossOfLink(11) portSecurityViolation(12) backupLinkTransition(13) meshingFault(14) fanFault(15) rpsFault(16) stuck10MbFault(17) lossOfStackMember(18) hotSwapReboot(19) </p></td> </tr> <tr> <td><b> hpicfFfLogAction</b></td> <td>%parm[#2]% </td> <td><p;> none(1) warn(2) warnAndDisable(3) warnAndSpeedReduce(4) warnAndSpeedReduceAndDisable(5) </p></td;> </tr> <tr> <td><b>hpicfFfLogSeverity</b></td> <td>%parm[#3]%</td> <td><p> informational(1) medium(2) critical(3) </p></td;> </tr> <tr> <td><b> hpicfFfFaultInfoURL</b></td> <td>%parm[#4]%</td> <td><p;></p></td;> </tr> </table> </descr> <logmsg dest='logndisplay'><p>HP Event: ICF Hub Fault Found.</p></logmsg> <severity>Warning</severity> </event>
Note that the third parameter denotes the severity of the event. By default this event has a severity of Warning, but what if it was desired to make the "critical" event a severity of Major? Using the new varbind extension to the mask tag: <event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.11.2.14.12.1</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>5</mevalue> </maskelement> <varbind> <vbnumber>specific</vbnumber> <vbvalue>5</vbvalue> </varbind> </mask> <uei>uei.opennms.org/vendor/HP/traps/hpicfFaultFinderTrap</uei> <event-label>HP-ICF-FAULT-FINDER-MIB defined trap event: hpicfFaultFinderTrap</event-label> <descr> <p>This notification is sent whenever the Fault Finder creates an entry in the hpicfFfLogTable.</p> <table> <tr> <td><b>hpicfFfLogFaultType</b></td> <td>%parm[#1]%</td> <td><p> badDriver(1) badXcvr(2) badCable(3) tooLongCable(4) overBandwidth(5) bcastStorm(6) partition(7) misconfiguredSQE(8) polarityReversal(9) networkLoop(10) lossOfLink(11) portSecurityViolation(12) backupLinkTransition(13) meshingFault(14) fanFault(15) rpsFault(16) stuck10MbFault(17) lossOfStackMember(18) hotSwapReboot(19)</p></td> </tr> <tr> <td><b>hpicfFfLogAction</b></td> <td>%parm[#2]%</td> <td><p> none(1) warn(2) warnAndDisable(3) warnAndSpeedReduce(4) warnAndSpeedReduceAndDisable(5)</p></td> </tr> <tr> <td><b>hpicfFfLogSeverity</b></td> <td>%parm[#3]%</td> <td><p;> informational(1) medium(2) critical(3)</p></td;> </tr> <tr> <td><b>hpicfFfFaultInfoURL</b></td> <td>%parm[#4]%</td> <td><p;></p></td;> </tr> </table> </descr> <logmsg dest='logndisplay'><p>HP Event: ICF Hub Fault Found.</p></logmsg> <severity>Major</severity> </event>
This event, when added before the previous event since it is more specific, will try to match on the enterprise id, the generic trap value of 6, the specific trap value of 5 and the value of the third parameter, or varbind, of 3.
There was also the addition of a low and high threshold rearm events. When a threshold is exceeded in consecutive polls equal to the trigger number, the threshold event is generated. Another event will not be generated until the polled value drops below the rearm number. The rearm event is thus similar to a "cleared" event. Since the first parameter passed with the threshold event is the data source name, using the "varbind" tag above, each data source can now have its own event.
One of the more noticeable changes is that the Unique Event Identifier no longer contains "http://". The original intent was that the UEI would act something like an XML namespace, but in practice it is just a label, so the "http://" was removed to avoid confusion.
Notifications also received some attention with this release. Due to popular demand, the tags %nodelabel% and %interfaceresolve% are now available. The former will display the label of the nodeid associated with the event, and the latter will attempt to resolve the name associated with the IP Address of the interface of the event.
In notifd-configuration.xml there are now two new attributes. In the global properties, there is "match-all". By default, this is set to false, which means that the first notification that matches an event will be the only notification sent. If it is set to true, then all notifications that match a given event will be sent. (Thanks Nick) In the auto-acknowledge section, there is a new attribute called "clear". By adding "clear=true" to the auto-acknowledge tag, both the event being auto acknowledged and the event that caused the acknowledgement will be acknowledged. Thus the "up" event that clears a "down" will also be cleared.
In addition to these enhancements, various bugs were fixed. Notification rules now actually work, and you can filter node level events via IP address. Also, threshold events can now generate notifications.
Polling
Polling
The biggest change to polling would have to be the addition of response time information for DHCP, DNS, HTTP and ICMP based pollers. Similar to data collection, the response time information can be graphed and it can have threshold alarms placed on it.
Also, all of the plugins and monitors (except HTTPS) have been re-written to use the non-blocking I/O available in the 1.4 JDK.
Discovery
Discovery
There has been some discussion on how OpenNMS determines node labels. Currently, this is set to the resolved SNMP Primary Interface IP Address. However, it is common practice on routers to have a software-loopback address. OpenNMS will now discover such interfaces (as long as they do not have an address that starts with 127) and mark them as the primary SNMP Interface. Note that no services will be polled on such interfaces.
The Web User Interface
The Web User Interface
A few changes were made to the WebUI. There is now a webui-colors.xml file that will allow for dynamic changes to the background colors used in the categories list on the main page (more pages to follow). Also under "Admin" the ability to delete nodes was added.
In addition, there is a new Admin page that will allow one to choose which non-IP interfaces will be used in data collection. By setting the snmpStorageFlag in datacollection-config.xml to "select" (now the default), OpenNMS will only store data from those interfaces that could serve as a primary SNMP interface. One can then select which other interfaces to collect on using the GUI. The previous values of snmpStorageFlag ("primary" and "all") still work.
Also, the "Destination Path" interface now has the ability to choose NOT to include a service (thanks Nick) which will create a rule like "match the events where service is NOT FTP", and by placing the mouse over the categories on the main page, the last time the category was updated should be displayed.
Fixed Service Deletion in Downtime Model
Fixed Service Deletion in Downtime Model
The poller downtime model allows for a service to be deleted if it has been down for a certain amount of time. This did not work correctly and has been fixed.
Reduced the Amount of Data Initially Collected from the ifTable
Reduced the Amount of Data Initially Collected from the ifTable
During discovery, the ifTable is collected from each device that is found to support SNMP. On some HP switches, this would fail due to a limitation on the SNMP maximum packet size. All non-essential ifTable elements were removed from the request that appears to resolve the problem.
Removed Spaces in Notification Path Names
Removed Spaces in Notification Path Names
Spaces in Notification Path names have been known to cause problems. The Web UI was modified to disallow spaces in path names. Bug 657.
Fixed the AM/PM Ordering on Performance Report UI.
Fixed the AM/PM Ordering on Performance Report UI.
In the Custom Performance Report Web UI, 11 PM was followed by 12 PM, when it should have been 12 AM. This has been corrected. Bug 515.
Added a "contrib" Directory
Added a "contrib" Directory
The "contrib" directory now contains code, such as nifty utilities, that exists outside of the main OpenNMS source but may prove useful. One such example is Tomas Carlsson's "mib2opennms" program. These programs are not supported.
Removed Duplicate Entries in capsd-configuration.xml
Removed Duplicate Entries in capsd-configuration.xml
Both LDAP and Citrix protocol plug-ins were listed twice. This would slow down the capabilities scan considerably.
Updated Data Collection and Graphing
Updated Data Collection and Graphing
Added new entries to datacollection-config.xml and snmp-graph.properties.
Bugfixes
Bugfixes
Many bugfixes, including allowing Threshold events to generate notifications, AdminStatus and OperStatus values causing exceptions, and rescans with certain devices.
Changes in OpenNMS 1.0.0 and Above
Changes in OpenNMS 1.0.0 and Above
The following major changes occurred between 0.9.9 and 1.0.0:
"OpenSSH" service is now "SSH"
"OpenSSH" service is now "SSH"
The OpenSSH service has been renamed to "SSH" and changed to detect common versions of SSH servers other than OpenSSH. Upgrades will retain the "OpenSSH" service as well for the sake of reports.
"Service Unresponsive" support
"Service Unresponsive" support
There is now the possibility of having a state between "up" and "down" that flags a service as being unresponsive. This state can be reached when the service's port can be connected to, but it does not respond in a reasonable amount of time.
Bugfixes
Bugfixes
Many small bugfixes, including the "Calculating..." problem if RTC has not come up yet when tomcat starts.

Known Issues and Caveats

Known Issues and Caveats

Chapter 3. Known Issues and Caveats
Known Problems And Workarounds In This Release
Here is the list of known issues in this release of OpenNMS.
Notes About Java Version
Notes About Java Version
For the RPMs created on Sourceforge, Sun's SDK version 1.4.2 was used for all 32-bit distros, and Sun's Java 5 (version 1.5) was used for all 64-bit distros. You should be able to build OpenNMS on either SDK, but since 64-bit Java is best supported under Java 5, that was the version that was used. Please run Tomcat under the same version of Java that OpenNMS uses.
Notes About Tomcat Version
Notes About Tomcat Version
OpenNMS 1.2.8+ supports Tomcat 4.1.18 and greater, up through Tomcat 5.0. It does not support Tomcat 5.5. There was no way to maintain the authentication scheme in Tomcat 5.5. However, the development branch of OpenNMS requires Tomcat 5.5 as it has an entirely new authentication process.
Invalid Symbolic Link on Some Distros
Invalid Symbolic Link on Some Distros
On Mandrake 10, and perhaps others, the symbolic link created in /etc/init.d for opennms doesn't seem to work. Do the following:
# rm /etc/init.d/opennms # ln -s /opt/OpenNMS/bin/opennms.sh /etc/init.d/opennms
The Installer is No Longer Automatic as of 1.1.5
The Installer is No Longer Automatic as of 1.1.5
I expect this to be the biggest question on the discussion lists. As of 1.1.5, the installer must be run manually after the packages are installed. Please see the documentation [https://sourceforge.net/docman/display_doc.php?docid=23937&group_id=4141] for more information.
Special Note for KSC Report Users
Special Note for KSC Report Users
With 1.1.5 a new format has been created for SNMP graphs in the snmp-graph.properties file. An attempt has been made to organize the different reports, and so default reports like "bits" are now prefixed by "mib2" (i.e. the report is now mib2.bits).
If you have KSC reports on bits, errors, etc., you will need to edit the ksc-performance-reports.xml file and replace the old names with the new ones.
Necessary Changes to Tomcat for 1.1.4 for Upgrades
Necessary Changes to Tomcat for 1.1.4 for Upgrades
In 1.1.4 the way OpenNMS configures Tomcat4 has changed. All of the necessary configuration information is now in opennms.xml in the Tomcat4 webapps directory.
Unfortunately, if you are upgrading, there are two things you will have to manually do in order to get OpenNMS to work correctly.
1.
Remove the opennms directory (or symbolic link) from the $TOMCAT4_HOME/webapps directory.
Depending on your operating system, you will need to find the webapps directory (usually /var/tomcat4/webapps). In that directory should be an opennms.xml file and an opennms directory (or symlink). Remove it and leave just the opennms.xml file.
2.
Locate the server.xml file, usually in $TOMCAT4_HOME/conf directory (/var/tomcat4/conf for many distributions). Remove the four <context> lines that refer to OpenNMS:
<Context path="/opennms" docBase="opennms" debug="0" reloadable="true"> <Logger className="org.opennms.web.log.Log4JLogger" homeDir="/opt/OpenNMS"/> <Realm className="org.opennms.web.authenticate.OpenNMSTomcatRealm" homeDir="/opt/OpenNMS"/> </Context >
You should then be able to restart Tomcat and everything should work just fine. Note that this does not apply to new installs, just upgrades.
New Requirements for Tomcat and PostgreSQL
New Requirements for Tomcat and PostgreSQL
Version 1.1.2 and beyond of OpenNMS will require at a minimum Tomcat version 4.1.18 and PostgreSQL 7.2. OpenNMS will no longer supply "onms" versions of these applications, and instead will use main distributions from their maintainers.
Note that upgrading these programs is not simple.
Tomcat4
Tomcat4
For Tomcat, the best thing to do is uninstall version 4.0 and then install 4.1. Version 4.1 is not seen as an upgrade to 4.0, but is instead seen as a separate product by rpm and apt. You will need to make the following changes to the tomcat4.conf file (located in /etc/tomcat4 on Red Hat):
# you could also override JAVA_HOME here # Where your java installation lives # JAVA_HOME="/usr/java/jdk" # JAVA_HOME="/opt/IBMJava2-131" JAVA_HOME="[location of your Java Home dir]"

# What user should run tomcat TOMCAT_USER="root"
You do not have to run Tomcat as root if you change the permissions on $OPENNMS/logs and $OPENNMS/etc so that the Tomcat user can write to them.
PostgreSQL
PostgreSQL
Two main changes need to be made to the Postgres configuration in order to allow OpenNMS to access it properly. Postgres needs to have been started at least once to create the "data" directory that will contain the configuration files.
Edit postgresql.conf (located in /var/pgsql/data on Red Hat) and insure the following values exist: tcpip_socket = true max_connections = 256 shared_buffers = 1024
Edit pg_hba.conf (host based authentication) to allow all users to access the database from the local host by un-commenting and/or adding these lines (do not add the last line if your system does not support IPv6):
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD

local all all trust host all all 127.0.0.1 255.255.255.255 trust host all all ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff trust
and you may need to uncomment:
# Using sockets credentials for improved security. Not available everywhere, # but works on Linux, *BSD (and probably some others)

# local all all ident sameuser
Note that this opens up Postgres to all users on the system (as long as they know the database password). Contact your database administrator if you want to limit this to a specific user, like root.

Supported Systems

Supported Systems

Chapter 4. Supported Systems
Supported UNIX-like OSes
OpenNMS is written almost entirely in Java, and should be able to run on any system that suuports the Java 1.4 Virtual Machine. There are requirements for other programs such as PostgreSQL, Perl, RRDTool and Tomcat4, but the 1.4 JDK is the key requirement (as most of the other packages can be compiled from source).
The following are the systems that support or are known to run OpenNMS.
Fully Supported
Fully Supported
The following Linux distributions and other unix-like systems are supported out-of-the-box with native installation packages.
Red Hat Linux 7.x, Red Hat Linux 8, Red Hat Linux 9, Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4
Red Hat Linux 7.x, Red Hat Linux 8, Red Hat Linux 9, Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4
PostgreSQL 7.2 and later has shipped with Red Hat Linux since version 7.3. Be sure to follow the above instructions.
CentOS 3 and CentOS 4
CentOS 3 and CentOS 4
Fedora Core 1, Fedora Core 2, Fedora Core 3, Fedora Core 4, Fedore Core 5 and Fedora Core 6 (including x86).
OpenNMS is known to build and run on Fedora Core 1 through Fedora Core 6.
Debian Woody, Sarge and Sid.
Debian packages should be available on ftp.opennms.org, and at the following apt-repository:deb http://debian.opennms.org/apt debian/opennms stable
Special Tomcat 4.1 packages were created, since only 4.0 is supported in stable. For instructions see this How-To [http://opennms.netstatz.com/Debian_ONMS_HOWTO.html#toc2] written by Ian MacDonald.
Solaris 8, Solaris 9 and Solaris 10 on x86 and SPARC.
Packages are available at ftp.opennms.org for Solaris 8 and Solaris 9 running on SPARC and Solaris 9 running on x86.
Mandrake 8, Mandrake 9 and Mandrake 10.
Please note that while we build packages for Mandrake 8.x, we do not do any formal testing on it. Packages are provided as a convenience.
SuSE 8, SuSE 9 and SuSE 10.
OpenNMS is known to build and run on SuSE.
MacOSX 10.3 and 10.4.
On MacOSX, the Fink distribution packages of OpenNMS are supported. See the Fink web site [http://fink.sf.net/] for more information on installing and using Fink.
Also note that on MacOSX, PostgreSQL must be configured in the same manner as above for Linux. However, to do so you will need to update the SHM settings so that the OS allows enough resources for PostgreSQL to run with larger buffers.
To do so, you must edit /System/Library/StartupItems/SystemTuning/SystemTuning so that the sysctl lines look like so (at a minimum): sysctl -w kern.sysv.shmmax=16777216 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=128 sysctl -w kern.sysv.shmseg=32 sysctl -w kern.sysv.shmall=4096
Unsupported
Unsupported
The following UNIX systems are unsupported, but have been known to work.
Debian Woody on SPARC.
OpenNMS is known to run on Debian on SPARC
Red Hat 6.2.
No special cases known.
Solaris 7.
There have been reports of OpenNMS building and running on Solaris on the discuss list.