Bug 966294 - RHQ-mib.txt definition file is invalid and missing SNMPv2 notification definition
Summary: RHQ-mib.txt definition file is invalid and missing SNMPv2 notification defini...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- Other
Version: JON 3.1.2
Hardware: All
OS: All
unspecified
medium
Target Milestone: ER01
: JON 3.2.0
Assignee: Heiko W. Rupp
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-23 00:06 UTC by Larry O'Leary
Modified: 2018-12-03 18:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-02 20:43:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 614300 0 low CLOSED SNMP MIB does not define a notification-type 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 744262 0 high CLOSED [RFE] Request adding parent and grandparent resource name to SNMP Alerts 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 378503 0 None None None Never

Internal Links: 614300 744262

Description Larry O'Leary 2013-05-23 00:06:52 UTC
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):
4.4.0.JON312GA

How reproducible:
Always

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 16:56:14 UTC
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 17:41:31 UTC
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 18:13:29 UTC
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 15:16:23 UTC
First cut is in master 4381d307b87

Comment 5 Heiko W. Rupp 2013-07-12 19:09:29 UTC
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 14:31:47 UTC
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.