Openldap version 2.4.35
Our global ldap server has the following naming contexts:
namingContexts: o=global,ou=studios,dc=methodstudios,dc=net namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net namingContexts: ou=studios,dc=methodstudios,dc=net namingContexts: ou=login,dc=methodstudios,dc=net
ou=studio,dc=methodstudios,dc=net is the superior database and global, chi01, det01, la01, ny01, lon01, van01 are all have "subordinate advertise" and are all sync providers.
The sync provider:
database mdb suffix "ou=studios,dc=methodstudios,dc=net" rootdn ... rootpw ... directory /var/lib/ldap/studios.methodstudios.net maxsize 17179869184 serverID 201
overlay glue overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 sync_use_subentry true
...
The sync consumer only has a database for ou=studios,dc=methodstudios,dc=net.
database mdb suffix "ou=studios,dc=methodstudios,dc=net" rootdn ... rootpw ... directory /var/lib/ldap/studios.methodstudios.net maxsize 17179869184 serverID 202
syncrepl rid=201 provider=ldap://<providor host name> type=refreshAndPersist retry="60 10 300 +" searchbase="ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="..." credentials=... schemachecking=off sizelimit=unlimited timelimit=unlimited updateref ldap://<providor host name>
It seems to be only syncing ou=studios,dc=methodstudios,dc=net and o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of the provider server so that chi01 comes before global then only syncing ou=studios,dc=methodstudios,dc=net and o=chi01,ou=studios,dc=methodstudios,dc=net get sync.
Am I doing anything obviously wrong?
After some more testing f I turn off syncprov on all of my subordinates and leave syncprov on on my superior it works. So it seems to be a problem with having syncprov on subordinates.
On 12/18/2013 03:34 PM, Robert Minsk wrote:
Openldap version 2.4.35
Our global ldap server has the following naming contexts:
namingContexts: o=global,ou=studios,dc=methodstudios,dc=net namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net namingContexts: ou=studios,dc=methodstudios,dc=net namingContexts: ou=login,dc=methodstudios,dc=net
ou=studio,dc=methodstudios,dc=net is the superior database and global, chi01, det01, la01, ny01, lon01, van01 are all have "subordinate advertise" and are all sync providers.
The sync provider:
database mdb suffix "ou=studios,dc=methodstudios,dc=net" rootdn ... rootpw ... directory /var/lib/ldap/studios.methodstudios.net maxsize 17179869184 serverID 201
overlay glue overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 sync_use_subentry true
...
The sync consumer only has a database for ou=studios,dc=methodstudios,dc=net.
database mdb suffix "ou=studios,dc=methodstudios,dc=net" rootdn ... rootpw ... directory /var/lib/ldap/studios.methodstudios.net maxsize 17179869184 serverID 202
syncrepl rid=201 provider=ldap://<providor host name> type=refreshAndPersist retry="60 10 300 +" searchbase="ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="..." credentials=... schemachecking=off sizelimit=unlimited timelimit=unlimited updateref ldap://<providor host name>
It seems to be only syncing ou=studios,dc=methodstudios,dc=net and o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of the provider server so that chi01 comes before global then only syncing ou=studios,dc=methodstudios,dc=net and o=chi01,ou=studios,dc=methodstudios,dc=net get sync.
Am I doing anything obviously wrong?
-- Robert Minsk Systems and Software Engineer
WWW.METHODSTUDIOS.COM http://www.methodstudios.com 730 Arizona Ave, Santa Monica, CA 90401 O:+1 310 434 6500 tel:+13104346500 // F:+1 310 434 6501 tel:+13104346501
Los Angeles http://www.methodstudios.com/signature/url/los-angeleshttp://www.methodstudios.com/signature/url/los-angeles
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
openldap-technical@openldap.org