Bug 966294
| Summary: | RHQ-mib.txt definition file is invalid and missing SNMPv2 notification definition | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Larry O'Leary <loleary> |
| Component: | Plugin -- Other | Assignee: | Heiko W. Rupp <hrupp> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | JON 3.1.2 | CC: | hrupp |
| Target Milestone: | ER01 | ||
| Target Release: | JON 3.2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-02 20:43:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. 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. First cut is in master 4381d307b87 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 As this is MODIFIED or ON_QA, setting milestone to ER1. |
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.