Red Hat Bugzilla – Bug 1150206
result of dna_dn_is_shared_config is incorrectly used
Last modified: 2015-03-05 04:36:03 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47918 The function dna_dn_is_shared_config() should determine if the entry handled by the plugin is a shared config entry, but it does the opposite. As a side effect for every changed entry dna_load_shared_servers() is called.
please add steps to reproduce and verify Thanks!
I think the performance of DNA over MMR would be significantly improved, but functionality-wise, no difference. So, running DNA acceptance/stress would be good enough to verify this bug. But I could be wrong, could you please add your comments, Ludwig? Thanks!
the bug is also a functional but, it did not only do too many searches, but it did it also for the wrong entries. But so far there haven't been any report on failures, perhaps the changig of entries in the shared config is not a common case. I'm not so familiar with that changes and how to test, passing needinfo on to Mark
It doesn't look like tet tests the new "remote servers" feature yet, but the remote server code is still evaluated when checking for shared configurations. So if tet passes, the core/shared config functionality is working correctly. Note, the new "remote server" feature is just an extension of the existing shared configuration functionality. The "shared configuration" feature has been around since the creation of the DNA plugin, and it is fully tested in tet.
$ rpm -qa | grep 389 389-ds-base-libs-1.3.3.1-12.el7.x86_64 389-ds-base-debuginfo-1.3.3.1-12.el7.x86_64 389-ds-base-1.3.3.1-12.el7.x86_64 [1] Install two servers using "dc=example,dc=com": Server A and Server B M1: 1189, 1616 M2: 1289, 1626 $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 << EOF dn: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on EOF modifying entry "cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1289 << EOF dn: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on EOF modifying entry "cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" $ sudo systemctl restart dirsrv.target [2] Add some org units: $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 << EOF dn: ou=ranges,dc=example,dc=com changetype: add ou: ranges objectClass: top objectClass: organizationalunit EOF adding new entry "ou=ranges,dc=example,dc=com" [3] Add a shared config entry that points to Server B $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 << EOF dn: dnaHostname=rhel7.brq.redhat.com+dnaPortNum=1289,ou=ranges,dc=example,dc=com changetype: add objectClass: dnaSharedConfig objectClass: top dnaHostname: rhel7.brq.redhat.com dnaPortNum: 1289 dnaSecurePortNum: 1626 dnaRemainingValues: 1000 EOF adding new entry "dnaHostname=rhel7.brq.redhat.com+dnaPortNum=1289,ou=ranges,dc=example,dc=com" [4] Add the DNA config entries $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 << EOF dn: cn=UID and GID numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: UID and GID numbers dnaType: cn dnaMaxValue: 10000 dnaMagicRegen: 0 dnaFilter: (objectclass=top) dnaScope: ou=people,dc=example,dc=com dnaNextValue: 500 dnaSharedCfgDN: ou=ranges,dc=example,dc=com dnaRemoteBindDN: cn=Directory Manager dnaRemoteBindCred: Secret123 EOF adding new entry "cn=UID and GID numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" [5] Turn on plugin and internal access logging, and disable log buffering $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 << EOF dn: cn=config changetype: modify replace: nsslapd-plugin-logging nsslapd-plugin-logging: on - replace: nsslapd-accesslog-level nsslapd-accesslog-level: 4 - replace: nsslapd-accesslog-logbuffering nsslapd-accesslog-logbuffering: off EOF modifying entry "cn=config" [6] Restart the server $ sudo systemctl restart dirsrv.target [7] Add a entry to ou=people,dc=example,dc=com $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 << EOF dn: cn=entry,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: groupofuniquenames cn: entry EOF adding new entry "cn=entry,ou=People,dc=example,dc=com" [8] This should not trigger an internal search: $ grep -i -E "Internal.*dna" /var/log/dirsrv/slapd-M1/access | wc -l 0 > However, at server startup this is logged, so the proper way to verify this is to chek for two of these searches: After server restart there is no mentions of this kind of internal search. Is this OK, or I'm missing something in my setup? Thanks!
Are there any searches that contain "dnaRemoteConnProtocol"? Can you attach the access log?
Created attachment 984461 [details] access log
Thanks for getting the access log. This can be marked verified. It's okay if there is not a matching search, we are only concerned if there is more than 1.
Thank you, Mark! Marking this bug as VERIFIED.
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://rhn.redhat.com/errata/RHSA-2015-0416.html