On 02/22/2012 10:23 AM, Colin Hudler wrote:
Greetings,
Haven't used OpenLDAP since 2.1; I see it has come a long way. I have a few hundred static groups and am using the memberOf overlay. There's a hundred thousand or so people entries and thousands of memberships. The overlay is configured thusly:
<snip>
4f450e2d syncrepl_entry: rid=004 cn=uc:org:nsit:integration:techag,ou=groups,dc=uchicago,dc=edu 4f450e2d conn=-1 op=0: memberof_op_add("cn=uc:org:nsit:integration:techag,ou=groups,dc=uchicago,dc=edu"): member="uid=chudler,ou=people,dc=uchicago,dc=edu" does not exist (stripping...) slapd: entry.c:773: entry_encode: Assertion `i == a->a_numvals' failed.
The member ("uid=chudler") does exist in the master, I can find it with ldapsearch. I believe it does not yet exist in the replica. I'd like for total replication to succeed without doing an initial slapcat. Has anyone encountered this before? I am happy to debug if you need more information.
Version 2.4.29, also using the refint overlay if that matters.
Attached is a one line patch. I figured this is related to bug #6508 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6508. The fix there still does not decrement a->a_numvals when the loop terminate early. So this patch addresses that. I haven't done testing except "make test".
There's something higher wrong with what I'm doing, however. As configured, memberOf will drop the member from the group because it does not yet exist. What would be better is a sort of two-pass replication so the contents are stable before it starts dropping members. I'm trying to decide the cleanest way for me to do that, given that these are mirrormode masters with replicated configs. Perhaps someone has encountered this problem before..
I know that the overlay is unaware that the directory contents are still stabilizing. Perhaps I should alter the memberOf overlay (memberof-dangling=ignore) until replication has completely refreshed, then manually do a second pass to find dangling values? The goal is a simple and repeatable process to completely refresh a server, ideally allowing replication to do the work. Better for us might be to hold down synchronization of group containers until members has been fully refreshed (how?).