| Newsgroups |
gmane.network.opennms.announce |
| Message-ID |
<[email protected]> |
Gang:
OpenNMS 1.1.0 has been released and is available from the website. The web
installer and apt should work fine for Red Hat 7 and Mandrake 8.
There is a dependency problem with the Red Hat 8 RPMS right now, which I
have fixed. New RPMs will be uploaded by 3pm (15:00) EDT.
RPMs will exist for Mandrake 9, but we have yet to modify the installer to
support Mandrake 9 (it uses urpm versus apt). We should have that fixed by
this weekend.
Also, Tony will be creating 1.1.0 Debian packages soon. They will be
available for download from ftp.opennms.org.
I will send out an announcement when the Red Hat 8, Mandrake 9 and Debian
packages are ready, and when Mandrake 9 and Debian are supported by the
installer.
Version 1.1.0 is the new development or unstable release. There are a
number of new features in 1.1.0, as well as all the bugfixes and additions
from the stable release. This does not represent the final 1.1 release and
more features are on the way.
Enjoy, and please submit issues to bugzilla.opennms.org.
-T
From the release notes:
2.1. 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
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
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
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
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
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
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
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.
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
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
Both LDAP and Citrix protocol plug-ins were listed twice. This
would slow down the capabilities scan considerably.
* Updated Data Collection and Graphing
Added new entries to datacollection-config.xml and
snmp-graph.properties.
* Bugfixes
Many bugfixes, including allowing Threshold events to generate
notifications, AdminStatus and OperStatus values causing
exceptions, and rescans with certain devices.
--
Tarus Balog
Consultant
Sortova Consulting Group, http://www.sortova.com
+1-919-696-7625
[email protected]
_______________________________________________
announce mailing list ([email protected])
To subscribe, unsubscribe, or change your list options, go to:
http://lists.opennms.org/mailman/listinfo/announce