sascha.kuehndel@deka.de wrote:
> Full_Name: Sascha Kuehndel
> Version: 2.4.33 + ITS#7418
> OS: HP-UX 11.31
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (192.166.104.102)
>
>
> Hallo,
>
> the constraints seams to block the sync-replication.
>
> constraint_attribute dekanetZielgruppenDN uri
>    ldap:///ou=Zielgruppen,ou=dekanet,dc=dekager,dc=dekabank,dc=extern?entryDN?one?(objectClass=dekanetZielgruppe)
>    restrict=ldap:///ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern??one

Seems this is an improper config. If you already have constraints enforced on 
the provider, then only valid entries may be replicated, so constraints on the 
consumer are superfluous.

> the replication syncs the users in ou=Benutzer first, and later the groups  of
> ou=Zielgruppen.
> The be_add of the user failed in the consumer, until commenting out the
> constraint.
>
> here the relevant part of the log file
> 50c84eff syncrepl_message_to_entry: rid=002 DN:
> uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern, UUID: XXX-UUID
> 50c84eff syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
> 50c84eff syncrepl_entry: rid=002 inserted UUID XXX-UUID
> 50c84eff syncrepl_entry: rid=002 be_search (0)
> 50c84eff syncrepl_entry: rid=002
> uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern
> 50c84f00 slap_queue_csn: queing 6000000000a1d9c0
> 20120926141541.717811Z#000000#002#000000
> 50c84f00 slap_graduate_commit_csn: removing 6000000012baa390
> 20120926141541.717811Z#000000#002#000000
> 50c84f00 null_callback : error code 0x13
> 50c84f00 syncrepl_entry: rid=002 be_add
> uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern (19)
> 50c84f00 syncrepl_entry: rid=002 be_add
> uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern failed (19)
> 50c84f00 do_syncrepl: rid=002 rc 19 retrying
>
>
> Greets,
> Sascha
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Hi,

the problem is the order of the sync process.
First the users are sync. At this moment the consumer don't have any group entry.
So the constraints checks the dekanetZielgruppenDN against a not existing subtree. 
The result is: the user entry is not added.

Sascha

Sascha.Kuehndel@deka.de wrote:
> Hi,
>
> the problem is the order of the sync process.
> First the users are sync. At this moment the consumer don't have any group entry.
> So the constraints checks the dekanetZielgruppenDN against a not existing subtree.
> The result is: the user entry is not added.

Yes, but that's irrelevant. Even if the groups were fully replicated already, 
if the provider sent an invalid user, this constraint overlay on the consumer 
would correctly reject it and replication would still break.

The config is nonsensical. Closing this ITS.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

changed state Open to Closed

> Yes, but that's irrelevant. Even if the groups were fully replicated already
I have tested the user entry on provider (with constraints active) the entry is accepted!
So the entry is valid!

Sascha

Hi Howard,

Sorry for the much "!"

I have written a new config, only with constraint and replication.
I have reduce the database to 56 entries.

In this configuration I can reproduce this error.

my steps.
1. F1> slapadd -f slapd.conf -f initial.ldif 2. F1> slapd -h ldap://0.0.0.0:4001 -f slapd.conf 3. F1> slapd -h ldap://0.0.0.0:4002 -f slapd.conf

In the log of F2, the sync stops with the first user. And this moment the root-entry and ou=users is synced, only.

I hope you can reproduce the error, too.

Sascha

PS: tested with 2.4.32 have the problem, too.

--On Thursday, November 01, 2012 3:03 PM +0000 Sascha.Kuehndel@deka.de 
wrote:

> --_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi Howard,
>
> Sorry for the much "!"
>
> I have written a new config, only with constraint and replication.
> I have reduce the database to 56 entries.
>
> In this configuration I can reproduce this error.
>
> my steps.
> 1. F1> slapadd -f slapd.conf -f initial.ldif 2. F1> slapd -h
> ldap://0.0.0.0= :4001 -f slapd.conf 3. F1> slapd -h ldap://0.0.0.0:4002
> -f slapd.conf

