openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#8096) man not up to date
by tim.menage＠gmail.com 01 Apr '15

01 Apr '15

Full_Name: Timothee Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.225.242.54) Hey, If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ so I just don\t understand why when i do man slapd.conf (as you tell to do everywhere), why the first lines are: The file /etc/ldap/slapd.conf contains configuration information for the slapd(8) daemon. Thanks

1 0

(ITS#8095) Patch
by rouzier＠gmail.com 31 Mar '15

31 Mar '15

Full_Name: James Rouzier Version: OS: URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch Submission from: (NULL) (192.222.129.11) I am working on a proof of concept of a simple key value store service using lmdb as the back end. I am using sendfile to avoid an extra copy. I accomplished this by creating function to extract get the mmap ptr from the env so I can calculate the offset of data. I figured that function might be useful to the bigger community. If it does not fit in the bigger vision of lmdb it is fine not to include it. I, James Rouzier, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by quanah＠zimbra.com 30 Mar '15

30 Mar '15

--On Monday, March 30, 2015 12:49 PM +0000 shashikanthbussa(a)gmail.com wrote: > Full_Name: shashikanth.bussa > Version: 2.4 > OS: RHEL5.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.160.252.10) > > > Hi, > > Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i > have not found the openldap2.4 version for RHEl 5.11. The OpenLDAP foundation only releases source. If you want pre-compiled builds, you can look at the builds provided by Symas or the LTB project. As the ITS system is only for reporting bugs, this ITS will be closed. In the future, questions such as this should be directed to the openldap-technical list. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by shashikanthbussa＠gmail.com 30 Mar '15

30 Mar '15

Full_Name: shashikanth.bussa Version: 2.4 OS: RHEL5.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.160.252.10) Hi, Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i have not found the openldap2.4 version for RHEl 5.11. and When i tried to install from source tar ball. i am facing issue with the Barkley DB. hecking for Berkeley DB major version in db.h... 4 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... no configure: error: BerkeleyDB version incompatible with BDB/HDB backends ... Please help on the above

1 0

