Hi,
I've been trying to use a tool called "Grouper" to provision a hierarchical structure into my LDAP directory.
I'm currently running OpenLDAP 2.4.25 with BDB 4.8.30 on 3 SL5.5 servers in a multi-master configuration.
During the provisioning process it seems to be hitting a race condition where it creates a higher-level ou before the base-level ou is there resulting in the base-level ou existing in the tree with the "glue" objectClass.
As this is invisible to searches I end up with syncrepl constantly trying to replicate it ad infinitum:
Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 be_modify ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk (0) Jun 10 14:53:16 alder slapd[20702]: syncprov_sendresp: cookie= Jun 10 14:53:16 alder slapd[20702]: do_syncrep2: rid=032 cookie= Jun 10 14:53:16 alder slapd[20702]: do_syncrep2: rid=031 cookie= Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=032 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=032 be_search (0) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=032 ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 be_search (0) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk Jun 10 14:53:16 alder slapd[20702]: syncprov_sendresp: cookie= Jun 10 14:53:17 alder last message repeated 210 times Jun 10 14:53:17 alder slapd[20702]: syncrepl_entry: rid=032 be_modify ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk (0) Jun 10 14:53:17 alder slapd[20702]: do_syncrep2: rid=032 cookie= Jun 10 14:53:17 alder slapd[20702]: syncrepl_entry: rid=032 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Doing a bit of digging on the web the suggested solution is to modify the object and remove the glue objectlcass but there doesn't seem to be an obvious way to do this given that it's invisible to ldapsearch and if you try an ldapadd the object already exists?
Even a sample ldif file for ldapmodify would be grand.
Cheers,
Mark
/********************************* Mark Cairney ITI UNIX Section Information Services University of Edinburgh
Tel: 0131 650 6565 Email: mark.cairney@ed.ac.uk
*********************************/
--On Friday, June 10, 2011 3:04 PM +0100 Mark Cairney Mark.Cairney@ed.ac.uk wrote:
Hi,
I've been trying to use a tool called "Grouper" to provision a hierarchical structure into my LDAP directory.
I'm currently running OpenLDAP 2.4.25 with BDB 4.8.30 on 3 SL5.5 servers in a multi-master configuration.
During the provisioning process it seems to be hitting a race condition where it creates a higher-level ou before the base-level ou is there resulting in the base-level ou existing in the tree with the "glue" objectClass.
As this is invisible to searches I end up with syncrepl constantly trying to replicate it ad infinitum:
I would suggest filing an ITS with configurations and exact instructions on how to reproduce the issue at http://www.openldap.org/its/
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi Quanah,
Thanks for the reply- in the meantime is there any way I can apply some "first-aid" to work around the issue and make the ghost OUs appear as expected? I've also asked a similar question on the Grouper mailing list as it may be a case of "garbage in, garbage out".
The behaviour of OpenLDAP is a little bit odd as well though so I'll file an ITS.
Cheers,
Mark
On 10 Jun 2011, at 16:30, Quanah Gibson-Mount wrote:
--On Friday, June 10, 2011 3:04 PM +0100 Mark Cairney Mark.Cairney@ed.ac.uk wrote:
Hi,
I've been trying to use a tool called "Grouper" to provision a hierarchical structure into my LDAP directory.
I'm currently running OpenLDAP 2.4.25 with BDB 4.8.30 on 3 SL5.5 servers in a multi-master configuration.
During the provisioning process it seems to be hitting a race condition where it creates a higher-level ou before the base-level ou is there resulting in the base-level ou existing in the tree with the "glue" objectClass.
As this is invisible to searches I end up with syncrepl constantly trying to replicate it ad infinitum:
I would suggest filing an ITS with configurations and exact instructions on how to reproduce the issue at http://www.openldap.org/its/
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
/********************************* Mark Cairney ITI UNIX Section Information Services University of Edinburgh
Tel: 0131 650 6565 Email: mark.cairney@ed.ac.uk
*********************************/
Hi,
Just for completeness the issue turned out to be time synchronisation- one of the 3 nodes was still going to RHN for it's NTP sync rather than our local NTP server which the other 2 were pointed at. I'm guessing that there wasn't enough of a difference for the sync cookie to be rejected but enough of a time skew that they were received in the wrong order although this is pure conjecture on my part and am happy to be proven wrong. They now appear to be a lot happier!
Thanks,
Mark
On 10 Jun 2011, at 16:30, Quanah Gibson-Mount wrote:
--On Friday, June 10, 2011 3:04 PM +0100 Mark Cairney Mark.Cairney@ed.ac.uk wrote:
Hi,
I've been trying to use a tool called "Grouper" to provision a hierarchical structure into my LDAP directory.
I'm currently running OpenLDAP 2.4.25 with BDB 4.8.30 on 3 SL5.5 servers in a multi-master configuration.
During the provisioning process it seems to be hitting a race condition where it creates a higher-level ou before the base-level ou is there resulting in the base-level ou existing in the tree with the "glue" objectClass.
As this is invisible to searches I end up with syncrepl constantly trying to replicate it ad infinitum:
I would suggest filing an ITS with configurations and exact instructions on how to reproduce the issue at http://www.openldap.org/its/
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
/********************************* Mark Cairney ITI UNIX Section Information Services University of Edinburgh
Tel: 0131 650 6565 Email: mark.cairney@ed.ac.uk
*********************************/
openldap-technical@openldap.org
-
Mark Cairney -
Quanah Gibson-Mount