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