- openldap-bugs - openldap.org

(ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by vb4607＠att.com 06 Nov '12

06 Nov '12

Full_Name: Venkatesh Baglodi Version: 2.4.32 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.76.64.65) We have been facing frequent memory utilization issues with OpenLDAP 2.4.32 in our production environment (multi-master mode, 6 servers), which requires OpenLDAP server instances to be restarted almost every week. Utilization starts at a lower percentage to start with (2-3%), but then gradually moves up and never comes down. We have been using OpenLDAP 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). Are there any known issues with this version?

1 0

Re: (ITS#7432) slapd crashes when removing members from a large group
by hyc＠symas.com 05 Nov '12

05 Nov '12

marvin.mundry(a)uni-hamburg.de wrote: > Full_Name: Marvin Mundry > Version: 2.4.33 > OS: Ubuntu 12.10 > URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz > Submission from: (NULL) (134.100.2.183) > Thanks for the report. The crash has been fixed in git, but your test runs into another (known) issue in MDB. You're working with a very large entry, which libmdb stores in overflow pages. In the current version of libmdb, freespace management for overflow pages is not fully implemented, so every time you update the entry libmdb will always use new pages (instead of reusing old pages). Thus, after a few hundred operations, your 1GB map will be exhausted. It looks like you won't be able to use back-mdb until this feature is fully implemented in libmdb. > i have slapcat'ed my production environment and slapadded it into an back_mdb > database. > > when deleting members one by one from a large group (48428 Members), after some > transactions slapd crashes. > when i slapadd my dit to an mdb without having an eq index configured for > "member" the removal of members works fine. > > when doing the same thing (member indexed, slapadding members, starting slapd, > removing group members one by one) on a hdb, slapd does not crash. > > sortvals is set for members as otherwise deletion operations would take a very > long time > > i failed to reproduce the problem without initially slapadding the data from my > production environment into the mdb. > > i have removed all configuration settings not neccessary to reproduce the bug > > the debug.tar.bz should contain everything that is neccessary (including a > description) to reproduce the problem. additionally the file contains a coredump > and the full trace output > > slapd.conf: > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/rfc2307bis.schema > pidfile /usr/local/var/run/slapd.pid > argsfile /usr/local/var/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_mdb.la > sortvals member > database mdb > suffix "dc=test,dc=com" > rootdn "cn=admin,dc=test,dc=com" > rootpw secret > directory /usr/local/etc/openldap/test123db/AL > index member eq > maxsize 1000000000 > > > last lines of slapd -d Trace: > 5096b5ae oc_check_allowed type "modifyTimestamp" > 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times > 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > > build options: > CFLAGS=-O0 -d > ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes > --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye > s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod > --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl > > --enable-debug > > (gdb) bt: > #0 0x000002fc000002fa in ?? () > #1 0x000002ff000002fd in ?? () > #2 0x0000030200000300 in ?? () > #3 0x0000030500000303 in ?? () > #4 0x0000030800000306 in ?? () > #5 0x0000030b00000309 in ?? () > #6 0x00007f1400000312 in ?? () > #7 0x0000009cffffffbf in ?? () > #8 0x00007f1400000011 in ?? () > #9 0x00000000000102a3 in ?? () > #10 0x00007f140c101880 in ?? () > #11 0x00007f140883c200 in ?? () > #12 0x0000000000000891 in ?? () > #13 0x00007f14155ef060 in ?? () > #14 0x00007f14523dd5a6 in ?? () > #15 0x00007f1451fa1010 in ?? () > #16 0x00000000523dd2a7 in ?? () > #17 0x00007f14155ef390 in ?? () > #18 0x0000000000000000 in ?? () > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 05 Nov '12

05 Nov '12

On 11/04/2012 05:33 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 > OS: openSUSE 12.2 x86_64 > URL: > Submission from: (NULL) (79.227.185.139) > > > I get a seg fault when adding group entries with some regex-constrained > attributes. This is RE24 with the recent fixes for slapo-constraint. The > constraint setup works with 2.4.31. > > Strange thing is that the entry is added to the database. So it seems to me that > the seg fault happens after that while checking constraints for what > slapo-memberof does? > > As often this is a complex customer setup. So it's not that easy to narrow down > the config and strip aways private customer data in a full traceback. I will do > if really necessary. > > Maybe this gives a first hint where to look: > > No symbol "info" in current context. > (gdb) info threads > Id Target Id Frame > 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () > from /lib64/libc.so.6 > 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () > from /lib64/libpthread.so.0 > 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in > constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at > constraint.c:713 > Hello Michael, can you please provide a full backtrace of thread 1? A quick look suggest that there's something wrong, because constraint_check_restrict probably should not be called with e=0x0, but I'm unable to tell anything else with such restricted information. Also, if the problem is in my fix, it should be fairly easily reproducible with just a few slapadds with the right data. Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7432) slapd crashes when removing members from a large group
by marvin.mundry＠uni-hamburg.de 05 Nov '12

05 Nov '12

Full_Name: Marvin Mundry Version: 2.4.33 OS: Ubuntu 12.10 URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz Submission from: (NULL) (134.100.2.183) i have slapcat'ed my production environment and slapadded it into an back_mdb database. when deleting members one by one from a large group (48428 Members), after some transactions slapd crashes. when i slapadd my dit to an mdb without having an eq index configured for "member" the removal of members works fine. when doing the same thing (member indexed, slapadding members, starting slapd, removing group members one by one) on a hdb, slapd does not crash. sortvals is set for members as otherwise deletion operations would take a very long time i failed to reproduce the problem without initially slapadding the data from my production environment into the mdb. i have removed all configuration settings not neccessary to reproduce the bug the debug.tar.bz should contain everything that is neccessary (including a description) to reproduce the problem. additionally the file contains a coredump and the full trace output slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/rfc2307bis.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_mdb.la sortvals member database mdb suffix "dc=test,dc=com" rootdn "cn=admin,dc=test,dc=com" rootpw secret directory /usr/local/etc/openldap/test123db/AL index member eq maxsize 1000000000 last lines of slapd -d Trace: 5096b5ae oc_check_allowed type "modifyTimestamp" 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com build options: CFLAGS=-O0 -d ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl --enable-debug (gdb) bt: #0 0x000002fc000002fa in ?? () #1 0x000002ff000002fd in ?? () #2 0x0000030200000300 in ?? () #3 0x0000030500000303 in ?? () #4 0x0000030800000306 in ?? () #5 0x0000030b00000309 in ?? () #6 0x00007f1400000312 in ?? () #7 0x0000009cffffffbf in ?? () #8 0x00007f1400000011 in ?? () #9 0x00000000000102a3 in ?? () #10 0x00007f140c101880 in ?? () #11 0x00007f140883c200 in ?? () #12 0x0000000000000891 in ?? () #13 0x00007f14155ef060 in ?? () #14 0x00007f14523dd5a6 in ?? () #15 0x00007f1451fa1010 in ?? () #16 0x00000000523dd2a7 in ?? () #17 0x00007f14155ef390 in ?? () #18 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7418) slapo-constraint are broken
by michael＠stroeder.com 04 Nov '12

04 Nov '12

This is a cryptographically signed message in MIME format. --------------ms020504060001080007040306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The recent fix for ITS#7418 might have caused another regression causing = a seg fault. Please have a look at http://www.openldap.org/its/index.cgi?findid=3D7431 Ciao, Michael. --------------ms020504060001080007040306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA0MTcxNTA3WjAjBgkq hkiG9w0BCQQxFgQU2S6ujsV//DKe24vs3qNZa3mUkuEwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAR/l43ew8i8amA4dE9byAvbfTT50nLLLVOMrTVoCFZk2trkOiFPhWPY3QcsEYncUPTrpI GHaDDCvnrsOp0S5bW3QOXkt0thuE95BFHoOsk6LQATGuCp6hz2WskWx8sJsLQ72zfoJY9Zne H8+0BkBF/otrgACAGEGJgSTiM/ay4IMAmt7JLyGdVSUQZErjP+GbSv7p+wFbQTdMyiUTTGuG OihXeKuKkiZ9CLKdYpjlVQYw5/cxzDWV27Iba0XylKDx1FyhjoWoHaKNpW6BgDSy2xTjWa/I GH2wb4CzyhDkjc3pHmgTSdtIVZ7fqvwgsssWfVV/BeDV4tUH2OZwflJrCgAAAAAAAA== --------------ms020504060001080007040306--

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

It also works when using constraint.c of OpenLDAP release 2.4.33. Maybe it's caused by fix for ITS#7418?

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

It works when using constraint.c of OpenLDAP release 2.4.32.

1 0

(ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

Full_Name: Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 OS: openSUSE 12.2 x86_64 URL: Submission from: (NULL) (79.227.185.139) I get a seg fault when adding group entries with some regex-constrained attributes. This is RE24 with the recent fixes for slapo-constraint. The constraint setup works with 2.4.31. Strange thing is that the entry is added to the database. So it seems to me that the seg fault happens after that while checking constraints for what slapo-memberof does? As often this is a complex customer setup. So it's not that easy to narrow down the config and strip aways private customer data in a full traceback. I will do if really necessary. Maybe this gives a first hint where to look: No symbol "info" in current context. (gdb) info threads Id Target Id Frame 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () from /lib64/libc.so.6 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () from /lib64/libpthread.so.0 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at constraint.c:713

1 0

(ITS#7430) building with gnutls-3.0.x fails
by travisghansen＠yahoo.com 03 Nov '12

03 Nov '12

Full_Name: Travis Glenn Hansen Version: openldap-2.4.33 OS: gentoo ~arch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.248.41.91) http://www.gnu.org/software/gnutls/manual/html_node/Upgrading-from-previous… It appears a handful of calls have new/updated renditions per the above link including (but not limited to) gnutls_certificate_get_x509_cas. Thanks! libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/apitest apitest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [ftest] Error 1 make[2]: *** Waiting for unfinished jobs.... libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/dntest dntest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/urltest urltest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/ltest test.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [dntest] Error 1 ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [urltest] Error 1 ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [ltest] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries' make: *** [all-common] Error 1

1 0

(ITS#7429) MDB crashing with slapo-valsort
by marco.pizzoli＠gmail.com 02 Nov '12

02 Nov '12

Full_Name: Marco Pizzoli Version: 2.4.33 OS: Linux 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) Hi, I'm aware I'm not providing a complete bug report, but as I wrote on the mailing list I'm in a situation where I simply can't do it. Feel free to close if not enough information will be provided or try to ask me other infos if it could be worth the doing. I slapadd-ed a pre-existent OpenLDAP database (2.4.16) on a new test system (2.4.33). The new setup uses back-mdb as database. I created a second specular system and successfully completed a sync-replication from the first of the servers. Repeated the procedure (drop/populate the db) 5 or 6 times, without any problem. I decided to enable the valsort overlay, instanciated on the mdb db. My configuration was simply: overlay valsort valsort-attr member dc=company,dc=XX alpha-ascend Now I have the slave always crashing at almost 70% of progress. I produced a "bt full" (which I can't copy/paste here) of the core and I can see in the "mdb_search <cut> search.c:352" section a lot of rows similar to this one: isc{ bv_val = 0x8 <Address 0x8 out of bounds>}, {bv_len = 140172391141264, bv_val = 0x7f7c6e041000 <Address 0x7f7c6e041000 out of bounds>},[cut] I would be happy to provide other infos but I can't copy paste the entire "bt full" output. I'm sorry about that. Thanks Marco Pizzoli

1 0

AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 02 Nov '12

02 Nov '12

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

1 0

Re: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 02 Nov '12

02 Nov '12

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> Sascha.Kuehndel(a)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/

1 0

Re: (ITS#7426) contraints blocks syncreplication
by michael＠stroeder.com 01 Nov '12

01 Nov '12

hyc(a)symas.com wrote: > Sascha.Kuehndel(a)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.

1 0

Re: (ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 01 Nov '12

01 Nov '12

I've just uploaded: ftp://ftp.openldap.org/incoming/rhafer-Use-non-blocking-IO-during-SSL-Hands… which tries to address the issue. If LDAP_OPT_NETWORK_TIMEOUT is set ldap_int_tls_start will switch to non-blocking IO and call ldap_int_tls_connect as often as needed unless it times out inbetween. Currently I have only tested this with openssl but AFAICS this should also work with the NSS and gnutls backends Please review and comment. Ralf

1 0

(ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 01 Nov '12

01 Nov '12

Full_Name: Ralf Haferkamp Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.80.202) Currently libldap is using blocking IO when performing the SSL handshake for ldaps:// connections (and when performing the StartTLS operation). The can lead to the client blocking forever in the ssl lib (in SSL_connect in case of openssl) if e.g. the server for whatever reason stops responding. It would be very helpful if libldap would use non-blocking IO during the handshake at least when LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_TIMEOUT?) are set.

1 0

Re: AW: WG: AW: (ITS#7426) contraints blocks syncreplication
by quanah＠zimbra.com 01 Nov '12

01 Nov '12

--On Thursday, November 01, 2012 4:47 PM +0000 Sascha.Kuehndel(a)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

1 0

AW: WG: AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

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

1 0

Re: WG: AW: (ITS#7426) contraints blocks syncreplication
by quanah＠zimbra.com 01 Nov '12

01 Nov '12

--On Thursday, November 01, 2012 3:03 PM +0000 Sascha.Kuehndel(a)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

1 0

(ITS#7427) Bogus entries with syncrepl/MMR
by hyc＠OpenLDAP.org 01 Nov '12

01 Nov '12

Full_Name: Howard Chu Version: 2.4.33 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc Related to ITS#7052 and #7162. We still see cases where some entries that were deleted on a master are resurrected on a consumer. This happens when a single consumer is talking to a pair of masters which are mirroring each other, and the consumer gets an old batch of updates from one master, duplicating updates it already received from the other master. The spurious Adds are being accepted because they were sent with no cookie CSN. These ops are embedded in a string of other old ops, which have cookie CSNs that are correctly being ignored. The fix is to set a flag to remember when we've seen an old op, and unset the flag when we're caught up. Then, for any ops that are received without a cookie CSN, if the flag is set, this means we're in the middle of a stream of old ops, and this op should be ignored.

1 0

WG: AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

--_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 b25hbFVuaXQKc3RydWN0dXJhbE9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKZW50cnlV VUlEOiA4YWQ4Y2ExMC1iMGJjLTEwMzEtOWYzYS0wNTliZWIwYmI1M2MKZW50cnlDU046IDIwMTIx MDIyMTc0OTE2LjM2MjU1NVojMDAwMDAwIzAwMCMwMDAwMDAKCmRuOiBkYz0xLG91PXVzZXIsb3U9 ZGVrYSxkYz1leGFtcGxlLGRjPWNvbQpkYzogMQpvYmplY3RDbGFzczogZG9tYWluCm9iamVjdENs YXNzOiB0b3AKYXNzb2NpYXRlZE5hbWU6IHVpZD0xNCxvdT1ncm91cCxvdT1kZWthLGRjPWV4YW1w bGUsZGM9Y29tCnN0cnVjdHVyYWxPYmplY3RDbGFzczogZG9tYWluCmVudHJ5VVVJRDogNzg4MGQw ZTYtYjBjMi0xMDMxLTg5NWItYTFhM2YyZmJhY2I3CmVudHJ5Q1NOOiAyMDEyMTAyMjE4MzE0Mi41 NjcyNzlaIzAwMDAwMCMwMDAjMDAwMDAwCgpkbjogZGM9MixvdT11c2VyLG91PWRla2EsZGM9ZXhh bXBsZSxkYz1jb20KZGM6IDIKb2JqZWN0Q2xhc3M6IGRvbWFpbgpvYmplY3RDbGFzczogdG9wCmFz c29jaWF0ZWROYW1lOiB1aWQ9MTQsb3U9Z3JvdXAsb3U9ZGVrYSxkYz1leGFtcGxlLGRjPWNvbQpz dHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IGRvbWFpbgplbnRyeVVVSUQ6IDgwNDE1MjU2LWIwYzItMTAz MS04OTVjLWExYTNmMmZiYWNiNwplbnRyeUNTTjogMjAxMjEwMjIxODMxNTUuNTczMDU4WiMwMDAw MDAjMDAwIzAwMDAwMAoKZG46IG91PWdyb3VwLG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20Kb3U6 IFppZWxncnVwcGVuCmRlc2NyaXB0aW9uOiBDb250YWluZXIgZnVlciBaaWVsZ3J1cHBlbmVpbnRy YWVnZQpvYmplY3RDbGFzczogb3JnYW5pemF0aW9uYWxVbml0CnN0cnVjdHVyYWxPYmplY3RDbGFz czogb3JnYW5pemF0aW9uYWxVbml0CmVudHJ5VVVJRDogODQwNTExMTItYjBiYy0xMDMxLTlmMjYt MDU5YmViMGJiNTNjCmVudHJ5Q1NOOiAyMDEyMTAyMjE3NDkwNC45MDg2NjBaIzAwMDAwMCMwMDAj MDAwMDAwCgpkbjogdWlkPTE0LG91PWdyb3VwLG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20KdWlk OiAxNApvYmplY3RDbGFzczogYWNjb3VudApvYmplY3RDbGFzczogdG9wCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogYWNjb3VudAplbnRyeVVVSUQ6IDg0N2VhYzVjLWIwYmMtMTAzMS05ZjM2LTA1OWJl YjBiYjUzYwplbnRyeUNTTjogMjAxMjEwMjIxNzUxMjcuNzIyNzQ3WiMwMDAwMDAjMDAwIzAwMDAw MAoKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYyL3NsYXBk LmNvbmYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwNjQ0ADAwMDA2MDUAMDAwMDAw MQAwMDAwMDAwMjQzNQAxMjA0NDUwNDI2MAAwMDE0MTEyADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzX3NsYXBkAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAG90aGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwMAAwMDAwMDAwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyBTY2hlbWF0 YSBhdXMgZGVyIE9wZW5MREFQLURpc3RyaWJ1dGlvbgppbmNsdWRlCSAgICAgICAgICAgICAgICAg c2xhcGQvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRlCSAgICAgICAgICAg ICAgICAgc2xhcGQvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3NpbmUuc2NoZW1hCgojIExvYWQgbW9k dWxlcwptb2R1bGVwYXRoICAgICAgICAgICAgICAgc2xhcGQvbGliZXhlYy9vcGVubGRhcAptb2R1 bGVsb2FkICAgICAgICAgICAgICAgYmFja19oZGIubGEKbW9kdWxlbG9hZCAgICAgICAgICAgICAg IGNvbnN0cmFpbnQubGEKbW9kdWxlbG9hZCAgICAgICAgICAgICAgIHN5bmNwcm92LmxhCgojIEJh c2Uga29uZmlndXJhdGlvbgpwaWRmaWxlICAgICAgICAgICAgICAgICAgc2xhcGQucGlkCmFyZ3Nm aWxlICAgICAgICAgICAgICAgICBzbGFwZC5hcmdzCgojIERhdGFiYXNlCmRhdGFiYXNlICAgICAg ICAgICAgICAgICBoZGIKCnN1ZmZpeCAgICAgICAgICAgICAgICAgICAib3U9ZGVrYSxkYz1leGFt cGxlLGRjPWNvbSIKZGlyZWN0b3J5ICAgICAgICAgICAgICAgIGV4YW1wbGUKcm9vdGRuICAgICAg ICAgICAgICAgICAgICJjbj1yb290LG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20iCnJvb3RwdyAg ICAgICAgICAgICAgICAgICByb290CgpvdmVybGF5IGNvbnN0cmFpbnQKY29uc3RyYWludF9hdHRy aWJ1dGUgYXNzb2NpYXRlZE5hbWUgdXJpCiAgbGRhcDovLy9vdT1ncm91cCxvdT1kZWthLGRjPWV4 YW1wbGUsZGM9Y29tP2VudHJ5RE4/b25lPyhvYmplY3RDbGFzcz1hY2NvdW50KQogIHJlc3RyaWN0 PWxkYXA6Ly8vb3U9dXNlcixvdT1kZWthLGRjPWV4YW1wbGUsZGM9Y29tPz9vbmUKCgppbmRleCAg ICAgICAgICAgICAgICAgICAgZW50cnlDU04gZXEKaW5kZXggICAgICAgICAgICAgICAgICAgIGVu dHJ5VVVJRCBlcQoKb3ZlcmxheSBzeW5jcHJvdgpzeW5jcHJvdi1jaGVja3BvaW50ICAgICAgMTAw IDUKc3luY3Byb3Ytc2Vzc2lvbmxvZyAgICAgIDEwMApzeW5jcHJvdi1yZWxvYWRoaW50ICAgICAg VFJVRQpzeW5jcmVwbAogICAgcmlkPTAwMQogICAgcHJvdmlkZXI9bGRhcDovL2xvY2FsaG9zdDo0 MDAxCiAgICBjcmVkZW50aWFscz1yb290CiAgICBiaW5kZG49ImNuPXJvb3Qsb3U9ZGVrYSxkYz1l eGFtcGxlLGRjPWNvbSIKICAgIGJpbmRtZXRob2Q9c2ltcGxlCiAgICBzZWFyY2hiYXNlPSJvdT1k ZWthLGRjPWV4YW1wbGUsZGM9Y29tIgogICAgc2NoZW1hY2hlY2tpbmc9b24KICAgIHR5cGU9cmVm cmVzaEFuZFBlcnNpc3QKICAgIHJldHJ5PSIzMCArIgptaXJyb3Jtb2RlIG9uCgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_--

1 0

AW: AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

> 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

1 0

Re: AW: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 01 Nov '12

01 Nov '12

Sascha.Kuehndel(a)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/

1 0

AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

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

1 0

Re: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 01 Nov '12

01 Nov '12

sascha.kuehndel(a)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/

1 0

(ITS#7426) contraints blocks syncreplication
by sascha.kuehndel＠deka.de 01 Nov '12

01 Nov '12

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs