Logged in as guest
Viewing Software Bugs/7426 Full headers
Major security issue: yes no
Notes: fixed in master fixed in RE24 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
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/
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
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/
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
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
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
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
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
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.
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/
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
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