(ITS#8093) Error string for LDAP_X_CONNECTING is missing
by mikko.auvinen＠vincit.fi 26 Mar '15

26 Mar '15

Full_Name: Mikko Auvinen Version: git master OS: Windows 8.1 URL: ftp://ftp.openldap.org/incoming/mikko-auvinen-150326.patch Submission from: (NULL) (83.102.45.242) ldap_search_ext() returns LDAP_X_CONNECTING when async connect attempt is ongoing. ldap_err2string() is missing an error string for LDAP_X_CONNECTING so it's returning "Unknown API error". Here's a patch that fixes this.

1 0

Re: (ITS#8091) Updateref for openldap 2.4.39 not work
by michael＠stroeder.com 26 Mar '15

26 Mar '15

This is a cryptographically signed message in MIME format. --------------ms090909080601010706070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable betchenhuang(a)163.com wrote: > Updateref for openldap 2.4.39 not work > i configured updateref option in slapd.conf for consumer slapd, later i= restart > slapd Successfully, but when i add new record to consumer, it failed. t= his new > recored not refer to master slapd. > in log ,i found the return code 10 which means: > ldap_add: Referral (10) > referrals: > ldaps://xxx:xxx/uid=3Dmeixuan,ou=3DPeoples,dc=3Dhadoop,dc=3Dcom It seems you did not load slapo-chain in your configuration which impleme= nts=20 the consumer-side referral chasing. Therefore the consumer sends the refe= rral=20 back to your LDAP client. Read about chaining here: http://www.openldap.org/doc/admin24/overlays.html#Chaining See another config example here: http://www.openldap.org/faq/data/cache/1434.html The ITS is only used for bug reports. Please post configuration questions to the openldap-technical mailing lis= t. Ciao, Michael. --------------ms090909080601010706070208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjA3MDMwNFowLwYJKoZIhvcNAQkEMSIE INUwr+VrzD6DxfJr7U+Sku8f+I6JqX5ty0KBRXsQe1eUMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQA77XDFu6SAsZn0FmyMD2rRN73NV6nvP7h6O9ppe+H2J0S4+hGmTotu VPLZ7Sc9V1Ybv1xqFXjhwjzuVkKFHn7h+iN+OF4ejzdOVuHI/YIZNepZiBMS0cQKuEachzBQ S42su/6Cs22EzIUB0QrvD0hSI4Ijwwa8bmUh24DP08hnlbZGf7pJoYUjdZv7vNPWpm15TMTD ZJKHJHyqA+0gYW4HKYRsncLL9x0ZN60EMI95J6n4S3NeQt5ccibsL+nhzVch20fZufWTufO9 CpNtlYUXs+6C/IJ3kkgLSnnzCHNmT9lOiE7/S3svyBhM/Lq6ATtG716LKJjcQ/LvQNF60oCB AAAAAAAA --------------ms090909080601010706070208--

1 0

(ITS#8092) slapd crash with sasl auxprop and empty suffix
by ryan＠nardis.ca 26 Mar '15

26 Mar '15

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Based on a Debian bug report: https://bugs.debian.org/781162 ./configure --enable-spasswd cat > slapd.conf << EOF include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema database mdb directory . suffix "" EOF slapadd -f slapd.conf << EOF dn: dc=com objectClass: domain dn: dc=example,dc=com objectClass: domain dn: uid=test,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject userPassword: {SASL}test(a)EXAMPLE.COM EOF ldapwhoami -x -D uid=test,dc=example,dc=com Enter LDAP Password: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeebab700 (LWP 28815)] __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. (gdb) bt #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at backend.c:704 #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, sparams=0x7fffe0001cd0, flags=0, user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, flags=flags@entry=0, user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) at ../../lib/canonusr.c:220 #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", ulen=ulen@entry=0, flags=flags@entry=3, oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized out>) at ../../lib/checkpw.c:159 #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, user=0x7fffe0001460 "test(a)EXAMPLE.COM", userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", passlen=passlen@entry=4) at ../../lib/server.c:1922 #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized out>, userlen=16, pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, cred=0x7fffe0002700, text=0x7fffeebaaae0) at sasl.c:990 #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) at passwd.c:327 #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, e=0x7fffe0002f28, a=0x7fffe0002fa8, cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:120 #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:383 #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:205 #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, arg_v=0x7fffe00026b0) at connection.c:1134 #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) at connection.c:1280 #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at tpool.c:958 #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at pthread_create.c:309 #19 0x00007ffff71aa04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I don't know how auxprop is intended to be configured; I'm going to follow up on that when I have time. This is just about a segv that happens when pwcheck_method is auxprop (the default) and the suffix is the empty string.

1 0

(ITS#8091) Updateref for openldap 2.4.39 not work
by betchenhuang＠163.com 26 Mar '15

26 Mar '15

Full_Name: marix wong Version: 2.4.39 OS: redhat 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (119.145.14.210) Updateref for openldap 2.4.39 not work i configured updateref option in slapd.conf for consumer slapd, later i restart slapd Successfully, but when i add new record to consumer, it failed. this new recored not refer to master slapd. in log ,i found the return code 10 which means: ldap_add: Referral (10) referrals: ldaps://xxx:xxx/uid=meixuan,ou=Peoples,dc=hadoop,dc=com this is my configuration: syncrepl rid=124 provider=ldaps://167.52.0.35:21780 type=refreshAndPersist%0 interval=00:00:00:15 searchbase="dc=hadoop,dc=com" filter="(objectClass=*)" scope=sub attrs="*,+" tls_reqcert=allow tls_cacert=/opt/cert/cacert.pem schemachecking=off bindmethod=simple binddn="cn=root,dc=hadoop,dc=com" credentials=Ldap@123 retry="15 +" updateref ldaps://167.52.0.35:21780 so i want to know how to make this option work better?

1 0

(ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by olli.salli＠vincit.fi 25 Mar '15

25 Mar '15

Full_Name: Olli Salli Version: git master OS: Windows 8.1, Linux 3.18.10 URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch Submission from: (NULL) (83.102.45.242) We are working on an application which needs to perform some simple LDAP search queries every once in a while. The application is running as a daemon in an embedded server environment and has no user interface, and is instead remotely controlled and configured via a control TCP connection. This includes the configuration specifying the LDAP server address and port, and whether the LDAP queries should be attempted at all (if there is no server available). We are currently developing on Windows 8.1 with Visual Studio 2013 but will also run in Linux environments. To ensure the control TCP connection stays alive at all times (and the daemon otherwise functional), and to avoid using threads, whahave used the openldap asynchronous APIs, including the asynchronous connect option - if the configured LDAP server is unreachable, the initial search query can block for a very long time otherwise. It is here that we have hit a small issue. When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the initial request (e.g. using ldap_search_ext) does not block, which is correct. However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and continue reissuing the ldap_search_ext request periodically, following calls correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed, LDAP_CONNECT_ERROR is returned again, which is correct. LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from legitimate error conditions in connect() even in asynchronous mode, for example out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces being down (ENETUNREACH), etc. These should be handled as fatal errors, but would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR resulting from using LDAP_OPT_CONNECT_ASYNC. The issue seems to be in ldap_send_initial_request (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/…). When async connect is enabled what happens during the first request is: 1) sd is initialized to AC_SOCKET_INVALID 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether there is already a connection, and to fetch its socket descriptor to sd 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID 4) a new connection is formed using ldap_open_defconn() 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still AC_SOCKET_INVALID, and thus the poll fails 6) LDAP_CONNECT_ERROR is returned On successive calls, what happens is 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid socket descriptor 2) opening a new connection is skipped 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket descriptor 4) the poll works as intended A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) after opening the connection. This fixes the first poll to return LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A perhaps more semantically correct alternative could be to return the created socket descriptor from ldap_open_defconn().

