Bug 966294 - RHQ-mib.txt definition file is invalid and missing SNMPv2 notification definition
RHQ-mib.txt definition file is invalid and missing SNMPv2 notification defini...
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- Other (Show other bugs)
JON 3.1.2
All All
unspecified Severity medium
: ER01
: JON 3.2.0
Assigned To: Heiko W. Rupp
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2013-05-22 20:06 EDT by Larry O'Leary
Modified: 2014-02-24 10:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-02 15:43:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 378503 None None None Never

  None (edit)
Description Larry O'Leary 2013-05-22 20:06:52 EDT
Description of problem:
Running validation on RHQ-mib.txt reveals a few warnings and some fatal errors:

./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:27: [3] revision not in reverse chronological order
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:29: [3] revision not in reverse chronological order
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:96: [1] identifier `alertHierarchy' registers object identifier already registered by `alertUrl'
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:82: [6] info: previous definition of `alertUrl'
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:101: [5] warning: redefinition of identifier `SNMPv2-MIB::snmpMIBConformance'
/usr/share/mibs/ietf/SNMPv2-MIB:510: [6] info: previous definition of `snmpMIBConformance'
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:104: [5] warning: redefinition of identifier `SNMPv2-MIB::snmpMIBCompliances'
/usr/share/mibs/ietf/SNMPv2-MIB:513: [6] info: previous definition of `snmpMIBCompliances'
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:105: [5] warning: redefinition of identifier `SNMPv2-MIB::snmpMIBGroups'
/usr/share/mibs/ietf/SNMPv2-MIB:514: [6] info: previous definition of `snmpMIBGroups'
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:109: [5] warning: redefinition of identifier `SNMPv2-MIB::snmpBasicCompliance'
/usr/share/mibs/ietf/SNMPv2-MIB:522: [6] info: previous definition of `snmpBasicCompliance'
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:130: [3] OBJECTS or NOTIFICATIONS member `coldStart' is not defined in this module
./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:4: [5] warning: identifier `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used

For starters, we attempt to define a notification group compliance but are using a notification that is defined in another module. This can be seen by "OBJECTS or NOTIFICATIONS member `coldStart' is not defined in this module". 

Next, as the not so critical warning "identifier `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used" indicates, we aren't even defining a notification type. Meaning that we can't even fix the notification group compliance issue because we do not actually define a notification type.

The redefinition warnings are due to us using the nodes from the SNMPv2-MIB as our own compliance nodes. We should use our own defined under our own enterprise node.

Finally, the biggest error is the reuse of the same OID for two different alert objects:

alertUrl and alertHierarchy both use 6 as their identifier. This will result in unpredictable behavior by a trap processor as the values and will be ambiguous. SnmpTrapSender.sendSnmpTrap uses 7 for alertHierarchy.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Execute smilint (provided by the libsmi package) on the RHQ-mib.txt file:

       smilint -s ./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt

Actual results:
Validation errors/warning ranging from severity 1 to severity 6 appear.

Expected results:
No validation errors should appear.

Additional info:
Although the basic validation of the syntax and definitions is where we should start, all changes should ensure compatibility with existing installations and should conform to the the SNMP version standard we support.

We should also perform testing of actual processing of these traps/notifications within an actual SNMP trap daemon which is using the MIB.
Comment 1 Larry O'Leary 2013-05-28 12:56:14 EDT
Bug 614300 was supposed to introduce NOTIFICATION-TYPE in the RHQ-mib but instead redefined SNMPv2-MIB compliance level. Not sure how we missed this in our testing but 614300 did not do what it was supposed to.

Bug 744262 introduced a new alert field named alertHierarchy. However, the MIB definition that was added uses OID .6 instead of OID .7. OID .6 belongs to alertUrl which is in error.
Comment 2 Heiko W. Rupp 2013-07-02 13:41:31 EDT
The first few items are easy to fix - especially that duplicate OID.

What is tricky is ./modules/enterprise/server/appserver/src/main/resources/etc/RHQ-mib.txt:130: [3] OBJECTS or NOTIFICATIONS member `coldStart' is not defined in this module

as this coldStart has a pre-defined OID from the SNMPv2-MIB, which we import.
If this is redefined to be declared in the file, it will have a different OID.
If this stays as "coldStart", we get the warnings from smilint.
Comment 3 Larry O'Leary 2013-07-02 14:13:29 EDT
We shouldn't be using coldStart. It is a notification provided by SNMPv2-MIB and I believe we probably copied this word-for-word from an example. Instead, see https://access.redhat.com/site/solutions/378503 for how this should be done. Obviously the knowledge solution describes how to create this in a custom/user defined MIB that extends our MIB but we should do the same in our own MIB ensuring that we use object names and numbers that are relevant to our own MIB.
Comment 4 Heiko W. Rupp 2013-07-09 11:16:23 EDT
First cut is in master 4381d307b87
Comment 5 Heiko W. Rupp 2013-07-12 15:09:29 EDT
Further work after review meeting in 9356e5f

This wiki page gives more details: https://docs.jboss.org/author/display/RHQ/SNMP+Trap+Notifications
It also lists output from tcpdump and snmptrapd at the bottom
Comment 6 Larry O'Leary 2013-09-06 10:31:47 EDT
As this is MODIFIED or ON_QA, setting milestone to ER1.

Note You need to log in before you can comment on or make changes to this bug.