OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/7426
Full headers

From: sascha.kuehndel@deka.de
Subject: contraints blocks syncreplication
Compose comment
Download message
State:
0 replies:
11 followups: 1 2 3 4 5 6 7 8 9 10 11

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 01 Nov 2012 13:00:38 +0000
From: sascha.kuehndel@deka.de
To: openldap-its@OpenLDAP.org
Subject: contraints blocks syncreplication
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

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

Followup 1

Download message
Date: Thu, 01 Nov 2012 06:21:52 -0700
From: Howard Chu <hyc@symas.com>
To: sascha.kuehndel@deka.de
CC: openldap-its@openldap.org
Subject: Re: (ITS#7426) contraints blocks syncreplication
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/



Followup 2

Download message
From: <Sascha.Kuehndel@deka.de>
To: <hyc@symas.com>
CC: <openldap-its@openldap.org>
Date: Thu, 1 Nov 2012 14:27:27 +0100
Subject: AW: (ITS#7426) contraints blocks syncreplication
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



Followup 3

Download message
Date: Thu, 01 Nov 2012 06:59:30 -0700
From: Howard Chu <hyc@symas.com>
To: Sascha.Kuehndel@deka.de
CC: openldap-its@openldap.org
Subject: Re: AW: (ITS#7426) contraints blocks syncreplication
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/



Followup 4

Download message
From: <Sascha.Kuehndel@deka.de>
To: <hyc@symas.com>
CC: <openldap-its@openldap.org>
Date: Thu, 1 Nov 2012 15:03:38 +0100
Subject: AW: AW: (ITS#7426) contraints blocks syncreplication
> 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



Followup 5

Download message
From: <Sascha.Kuehndel@deka.de>
To: <openldap-its@openldap.org>
Date: Thu, 1 Nov 2012 16:02:47 +0100
Subject: WG: AW: (ITS#7426) contraints blocks syncreplication
--_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

In the log of F2, the sync stops with the first user. And this moment the r=
oot-entry and ou=3Dusers is synced, only.

I hope you can reproduce the error, too.

Sascha

PS: tested with 2.4.32 have the problem, too.


--_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_
Content-Type: application/x-tar; name="ITS_7426.tar"
Content-Description: ITS_7426.tar
Content-Disposition: attachment; filename="ITS_7426.tar"; size=10240;
	creation-date="Thu, 01 Nov 2012 14:56:56 GMT";
	modification-date="Thu, 01 Nov 2012 14:55:43 GMT"
Content-Transfer-Encoding: base64

RjEvc2xhcGQuY29uZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDA2NDQAMDAwMDYw
NQAwMDAwMDAxADAwMDAwMDAyNDM1ADEyMDQ0NTAzNzA2ADAwMTQxMTUAMAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNfc2xhcGQAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAb3RoZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAwADAwMDAw
MDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj
IFNjaGVtYXRhIGF1cyBkZXIgT3BlbkxEQVAtRGlzdHJpYnV0aW9uCmluY2x1ZGUJICAgICAgICAg
ICAgICAgICBzbGFwZC9ldGMvb3BlbmxkYXAvc2NoZW1hL2NvcmUuc2NoZW1hCmluY2x1ZGUJICAg
ICAgICAgICAgICAgICBzbGFwZC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKCiMg
TG9hZCBtb2R1bGVzCm1vZHVsZXBhdGggICAgICAgICAgICAgICBzbGFwZC9saWJleGVjL29wZW5s
ZGFwCm1vZHVsZWxvYWQgICAgICAgICAgICAgICBiYWNrX2hkYi5sYQptb2R1bGVsb2FkICAgICAg
ICAgICAgICAgY29uc3RyYWludC5sYQptb2R1bGVsb2FkICAgICAgICAgICAgICAgc3luY3Byb3Yu
bGEKCiMgQmFzZSBrb25maWd1cmF0aW9uCnBpZGZpbGUgICAgICAgICAgICAgICAgICBzbGFwZC5w
aWQKYXJnc2ZpbGUgICAgICAgICAgICAgICAgIHNsYXBkLmFyZ3MKCiMgRGF0YWJhc2UKZGF0YWJh
c2UgICAgICAgICAgICAgICAgIGhkYgoKc3VmZml4ICAgICAgICAgICAgICAgICAgICJvdT1kZWth
LGRjPWV4YW1wbGUsZGM9Y29tIgpkaXJlY3RvcnkgICAgICAgICAgICAgICAgZXhhbXBsZQpyb290
ZG4gICAgICAgICAgICAgICAgICAgImNuPXJvb3Qsb3U9ZGVrYSxkYz1leGFtcGxlLGRjPWNvbSIK
cm9vdHB3ICAgICAgICAgICAgICAgICAgIHJvb3QKCm92ZXJsYXkgY29uc3RyYWludApjb25zdHJh
aW50X2F0dHJpYnV0ZSBhc3NvY2lhdGVkTmFtZSB1cmkKICBsZGFwOi8vL291PWdyb3VwLG91PWRl
a2EsZGM9ZXhhbXBsZSxkYz1jb20/ZW50cnlETj9vbmU/KG9iamVjdENsYXNzPWFjY291bnQpCiAg
cmVzdHJpY3Q9bGRhcDovLy9vdT11c2VyLG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20/P29uZQoK
CmluZGV4ICAgICAgICAgICAgICAgICAgICBlbnRyeUNTTiBlcQppbmRleCAgICAgICAgICAgICAg
ICAgICAgZW50cnlVVUlEIGVxCgpvdmVybGF5IHN5bmNwcm92CnN5bmNwcm92LWNoZWNrcG9pbnQg
ICAgICAxMDAgNQpzeW5jcHJvdi1zZXNzaW9ubG9nICAgICAgMTAwCnN5bmNwcm92LXJlbG9hZGhp
bnQgICAgICBUUlVFCnN5bmNyZXBsCiAgICByaWQ9MDAxCiAgICBwcm92aWRlcj1sZGFwOi8vbG9j
YWxob3N0OjQwMDIKICAgIGNyZWRlbnRpYWxzPXJvb3QKICAgIGJpbmRkbj0iY249cm9vdCxvdT1k
ZWthLGRjPWV4YW1wbGUsZGM9Y29tIgogICAgYmluZG1ldGhvZD1zaW1wbGUKICAgIHNlYXJjaGJh
c2U9Im91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20iCiAgICBzY2hlbWFjaGVja2luZz1vbgogICAg
dHlwZT1yZWZyZXNoQW5kUGVyc2lzdAogICAgcmV0cnk9IjMwICsiCm1pcnJvcm1vZGUgb24KAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGMS9p
bml0aWFsLmxkaWYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDY0NAAwMDAwNjA1ADAw
MDAwMDEAMDAwMDAwMDI3MjIAMTIwNDQ1MDM0NjEAMDAxNDQzMQAwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwc19zbGFwZAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABvdGhlcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMDAAMDAwMDAwMAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRuOiBv
dT1kZWthLGRjPWV4YW1wbGUsZGM9Y29tCm91OiBkZWthbmV0Cm9iamVjdENsYXNzOiBvcmdhbml6
YXRpb25hbFVuaXQKc3RydWN0dXJhbE9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKZW50
cnlVVUlEOiA3YjlkZDlkMi1iMGJjLTEwMzEtOWYyNS0wNTliZWIwYmI1M2MKZW50cnlDU046IDIw
MTIxMDIyMTc0ODUwLjgxMDQ2N1ojMDAwMDAwIzAwMCMwMDAwMDAKCmRuOiBvdT11c2VyLG91PWRl
a2EsZGM9ZXhhbXBsZSxkYz1jb20Kb3U6IEJlbnV0emVyCm9iamVjdENsYXNzOiBvcmdhbml6YXRp
b25hbFVuaXQKc3RydWN0dXJhbE9iamVjdENsYXNzOiBvcmdhbml6YXRpb

Message of length 14997 truncated


Followup 6

Download message
Date: Thu, 01 Nov 2012 09:24:10 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Sascha.Kuehndel@deka.de, openldap-its@openldap.org
Subject: Re: WG: AW: (ITS#7426) contraints blocks syncreplication
--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



Followup 7

Download message
From: <Sascha.Kuehndel@deka.de>
To: <quanah@zimbra.com>, <openldap-its@openldap.org>
CC: <hyc@symas.com>
Date: Thu, 1 Nov 2012 17:46:32 +0100
Subject: AW: WG: AW: (ITS#7426) contraints blocks syncreplication
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



Followup 8

Download message
Date: Thu, 01 Nov 2012 10:05:08 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Sascha.Kuehndel@deka.de, openldap-its@openldap.org
Subject: Re: AW: WG: AW: (ITS#7426) contraints blocks syncreplication
--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



Followup 9

Download message
Date: Thu, 01 Nov 2012 19:36:11 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#7426) contraints blocks syncreplication
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.



Followup 10

Download message
Date: Thu, 01 Nov 2012 17:58:48 -0700
From: Howard Chu <hyc@symas.com>
To: Sascha.Kuehndel@deka.de
CC: openldap-its@openldap.org
Subject: Re: (ITS#7426) contraints blocks syncreplication
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/



Followup 11

Download message
From: <Sascha.Kuehndel@deka.de>
To: <hyc@symas.com>
CC: <openldap-its@openldap.org>, <michael@stroeder.com>
Date: Fri, 2 Nov 2012 14:20:11 +0100
Subject: AW: (ITS#7426) contraints blocks syncreplication
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


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org