1 0

(ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by pk＠dbic.pro 24 Mar '15

24 Mar '15

Full_Name: Pavel Kraynyukhov Version: only LMDB from git and lmdb-0.9.14 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.99.47.171) Hello there, I have ran into an issue with LMDB, which I can reproduce at will, but it seems a specific one. The git commit is 3368d1f5e243225cba4d730fba19ff600798ebe3 And this commit and my issue seems to be related. 1. I use MDB_NOTLS flag on environment open. 2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is stuck after several transactions (writer thread backtrace): #0 0x00007fe5534a25dc in __lll_robust_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fe553498ba1 in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #2 0x00007fe553ed895a in mdb_txn_renew0 (txn=txn@entry=0x661810) at mdb.c:2638 #3 0x00007fe553ed9558 in mdb_txn_begin (env=0x6606c0, parent=0x0, flags=<optimized out>, ret=0x7fe552bebd08) at mdb.c:2813 #4 0x000000000041cd0c in beginWOTxn (parent=0x0, this=0x6603a8) at ../ITCFramework/include/LMDBEnv.h:220 #5 itc::lmdb::WOTxn::WOTxn (this=0x7fe552bebdb0, ref=...) at ../ITCFramework/include/LMDBWOTxn.h:51 #6 0x0000000000420c5b in itc::lmdb::DBWriter::dbWrite (this=this@entry=0x661b08) at ../ITCFramework/include/LMDBWriter.h:185 #7 0x00000000004210ff in itc::lmdb::DBWriter::execute (this=0x661b08) at ../ITCFramework/include/LMDBWriter.h:98 #8 0x0000000000414eac in itc::sys::CancelableThread<itc::lmdb::DBWriter>::run (this=0x7ffff31f7cd0) at ../ITCLib/include/sys/CancelableThread.h:84 #9 0x0000000000439dc4 in itc::sys::invoke (context=0x7ffff31f7cd0) at src/Thread.cpp:56 #10 0x00007fe55349b4c6 in start_thread () from /lib64/libpthread.so.0 #11 0x00007fe5531e000d in clone () from /lib64/libc.so.6 Before you might ask: 1. There is only one writer thread. Only this thread begins writable transactions and only this thread commits them and of course only this thread calls mdb_put(). 2. There suppose to be a multiple reader threads. For the test I'm running one only. And there are no read operations or cursor usage during this test at the same time when the writer is working. 3. When I write hang, I mean only the application not the system. The test application consume no CPU after it hang. 4. If no MDB_NOSYNC flag is used, then there is no bug/deadlock. This however may be due to very slow file system operations of my PC. It is about 35 writable transactions per second and about 27-39% I/O wait on the CPU. P.S. tested against system provided lmdb version 0.9.14 and result is the same. So this maybe not related to latest commit in git.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs