#49546 Invalid SNMP MIB for 389 DS
Closed: wontfix 3 years ago Opened 3 years ago by mreynolds.

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

3 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

3 years ago

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

3 years ago

@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 :-)

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: None)

3 years ago

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

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)

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

a year ago

Login to comment on this ticket.

Metadata