When using entry distribution with a local db, each db has to have a copy of the root entry. For example, if you have a suffix ou=people,dc=example,dc=com with backends be1,be2,be3,be4 - each backend must have the entry

dn: ou=people,dc=example,dc=com
objectclass: organizationalunit
....

This is problematic from the standpoint of access control, replication, etc.

Furthermore, the only way to add this entry is by using an import e.g.
create an ldif file with the entry in it
then

for be in be1 be2 be3 be4 ; do ldif2db -n $be rootentry.ldif ; done

This makes it difficult to set up via LDAP:

• python-ldap in RHEL6 does not support extended operations, so the bulk import extop cannot be used with python. Support was added to python-ldap 2.4.
• openldap ldapmodify does not support bulk import - ldapexop does, but there is no way, using a single connection, to issue the bulk import begin extop, then one or more add operations, then the bulk import stop extop.
• mozldap ldapmodify does support bulk import, but it is of limited availability.
• perl Net::LDAP can be used to perform a bulk import, but the use of perl is discouraged.
• Import jobs can be triggered with tasks, but this means the ldif file must be copied to the remote server first, which is out of band of LDAP.

One solution to use LDAP would be to extend the MTN_CONTROL_USE_ONE_BACKEND_OID and MTN_CONTROL_USE_ONE_BACKEND_EXT_OID controls for use with ADD operations. Then an LDAP client could use the control and an add operation to populate all of the backends.

Another solution would be to figure out a way to have only 1 copy of the root entry. This may be very difficult because the ldbm_add.c code assumes the use of only 1 backend. Perhaps entry distribution should always create an additional backend for the root entry and any other entries which should not be distributed, and the ldbm_add code should be changed to handle the case where the parent is in a different database backend.