openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#7208) Replica coredumps in syncrepl mode
by michael＠stroeder.com 14 Mar '12

14 Mar '12

This is a cryptographically signed message in MIME format. --------------ms080104040202090104060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Typo on my part > > It is 2.4.24 Anyway you should try to reproduce this with 2.4.30 since there have been= =20 numerous fixes to syncrepl since 2.4.24: http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f=3DCH= ANGES;h=3D1c68a45c430b4d3ebaea83294c05c242a3ba91bf;hb=3Drefs/heads/OPENLD= AP_REL_ENG_2_4 Ciao, Michael. > -----Original Message----- > From: Michael Str=F6der [mailto:michael@stroeder.com] > Sent: March-14-12 9:41 AM > To: Cardinal, Andre (520972) > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#7208) Replica coredumps in syncrepl mode > > andre.cardinal(a)bell.ca wrote: >> Full_Name: Andre Cardinal >> Version: 2.2.24 > > Are you really using 2.2.24? This is an ancient version. 2.2.x has been= set to > historic years ago. > > Could you please try to reproduce this with currently recent release 2.= 4.30? > > Ciao, Michael. --------------ms080104040202090104060807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDE0MDQzMVowIwYJKoZIhvcNAQkEMRYE FJkgOqb2gdGaFMxe/XPrSXGdLw6HMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAAaOKi3q8/1dU7oRpxVYTBXb8WNOy0GFbA7awAAfhetQq68cq/+HwY5H+grPXuMZdOgce WJ09MEeAHlz4aExR2qOsClu5EBpHQoTOu20U8ByFpUU1xS6x5ZB7wv4JN8GpHe7sV/nTSDcJ bpA0kjurXc6UkwfLionQKJkdz//PTzkdCw+wGsz4UiRRayEbcq4BRi5KTp1IewrQwcid/qaN hfNATAhn1dbFfBv4mvyIYyEnSNG85XYwRdAyVSl8hVsfgWmSH6K/goGxeEMlnWPNxBk7F9ui AXpsiljAnNn4vl/uny5SFPKJkkn4mtDO7jK8RZKvxU+Pb2DBkjmBIaM/dgAAAAAAAA== --------------ms080104040202090104060807--

1 0

RE: (ITS#7208) Replica coredumps in syncrepl mode
by andre.cardinal＠bell.ca 14 Mar '12

14 Mar '12

Typo on my part It is 2.4.24 -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: March-14-12 9:41 AM To: Cardinal, Andre (520972) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7208) Replica coredumps in syncrepl mode andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.2.24 Are you really using 2.2.24? This is an ancient version. 2.2.x has been set to historic years ago. Could you please try to reproduce this with currently recent release 2.4.30? Ciao, Michael.

1 0

