openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

(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 25 Mar '15

25 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 25 Mar '15

25 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

(ITS#8088) slapd man pages get installed when --disable-slapd is specified
by quanah＠openldap.org 24 Mar '15

24 Mar '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.64.214) When only building out the client libraries (--disable-slapd), make install goes ahead and installs the man pages related to slapd, which should be skipped in this case.

1 0

(ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by francisco＠garnelo.eu 24 Mar '15

24 Mar '15

Full_Name: Francisco Garnelo Version: slapd 2.4.40 OS: FreeBSD 10.1-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.21) Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin to enumerate the items in differents branches, the server crashes; this not takes more than 30 seconds from last restart. I experimented a similar issue with SLES 12(if not it is the same) and openldap 2.4.40 (from suse repositories) version, but in this system I could not take evidences. The database has more than 3GB of size and MDB is configured to support 100GB as the maximum size. The same databa w works fine ining BDB using an old openldap version. ############# # Versions: # ############# root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $ root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd Included static overlays: dynlist seqmod syncprov Included static backends: config ldif relay root@xxxx:/usr/local/etc/openldap # uname -a FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 ###################### # cn=config export: # ###################### version: 1 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConfigDir: slapd.d olcConfigFile: slapd.conf olcIdleTimeout: 0 olcIndexIntLen: 8 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: 0 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSizeLimit: unlimited olcThreads: 20 olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key olcTLSCRLCheck: none olcTLSProtocolMin: 0.0 olcTLSVerifyClient: never olcToolThreads: 2 olcWriteTimeout: 0 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_mdb database config olcModulePath: /usr/local/libexec/openldap dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ### -- omitted content -- ### 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 /r%r/local/etc/openldap/schema/rfc2307bis.schema ### -- omitted content -- ### dn: olcDatabase={-1}frontend,cn=config objectClass: olcFrontendConfig objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base%%2"cn=subsemema" by * read olcAccess: {2}to attrs=shadowLastChange by self write by * read olcAccess: {3}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSizeLimit: unlimited olcSyncUseSubentry: FALSE dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: FALSE olcReadOnly: FALSE olcRootDN: cn=config olcRootPW: XXXXX olcSyncUseSubentry: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}mdb olcDbDirectory:2F2Fvar/db/openldap-data.mdb olcDbIndex: objectClass eq olcRootDN: cn=lalala,dc=yyyyyyy,dc=com olcRootPW: XXXXXXX olcSuffix: dc=yyyyyyy,dc=com ######## # GDB: # ######## 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 => mdb_entry_decode: 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <=dbdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_dn2id: got id=0x931e 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b7 daemon: activity on 1 descriptor 551194b8 daemon: activity on:519194b8 11r551194b8 551194b8 daemon: read activity on 11 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b7 => mdb_entry_decode: 551194b7 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL 551194b8 <= mdb_dn2id: got id=0xf 551194b6 <= mdb_entry_decode 551194b8 => mdb_entry_dece:3A 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x25 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode [New Thread 2103c12400 (LWP 100750/slapd)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2103c12400 (LWP 100750/slapd)] 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91 91 val = IDL_CMP( id, ids[cursor] ); Current language: auto; currently minimal -------------- Thanks, Francisco Garnelo

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 23 Mar '15

23 Mar '15

This one just bit us again. I know that the client should probably not be using pr at all, but the client is an Google supplied intergration application that we have little control over. Is this a problem that is going to be addressed as some point or will it be treated as a known limitation? Bill -- "We have meet the enemy and he is us." Pogo

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 22 Mar '15

22 Mar '15

Nikos Voutsinas wrote: > I am in the process of doing so. Do you have in mind a specific > commit/fix in REL_EN that might have solved this; That would help me > reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG). Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec > > For start I will try to upgrade to REL_ENG the same system from which I > got the debug log, to see if that would help recover (although I have no > great hopes). > > On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> wrote: > > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: > ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion… > <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2…> > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal operation, > may reach into a > situation where you can almost predictably crash it, with a > simple modify > operation. > > > Please test RE24 and see if you can still reproduce this issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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

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