[Date Prev][Date Next]
Re: (ITS#4626) "glue" objectclass in syncrepl consumer
> On Thu, Aug 17, 2006 at 01:49:51PM +0000, email@example.com wrote:
>> On Thu, Aug 17, 2006 at 05:08:02AM +0000, firstname.lastname@example.org wrote:
>>>> This still happens with 2.3.25cvs (REL_ENG_2_3 checked out a few hours
>>>> ago). The "ou=global" entry gets the glue objectClass.
>>>> It's very similar to what was described here about an year ago:
>>>> I don't have any filter specified in any consumer, so it should fetch
>>>> the whole thing. I managed, however, to sometimes get the ou=global
>>>> entry correctly, i.e., without the glue objectClass. So a race condition
>>>> perhaps? Ordering of results?
>>> Ordering maybe. But eventually the entry should get replicated, and the
>>> consumer should replace everything with the correct objectclasses. I
>>> guess there's a possibility that we're not setting the right flags to
>>> allow the consumer to change the entry's structuralObjectClass.
>> I'll get a syncrepl debug dump from the first replication to check on
>> the ordering and leave it like that for some time and paste the results
> It's below:
> slapd starting
> request done: ld 0x820f128 msgid 1
> syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
> syncrepl_entry: be_search (32)
> syncrepl_entry: dc=example,dc=com
> is_entry_objectclass("", "188.8.131.52") no objectClass attribute
> is_entry_objectclass("", "184.108.40.206") no objectClass attribute
> is_entry_objectclass("", "2.16.840.1.1137220.127.116.11") no objectClass attribute
> syncrepl_entry: be_add (0)
This says that no objectClass attribute was returned to the syncrepl
consumer from the provider. Have you checked your ACLs on the provider?
> It stays like this forever.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/