Re: (ITS#7208) Replica coredumps in syncrepl mode
by michael＠stroeder.com 14 Mar '12

14 Mar '12

This is a cryptographically signed message in MIME format. --------------ms050408060208030303010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.2.24 Are you really using 2.2.24? This is an ancient version. 2.2.x has been s= et to=20 historic years ago. Could you please try to reproduce this with currently recent release 2.4.= 30? Ciao, Michael. --------------ms050408060208030303010805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDEzNDA0NFowIwYJKoZIhvcNAQkEMRYE FPblbthmkMffgP3cgCbuBPtlezT2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAklodZ8Q0BtBXDb6m8/1q/UI1uoBf+3YPCUPFCgJteK48aBPZDpd6PQuhapmF9z+CuTJk JXV1J6uro8pBxQddbe6u8nPM2N9uwR9PVw58CKM3je2K7b2h10umwmiWZKiN/fG26nGFBM7B HKRoQw/oZ1lbsXH4kF22dMt9KRDL+vfNs5VfnNFuB9K7fxKySxB98gWbsPFx5giPOLLLqdKd SKjSK2+myZw8gTvKVfgI3fMOelvXvMtvTlkKMOY+12dECeFrbe51g5N1h0+rP08XnbrkMJsT H4Uz3DfJIt9tJkAXAiZ+l9sXzsxv2unUpGehzogR7Ss/DBKKWW+/Gb2hcQAAAAAAAA== --------------ms050408060208030303010805--

1 0

(ITS#7208) Replica coredumps in syncrepl mode
by andre.cardinal＠bell.ca 14 Mar '12

14 Mar '12

Full_Name: Andre Cardinal Version: 2.2.24 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.247) Replica core dumps if unable to contact it's Master after 2 hours. Replica is set to refresh and persist. To reproduce... Shut down slapd on Master server and/or, if multihomed server, shutdown the replication interface. After 2 hours (the os keep_alive_interval) the log will report: Feb 28 12:30:15 dpdsrass1 slapd[25552]: [ID 539778 local4.debug] do_syncrep2: rid=123 (-1) Can't contact LDAP server Feb 28 12:30:15 dpdsrass1 slapd[25552]: [ID 664938 local4.debug] do_syncrepl: rid=123 rc -1 retrying And ldap will coredump shortly there after. The log entry mentionned above do appear in the log (every 2 hours) if there is no traffic from the Master to the Slave and the Master can be contacted, so no coredump.

1 0

(ITS#7207) Re-binding to a failed connection segfaults
by jsynacek＠redhat.com 14 Mar '12

14 Mar '12

Full_Name: Jan Synacek Version: 2.4.30 OS: Fedora 16 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) I've created a small reproducer, that calls ldap_sasl_interactive_bind_s after it has been called once and failed, which causes a segfault. I've traced this bug with gdb: $ gdb ./reproducer GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/jsynacek/work/bz784989-openldap-rebinding/reproducer...done. (gdb) r Starting program: /home/jsynacek/work/bz784989-openldap-rebinding/reproducer [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ldap_sasl_interactive_bind: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 7 ldap_prepare_socket: 7 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 7 tm: -1 async: 0 TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory TLS: error: connect - force handshake failure: errno 21 - moznss error -5938 TLS: can't connect: TLS error -5938:Encountered end of file. ldap_msgfree ldap_err2string bind failed: Can't contact LDAP server, retrying for fun and profit! ldap_sasl_interactive_bind: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI Program received signal SIGSEGV, Segmentation fault. ldap_int_sasl_bind (ld=0x603130, dn=0x0, mechs=0x401a30 "GSSAPI", sctrls=0x0, cctrls=0x0, flags=1, interact=0x401660 <lutil_sasl_interact>, defaults=0x60cae0, result=0x0, rmech=0x7fffffffd878, msgid=0x7fffffffd88c) at ../../../libraries/libldap/cyrus.c:444 444 oldctx = ld->ld_defconn->lconn_sasl_authctx; (gdb) p ld->ldc->ldc_defconn $1 = (LDAPConn *) 0x0 If you set slapd to use TLS certs (uncomment the 'TLS*' lines in the config), there is no segfault. The reproducer and the config can be found here: URL1: http://jsynacek.fedorapeople.org/openldap/rebind-segfault/reproducer.c URL2: http://jsynacek.fedorapeople.org/openldap/rebind-segfault/cn=config.ldif

1 0

Re: (ITS#7206) ldaprc: TLS_REQCERT demand does not terminate session, if a bad certicate comes from the server
by hyc＠symas.com 14 Mar '12

14 Mar '12

mkeller(a)psi.de wrote: > Full_Name: Michael Keller > Version: 2.4.20 > OS: SLES 11 SP1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.131.98.154) > > > I have configured slapd to accept only TLS connections with: > > security ssf=1 update_ssf=112 simple_bind=64 > > A ldapsearch -x returns correctly a > "# search result > search: 2 > result: 13 Confidentiality required > text: confidentiality required" > > When using TLS_REQCERT=demand a > ldapsearch -x -Z still returns results, even if a bad certificate comes from the > server. See debug output below. > ldapsearch -x -Z Works as designed. Read the description for the -Z flag again. 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

(ITS#7206) ldaprc: TLS_REQCERT demand does not terminate session, if a bad certicate comes from the server
by mkeller＠psi.de 14 Mar '12

14 Mar '12

Full_Name: Michael Keller Version: 2.4.20 OS: SLES 11 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.131.98.154) I have configured slapd to accept only TLS connections with: security ssf=1 update_ssf=112 simple_bind=64 A ldapsearch -x returns correctly a "# search result search: 2 result: 13 Confidentiality required text: confidentiality required" When using TLS_REQCERT=demand a ldapsearch -x -Z still returns results, even if a bad certificate comes from the server. See debug output below. ldapsearch -x -Z ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate # extended LDIF # # LDAPv3 # base <dc=ee,dc=psi> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # ee.psi dn: dc=ee,dc=psi objectClass: dcObject objectClass: organization dc: ee o: PSI-EE # People, ee.psi dn: ou=People,dc=ee,dc=psi ou: People objectClass: top objectClass: organizationalUnit # Group, ee.psi dn: ou=Group,dc=ee,dc=psi ou: Group objectClass: top objectClass: organizationalUnit # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 Only when using "-ZZ" the connection isn't established. But the man page stated, that the connection is terminated immediatly if a bad certificate is supplied ("ldap_start_tls returns with an error). I think with "TLS_REQCERT demand" and a bad certificate the connection should be terminated even if just a "-Z" is used. At the moment the behaviour is the same for TLS_REQCERT = allow|try|demand Debug output: ldap_msgfree TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 2, err: 0, subject: /DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi, issuer: /DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi TLS certificate verification: depth: 1, err: 0, subject: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=EE-SigningCA@ldap-srv11, issuer: /DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi TLS certificate verification: depth: 0, err: 0, subject: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=ldap-srv11.ee.psi, issuer: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=EE-SigningCA@ldap-srv11 TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A TLS: hostname (ldap-srv11) does not match common name in certificate (ldap-srv11.ee.psi). ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 14 bytes to sd 3 ldap_result ld 0x615150 msgid 2 wait4msg ld 0x615150 msgid 2 (infinite timeout) wait4msg continue ld 0x615150 msgid 2 all 1 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid 2 all 1 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x615150 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x615150 0 new referrals read1msg: mark request completed, ld 0x615150 msgid 2 request done: ld 0x615150 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 51 bytes to sd 3 ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 89 contents: read1msg: ld 0x615150 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 89 contents: read1msg: ld 0x615150 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 87 contents: read1msg: ld 0x615150 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x615150 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x615150 0 new referrals read1msg: mark request completed, ld 0x615150 msgid 3 request done: ld 0x615150 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed

1 0

(ITS#7205) olcSuffix does not support modifications
by elecharny＠apache.org 13 Mar '12

13 Mar '12

Full_Name: Emmanuel Lecharny Version: 2.4.24 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.4.211) The olcSuffix AT, which is not declared as SINGLE-VALUED, does not support more than one value. Per se, the definition of this AT should be explicit about it. However, this is not the main issue. Trying to modify its value using such a LDIF file : dn: olcDatabase={3}ldif,cn=config changetype: modify delete: olcSuffix olcSuffix: cn=test2 - add: olcSuffix olcSuffix: cn=test3 - leads to an error : #!ERROR [LDAP: error code 80 - <olcSuffix> Only one suffix is allowed on this ldif backend] It seems that there is an internal check that is done to insure that the olcSuffix does not contain more than one value, bypassing the AT definition, and that this check is not correctly done when a modify operation is sent. Deleting the olcSuffix AT and injcting a new one works.

1 0

(ITS#7204) test044-dynlist broken with --disable-monitor
by h.b.furuseth＠usit.uio.no 09 Mar '12

09 Mar '12

Full_Name: Hallvard B Furuseth Version: 2.4->2.4.30 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard test044-dynlist uses olcDatabase={2}$BACKEND,cn=config. This breaks when back-monitor is omitted as database {1}. Fixing.

1 0

(ITS#7203) approxIndexer should not return zero-length keys
by hyc＠OpenLDAP.org 09 Mar '12

09 Mar '12

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc The approxIndexer generates a key for every word in the input string. Short words produce no actual key value, and leave a slot in the list of keys with bv_len=0. These results should be omitted; the underlying database can't do anything with zero length keys anyway.

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