Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1525256
Description of problem: The provided SNMP MIB for monitoring 389-ds is not syntactically valid. Version-Release number of selected component (if applicable): $ rpm -qa | grep 389 389-ds-base-1.3.6.1-24.el7_4.x86_64 389-ds-base-snmp-1.3.6.1-24.el7_4.x86_64 389-ds-base-libs-1.3.6.1-24.el7_4.x86_64 How reproducible: 100% Steps to Reproduce: 1. smilint /usr/share/dirsrv/mibs/redhat-directory.mib Actual results: redhat-directory.mib:41: MODULE-IDENTITY clause must be the first declaration in a module redhat-directory.mib:51: revision for last update is missing redhat-directory.mib:84: syntax error, unexpected LOWERCASE_IDENTIFIER, expecting '}' or ',' redhat-directory.mib:698: ACCESS is SMIv1 style, use MAX-ACCESS in SMIv2 MIBs instead redhat-directory.mib:699: invalid status `mandatory' in SMIv2 MIB redhat-directory.mib:706: ACCESS is SMIv1 style, use MAX-ACCESS in SMIv2 MIBs instead redhat-directory.mib:707: invalid status `mandatory' in SMIv2 MIB redhat-directory.mib:714: ACCESS is SMIv1 style, use MAX-ACCESS in SMIv2 MIBs instead redhat-directory.mib:715: invalid status `mandatory' in SMIv2 MIB redhat-directory.mib:722: ACCESS is SMIv1 style, use MAX-ACCESS in SMIv2 MIBs instead redhat-directory.mib:723: invalid status `mandatory' in SMIv2 MIB redhat-directory.mib:731: ACCESS is SMIv1 style, use MAX-ACCESS in SMIv2 MIBs instead redhat-directory.mib:732: invalid status `mandatory' in SMIv2 MIB redhat-directory.mib:740: ACCESS is SMIv1 style, use MAX-ACCESS in SMIv2 MIBs instead redhat-directory.mib:741: invalid status `mandatory' in SMIv2 MIB redhat-directory.mib:750: `DirectoryServerDown' should start with a lower case letter redhat-directory.mib:750: TRAP-TYPE macro is not allowed in SMIv2 redhat-directory.mib:758: `DirectoryServerStart' should start with a lower case letter redhat-directory.mib:758: TRAP-TYPE macro is not allowed in SMIv2 redhat-directory.mib:35: textual convention `URLString' can not be derived from the textual convention `DisplayString' redhat-directory.mib:54: unknown type `DsOpsEntry' Expected results: Syntatically valid MIB. Additional info: The lack of compliance with SMIv2 makes it difficult to incorporate monitoring for 389 DS into many 3rd party tools (for example, OpenNMS).
Metadata Update from @mreynolds: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1525256
Metadata Update from @mreynolds: - Issue assigned to mreynolds
From bug:
The MIB parser in OpenNMS, specifically, returns these errors:
ERROR: Parse error: expecting R_BRACE, found 'dsBindSecurityErrors', Source: redhat-directory.mib, Row: 84, Col: 9 dsBindSecurityErrors ^ ERROR: Cannot find symbol DsOpsEntry, Source: redhat-directory.mib, Row: 63, Col: 16 SYNTAX DsOpsEntry
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
Beta patch
ThIs patch converts the current MIB file to be SMIv2 compliant
<img alt="0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" src="/389-ds-base/issue/raw/files/778c0716cbaa365acd96b2fbc6f3a42a39f3dfd95021da0d9b7c83844ca1860a-0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" />
@mreynolds, sorry in advance for this novice question. The patch defines a list rhdsGroup. Each item in that list has a specific OID. Is that important that they are listed in the same order than OIDs (like dsMaxThreadsHit and dsConnectionsInMaxThreads being in the reverse order than OIDs)? Also some counters looks having change their OID (like dsSecurityErrors <--> dsConnectionsInMaxThreads) is that intentional ?
@tbordaz First here were issues with the current patch. Working on that now.
I don't think the group list item's order matter, but it does in other places. Sorry I'm not sure what you mean here:
Also some counters looks having change their OID (like dsSecurityErrors <--> dsConnectionsInMaxThreads) is that intentional ?
Since I changed a lot, especially the order of things, it would probably be best to review the file as a whole, and not use the "diff". Anyway I still have work to do on it, so keep your eyes open for the next patch :-)
<img alt="0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" src="/389-ds-base/issue/raw/files/bc8f1f8028b29a03455aaf6bc0bf170ddf2b5441fd6f7a8588fb1b930097a9e9-0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" />
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to review (was: None)
This MIB has been successfully tested by an external customer. (it also works with openNMS)
Instead of %ld, try and use the %"PRIu64" and related types because they work cross platform etc. There are other examples in the code base.
Besides that, ack from me, really great patch (I'm biased because uint64_t ;) )
Thank you!
Instead of %ld, try and use the %"PRIu64" and related types because they work cross platform etc. There are other examples in the code base. Besides that, ack from me, really great patch (I'm biased because uint64_t ;) ) Thank you!
Sorry I missed this update, I will make those changes before I push the patch
Revised patch
<img alt="0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" src="/389-ds-base/issue/raw/files/94c34d4508a124384a4460548822fd4be6320314b444bb39ffd349e202946b7e-0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" />
Revised (part 2)
<img alt="0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" src="/389-ds-base/issue/raw/files/409f95cb68d931b8dc92baaf2dfc9996b547963ba77ee1c5f69565eb831457e9-0001-Ticket-49546-Fix-broken-snmp-MIB-file.patch" />
I've reviewed the MIB section of the latest patch revision, and the changes look good. Thanks for keeping the SNMP OIDs the same as the previous versions!
6aa2acd..ee62d3d master -> master
6f682da..6df53cf 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
commit 6d4caac master
878bf89..51e2f0c 389-ds-base-1.3.8 -> 389-ds-base-1.3.8
244c940..2dbb47e 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2605
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.