Bug 1525256 - Invalid SNMP MIB for 389 DS
Summary: Invalid SNMP MIB for 389 DS
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base   
(Show other bugs)
Version: 7.4
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: pre-dev-freeze
: ---
Assignee: mreynolds
QA Contact: RHDS QE
Marc Muehlfeld
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-12 22:04 UTC by Mike Kelly
Modified: 2018-10-30 10:14 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.3.8.4-4.el7
Doc Type: Bug Fix
Doc Text:
Updated Directory Server SNMP MIB definitions Previously, the Simple Network Management Protocol (SNMP) Management Information Base (MIB) definitions provided by the _389-ds-base_ package did not conform to the Structure of Management Information Version 2 (SMIv2) defined in RFC 2578. As a consequence, the *lint* utility reported errors. The definitions have now been updated, and as a result, the MIB definitions comply with the SMIv2 specification
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-10-30 10:13:31 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Preview of updated MIB (24.72 KB, text/x-vhdl)
2018-01-19 21:16 UTC, mreynolds
no flags Details
Preview of updated MIB (part 2) (25.40 KB, text/x-vhdl)
2018-01-22 18:05 UTC, mreynolds
no flags Details
Preview of updated MIB (part 3) (25.27 KB, text/x-vhdl)
2018-01-22 22:30 UTC, mreynolds
no flags Details
redhat-directory.mib.diff (1.22 KB, patch)
2018-07-12 13:59 UTC, Viktor Ashirov
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3127 None None None 2018-10-30 10:14 UTC

Description Mike Kelly 2017-12-12 22:04:36 UTC
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).

Comment 1 Mike Kelly 2017-12-12 22:05:20 UTC
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
               ^

Comment 3 mreynolds 2018-01-19 17:29:14 UTC
Upstream ticket:
https://pagure.io/389-ds-base/issue/49546

Comment 4 mreynolds 2018-01-19 21:16 UTC
Created attachment 1383613 [details]
Preview of updated MIB

Test MIB

Comment 5 mreynolds 2018-01-19 21:17:36 UTC
Mike, I've attached a new MIB file.  Is there any chance you would be willing it give it test run?

Thanks,
Mark

Comment 6 Mike Kelly 2018-01-19 21:33:11 UTC
This still has some validation issues with smilint:

$ smilint redhat-directory.mib 
redhat-directory.mib:58: group 'rhdsGroup' is both mandatory and optional in `rhdsCompliance'

---

However, it is now parsed correctly by OpenNMS:

Fri Jan 19 16:22:06 EST 2018 [INFO] Parsing MIB file /opt/opennms/share/mibs/pending/redhat-directory.mib
Fri Jan 19 16:22:06 EST 2018 [INFO] MIB parsed successfuly.
Fri Jan 19 16:22:06 EST 2018 [INFO] Renaming file redhat-directory.mib to RHDS-MIB.mib

---

OpenNMS sees 2 traps: directoryServerDown, directoryServerStart

It sees 4 tables to collect stats from: dsOpsTable, dsEntriesTable, dsIntTable, dsEntityTable

---

Also, net-snmp doesn't seem to like part of the MIB:

Attempt to define a root oid (directoryServerDown): At line 825 in /Users/mkelly/Documents/RedHat/MIBs/redhat-directory.mib
Bad parse of NOTIFICATION-TYPE: At line 825 in /Users/mkelly/Documents/RedHat/MIBs/redhat-directory.mib

Comment 7 Mike Kelly 2018-01-19 21:43:59 UTC
Also, OpenNMS & net-snmp just plain parses the MIB in a way that doesn't match up with the data:

A snmpwalk of .1.3.6.1.4.1.2312 just lists a bunch of SNMPv2-SMI::enterprises.2312.6.1.1.389, etc type entries.

It looks like the MIB is not building its hierarchy correctly.

Comment 8 mreynolds 2018-01-19 22:09:15 UTC
Sorry Mike, I found some other errors in the MIB file when I started running tests.  I prematurely sent you the MIB file.  I'll have something better for you next week.

Comment 9 mreynolds 2018-01-22 16:39:12 UTC
Mike, unfortunately I'm having issues getting snmp working.   I've followed these steps exactly:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/monitoring_ds_using_snmp-configuring_the_subagent

But snmpwalk just times out.  (I tried turning of selinux, firewall, etc - but no change)

I'm curious what settings you added to snmpd.conf on your system.  Did you run into any odd issues just getting it to work?

Thanks,
Mark

Comment 10 Mike Kelly 2018-01-22 17:31:30 UTC
I already had AgentX support working for other internal uses, so I don't think I had much work involved in enabling this feature.

For agentx, I just have this configuration:

---

master agentx

agentXTimeout 1
agentXRetries 5

agentaddress udp:161

---

However, if snmpwalk times out, you probably have more fundamental configuration problems... are you even able to do a basic:

snmmpwalk 127.0.0.1 SNMPv2-MIB::system ?

If not, then you need to figure out your community string settings. If so, then you may have to tweak the 'views' configuration...

This Puppet module seems to do a good job configuring things, and it may help you...

https://forge.puppet.com/razorsedge/snmp

Comment 11 mreynolds 2018-01-22 18:01:49 UTC
(In reply to Mike Kelly from comment #10)
> I already had AgentX support working for other internal uses, so I don't
> think I had much work involved in enabling this feature.
> 
> For agentx, I just have this configuration:
> 
> ---
> 
> master agentx
> 
> agentXTimeout 1
> agentXRetries 5
> 
> agentaddress udp:161
> 
> ---
> 
> However, if snmpwalk times out, you probably have more fundamental
> configuration problems... are you even able to do a basic:
> 
> snmmpwalk 127.0.0.1 SNMPv2-MIB::system ?

This command works:

snmpwalk -v1 -c public 127.0.0.1 SNMPv2-MIB::system

These commands work too:

# snmptranslate -M /usr/share/snmp/mibs:/usr/share/dirsrv/mibs/ -m +RHDS-MIB -IR -On dsEntityContact
.1.3.6.1.4.1.2312.6.5.1.5
# snmptranslate -M /usr/share/snmp/mibs:/usr/share/dirsrv/mibs/ -m +RHDS-MIB -IR -On dsSimpleAuthBinds
.1.3.6.1.4.1.2312.6.1.1.3

But this fails:

# snmpwalk -v3 -u user_snmp -M /usr/share/snmp/mibs:/usr/share/dirsrv/mibs/ -l AuthPriv -m +RHDS-MIB -A PASSWORD -X PASSWORD localhost  .1.3.6.1.4.1.2312.6.1.1
Timeout: No Response from localhost


I tried your suggestions and looked at puppet settings, but unfortunately it did not help.

What is in "cn=SNMP,cn=config" (dse.ldif)?


Still investigating...

> 
> If not, then you need to figure out your community string settings. If so,
> then you may have to tweak the 'views' configuration...
> 
> This Puppet module seems to do a good job configuring things, and it may
> help you...
> 
> https://forge.puppet.com/razorsedge/snmp

Comment 12 mreynolds 2018-01-22 18:05 UTC
Created attachment 1384557 [details]
Preview of updated MIB (part 2)

On a side note, here is the updated mib file.  But since I can't test it I'm not 100% sure if it will work for you.

Comment 13 Mike Kelly 2018-01-22 20:38:41 UTC
I'm not using SNMPv3, that's a whole separate can of worms that I'd leave as an exercise for you to work out :)

---

Second revision of the MIB:

smilint: no issues flagged

---

snmpwalk / snmptable: appears to work w/o issue (FWIW, I haven't put it in place on my server, just on my SNMP client).

$ snmpwalk REDACTED.example.com .1.3.6.1.4.1.2312
RHDS-MIB::dsAnonymousBinds.389 = Counter64: 82040
RHDS-MIB::dsUnAuthBinds.389 = Counter64: 82040
RHDS-MIB::dsSimpleAuthBinds.389 = Counter64: 82045
RHDS-MIB::dsStrongAuthBinds.389 = Counter64: 149
RHDS-MIB::dsBindSecurityErrors.389 = Counter64: 0
RHDS-MIB::dsInOps.389 = Counter64: 169616
RHDS-MIB::dsReadOps.389 = Counter64: 0
RHDS-MIB::dsCompareOps.389 = Counter64: 0
RHDS-MIB::dsAddEntryOps.389 = Counter64: 0
RHDS-MIB::dsRemoveEntryOps.389 = Counter64: 0
RHDS-MIB::dsModifyEntryOps.389 = Counter64: 94
RHDS-MIB::dsModifyRDNOps.389 = Counter64: 0
RHDS-MIB::dsListOps.389 = Counter64: 0
RHDS-MIB::dsSearchOps.389 = Counter64: 2720
RHDS-MIB::dsOneLevelSearchOps.389 = Counter64: 1307
RHDS-MIB::dsWholeSubtreeSearchOps.389 = Counter64: 793
RHDS-MIB::dsReferrals.389 = Counter64: 0
RHDS-MIB::dsChainings.389 = Counter64: 0
RHDS-MIB::dsConnections.389 = Counter64: 0
RHDS-MIB::dsMaxThreadsHit.389 = Counter64: 353
RHDS-MIB::dsConnectionsInMaxThreads.389 = Counter64: 24
RHDS-MIB::dsSecurityErrors.389 = Counter64: 0
RHDS-MIB::dsErrors.389 = Counter64: 0
RHDS-MIB::rhdsCompliance.389 = Counter64: 0
RHDS-MIB::snmpMIBCompliances.2.389 = Counter64: 0
RHDS-MIB::snmpMIBCompliances.3.389 = Counter64: 0
RHDS-MIB::snmpMIBCompliances.4.389 = Counter64: 0
RHDS-MIB::snmpMIBCompliances.5.389 = Counter64: 0
RHDS-MIB::dsEntityDescr.389 = STRING: 
RHDS-MIB::dsEntityVers.389 = STRING: 389-Directory/1.3.6.1
RHDS-MIB::dsEntityOrg.389 = STRING: 
RHDS-MIB::dsEntityLocation.389 = STRING: 
RHDS-MIB::dsEntityContact.389 = STRING: 
RHDS-MIB::dsEntityName.389 = STRING: 

---

OpenNMS still successfully parses the MIB. But, this time, it correctly maps the traps to an OID. However, that OID still doesn't seem to match up with reality.

The traps being sent (again, using the existing MIB), seem to be coming in as .1.3.6.1.4.1.2312.6001 & .1.3.6.1.4.1.2312.6002, however the MIB defined them as coming in as .1.3.6.1.4.1.2312.6.6.0.6001 and .1.3.6.1.4.1.2312.6.6.0.6002... (Perhaps your other changes will accommodate this in the server itself?)

Comment 14 mreynolds 2018-01-22 20:48:18 UTC
Well I got it working.  I had a malformed snmp user (long story).  The MIB file "works" for me, but there are changes in the core server to fix alignment/column issues (dsErrors vs dsMaxThreadsHit)

I need to look into the trap issues next...

Comment 15 mreynolds 2018-01-22 21:28:04 UTC
Mike, can you try editing the newer MIB file, and at the very bottom change the NOTIFICATION-TYPE entries:


::= { rhdsNotification 6001 }


to


::= { 6001 }


Basically remove "rhdsNotification", and do the same for the 6002 entry.

Are you now getting consistent results?  What OID's are you seeing now?  

According to the source code it expects it to be: .1.3.6.1.4.1.2312.0.6001 (fyi)

Thanks,
Mark

Comment 16 Mike Kelly 2018-01-22 21:47:07 UTC
That edit makes the MIB invalid, it seems.

$ snmptranslate -On RHDS-MIB::directoryServerStart
No log handling enabled - using stderr logging
Attempt to define a root oid (directoryServerDown): At line 811 in /Users/mkelly/Documents/RedHat/MIBs/redhat-directory.mib
Bad parse of NOTIFICATION-TYPE: At line 811 in /Users/mkelly/Documents/RedHat/MIBs/redhat-directory.mib
RHDS-MIB::directoryServerStart: Unknown Object Identifier

---

If you want to get the OID the source code expects, you need something like:

 ::= { redhat 0 6002 }

Or... you just need to tweak the definition of `rhdsNotification`, like this:

rhdsNotification  OBJECT IDENTIFIER ::= { redhat 0 }

Comment 17 mreynolds 2018-01-22 22:29:12 UTC
I was just about to tell you I got the same error.  Can yo7u run one more test.  I'm attaching a new MIB file, can you confirm what OID the client is seeing for the traps?

Comment 18 mreynolds 2018-01-22 22:30 UTC
Created attachment 1384618 [details]
Preview of updated MIB (part 3)

New MIB file, please confirm the trap OID's returned to the client.  Thanks!

Comment 19 Mike Kelly 2018-01-23 14:42:27 UTC
OK, latest iteration:

* Passes smilint

* Returns the expected OIDs for the traps

* Parsed correctly by OpenNMS.

---

Main thing that seems weird to me (but may have been weird before), is this bit in my snmpwalk output:

RHDS-MIB::rhdsCompliance.389 = Counter64: 0
RHDS-MIB::rhdsMIBCompliances.2.389 = Counter64: 0
RHDS-MIB::rhdsMIBCompliances.3.389 = Counter64: 0
RHDS-MIB::rhdsMIBCompliances.4.389 = Counter64: 0
RHDS-MIB::rhdsMIBCompliances.5.389 = Counter64: 0

---

$ snmptranslate -Td RHDS-MIB::rhdsCompliance
RHDS-MIB::rhdsCompliance
rhdsCompliance MODULE-COMPLIANCE
  -- FROM	RHDS-MIB
  DESCRIPTION	"The compliance statement for SNMPv2 entities which
             implement the SNMPv2 MIB."
::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) redhat(2312) rhds(6) rhdsMIBConformance(2) rhdsMIBCompliances(1) 1 }

$ snmptranslate -Td RHDS-MIB::rhdsMIBCompliances
RHDS-MIB::rhdsMIBCompliances
rhdsMIBCompliances OBJECT-TYPE
  -- FROM	RHDS-MIB
::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) redhat(2312) rhds(6) rhdsMIBConformance(2) 1 }

Comment 20 mreynolds 2018-01-23 15:20:10 UTC
I had to create these conformance/compliance entries to satisfy smilint.  So these entries did not exists until I updated the MIB.  What output were you expecting to see?  Or what is weird about it?

Thanks again for testing the MIB's!

Comment 21 mreynolds 2018-01-23 15:42:07 UTC
Perhaps you meant the DESCRIPTION?  Well it was very generic (copy/paste from some example I found)  I have revised those descriptions to match up with the RHDS MIB.

Comment 22 mreynolds 2018-01-23 17:12:25 UTC
Mike, I have one last favor to ask, can you verify that the traps are actually working?  The only traps we have are for stopping/starting the server.

Thanks again!

Comment 23 mreynolds 2018-01-26 14:30:18 UTC
Hi Mike,

Sorry to pest you, I know you are busy, but I was hoping you could verify if the DS traps are working with the new MIB file.

Thanks,
Mark

Comment 24 mreynolds 2018-01-31 13:24:23 UTC
Fixed upstream

Comment 27 Viktor Ashirov 2018-07-12 13:58:14 UTC
Build tested: 389-ds-base-1.3.8.4-3.el7.x86_64

smilint passes, but I've noticed 2 issues:

1. dsIntIndex has type INTEGER in SEQUENCE, but in OBJECT-TYPE it is Integer32.
2. dsMaxThreadsHit has type Counter64, but its name doesn't denote plurality, unlike other Counter64-typed objects.

Marking as ASSIGNED.

Comment 28 Viktor Ashirov 2018-07-12 13:59 UTC
Created attachment 1458446 [details]
redhat-directory.mib.diff

Proposed patch

Comment 29 mreynolds 2018-07-12 14:56:04 UTC
Thanks for the patch Viktor, it required other changes since you changed the name.  Fortunately we do not document dsMaxThreadsHit, so this does not require a doc change.  Patch is out for review..

Comment 31 Viktor Ashirov 2018-07-23 13:00:19 UTC
Build tested: 389-ds-base-1.3.8.4-7.el7.x86_64

Changes were applied, marking as VERIFIED.

Comment 34 Mike Kelly 2018-08-04 20:19:31 UTC
Probably worth clarifying the docs:

"The SNMP MIB definitions provided with 389-ds-base previously did not conform to the SMIv2 specification, as shown by the output of the `smilint` tool. The MIB has been updated to comply with the standard, per RFC 2578, etc."

Comment 38 errata-xmlrpc 2018-10-30 10:13:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3127


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