Bug 1525256

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
               ^

Upstream ticket:
https://pagure.io/389-ds-base/issue/49546

Created attachment 1383613 [details]
Preview of updated MIB

Test MIB

Mike, I've attached a new MIB file.  Is there any chance you would be willing it give it test run?

Thanks,
Mark

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

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.

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.

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

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

(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

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.

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?)

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...

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

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 }

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?

Created attachment 1384618 [details]
Preview of updated MIB (part 3)

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

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 }

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!

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.

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!

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

Fixed upstream

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.

Created attachment 1458446 [details]
redhat-directory.mib.diff

Proposed patch

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..

Build tested: 389-ds-base-1.3.8.4-7.el7.x86_64

Changes were applied, marking as VERIFIED.

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."

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