Your message isn't particularly clear on what it is you are doing now.  As 
Howard noted, it is only valid to have slapo-constraint on the provider, 
and not on any of the replicas.  Using slapadd does not necessarily 
guarantee that your entry is valid, as slapadd can bypass some overlay 
checks.

--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,

in real it is a multi-master-replication. 
So the constraints have to define on both sides.

I have check the entry, more than one time. (many more)
so i really sure, it is valid. (changed the attribute to another value and back on the procurer)

I think it is a tricky timing problem, and it appears only in special situations.
I found it, in a restore of a system with an backup. After imported it in the procurer1,  I started the  second one.
At the next morning the sync wasn't complete. And I wondered why.

Another test shows the problem, a little bit more.
I changed the order of the entries in the initial.ldif (groups in front of users), and the sync works.

In the last message, was a little type. In the database only 6 entries (not 56)

Sascha

PS: sorry my English is not very well

--On Thursday, November 01, 2012 4:47 PM +0000 Sascha.Kuehndel@deka.de 
wrote:

> Hi,
>
> in real it is a multi-master-replication.
> So the constraints have to define on both sides.

If you could provide your exact config and the LDIF files you are loading, 
that would help.  Please strip out any passwords and other individual 
identifying information.

Thanks.

--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

hyc@symas.com wrote:
> Sascha.Kuehndel@deka.de wrote:
>> the problem is the order of the sync process.
>> First the users are sync. At this moment the consumer don't have any group entry.
>> So the constraints checks the dekanetZielgruppenDN against a not existing subtree.
>> The result is: the user entry is not added.
> 
> Yes, but that's irrelevant. Even if the groups were fully replicated already, 
> if the provider sent an invalid user, this constraint overlay on the consumer 
> would correctly reject it and replication would still break.

IMO Sascha says that the group and user entries were written in correct order
to the first provider, successfully passed the constraints there but are then
replicated in different order to the second provider which also checks the
same constraints again. Since the order is significant for the constraint it
fails on the second provider. (Both are configured with same constraints.)

The solution would be to not check constraints for replicated ops. It's
similar to the problem space when/whether to apply slapo-refint,
slapo-memberof etc. in case of replicated ops.

Ciao, Michael.

michael@stroeder.com wrote:
> hyc@symas.com wrote:
>> Sascha.Kuehndel@deka.de wrote:
>>> the problem is the order of the sync process.
>>> First the users are sync. At this moment the consumer don't have any group entry.
>>> So the constraints checks the dekanetZielgruppenDN against a not existing subtree.
>>> The result is: the user entry is not added.
>>
>> Yes, but that's irrelevant. Even if the groups were fully replicated already,
>> if the provider sent an invalid user, this constraint overlay on the consumer
>> would correctly reject it and replication would still break.
>
> IMO Sascha says that the group and user entries were written in correct order
> to the first provider, successfully passed the constraints there but are then
> replicated in different order to the second provider which also checks the
> same constraints again. Since the order is significant for the constraint it
> fails on the second provider. (Both are configured with same constraints.)
>
> The solution would be to not check constraints for replicated ops. It's
> similar to the problem space when/whether to apply slapo-refint,
> slapo-memberof etc. in case of replicated ops.

OK, that sounds fine. The corresponding fix is now in git master, please test.
commit b4126863a4443630392afc50de65b0c90de2304f

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

changed notes
changed state Closed to Test
moved from Incoming to Software Bugs

Hi Howard,

today, i have tested the patch.

1) make test -> successful
2) sync in small example -> successful
3) sync in the real configuration -> successful, too

Thanks to all,
Sascha

changed notes
changed state Test to Release

changed notes
changed state Release to Closed

fixed in master
fixed in RE24