openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by dirk.kastens＠uni-osnabrueck.de 12 Jan '15

12 Jan '15

This is a cryptographically signed message in MIME format. --------------ms020609010007010102020405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, > Then you should have simply followed up to #7983. The case has been closed. > Does ldapsearch work against the target servers using the certificate > configurations you listed? Yes. I can directly query the target servers from the redhat server=20 using ldapsearch and ssl. --------------ms020609010007010102020405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJDCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFcDCCBFigAwIBAgIHF6QkfFey qDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MB4XDTE0MDUyNzE0NTMzM1oXDTE5MDcwOTIzNTkwMFowgZExCzAJBgNVBAYTAkRFMSAwHgYD VQQKExdVbml2ZXJzaXRhZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEj MCEGA1UEAxMaVW5pLU9zbmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNh QHVuaS1vc25hYnJ1ZWNrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApLZx V6i214uWBb3c16AMckkujPKMXxl9Z4XsEIhrA47tG5YL9upeUrj+duDcrbEQvphvSXJFveVk LK1JMANHJuu/Wa32Bc8IRljYBqhaKMTGRO1q5L6jkMBDwBwenozhlGAaqG+8Cy+qcFoUaoWB RCH2++t5FtXyS1/1GKhWu7yQxCblFul7VXvnLKyaNlOaTalREXb9pQk2N31+rrOgwkbogxc2 z30gQAJXeJ2Ra0SlReqINMmcDd4lfluXjBpFmiJa4xHhQIVJpW2vF8dbqmeKqxIoYziBh78N GaqMSC8IbDPbCM3qaDaGUWKccgb/SKZvrNTLU+jcW66yGi1YPwIDAQABo4ICATCCAf0wEgYD VR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwEQYDVR0gBAowCDAGBgRVHSAAMB0G A1UdDgQWBBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp 9/EKcD7eZDAfBgNVHREEGDAWgRRjYUB1bmktb3NuYWJydWVjay5kZTCBiAYDVR0fBIGAMH4w PaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9j YWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRw Oi8vb2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEApVPS1rUMH9oWu02nJHDV C7jF74wUYbzFaX1ULtkEGXK0MV2HyR8kZ3t19qcmEzgo/eaYv5+OE/nMnNHWUH/ybTN3bQFF K4+L+42SwRkSnyXVQsb38NsUknpDAlUeR9+jv5rkhIF5u+sRIXSB1lzoohtVUkYsC50UO1L4 bWchK7DE++22NDiTgtoFWwC1nn2wt8FYTB4IIbCOogEI6fFXIHZkG6BlLiYmPFmbNfPwNJpv 25g87P0SXpQR1uxSv4giL6o6XWCDJpnCEA4+029ZYLZG0e1bSzk4wI+ho08oxNs8B7NPlH2p jOpq40pZwvVw5rp2nu3W5CaDxgHdxXBX5DCCBYcwggRvoAMCAQICBxWm3SXtmbEwDQYJKoZI hvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgT3NuYWJy dWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9zbmFicnVlY2sg UlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNrLmRlMB4XDTEz MDUwNjA3NDUyNVoXDTE2MDUwNTA3NDUyNVowXjELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1Vu aXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVtMRUwEwYDVQQD EwxEaXJrIEthc3RlbnMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZObhf0kwV d2daq89+nHsASWUXo8iLb+T9y2N5cmwkVMwAjgtTqjJu+P8jQOxxKaK35pWS5CB1HGiNqLms NOdMVqf1PXdnDANE//wGsMTKwKVjhYlj7PoPSuwAZ4NT8eTf/UR3ViPA64r9qCB8pYBO3L1w n6oMiXdWD8Vd7OVEVzGeMoVYstRyv+wzUAPJotGCd5smxEq+LMTv1HQ6xtZW2le5bMub4uk4 UdACPgCDBGP07sQvM8krM5fNOIbzNRyqD7eERnSMGkounpRkHSwoWUkt1njYUrxk1q4qMDBz xEIx4MPGPw57HN0VQ9z/3eUBjmZi+oqlxkDlHwzcvsH3AgMBAAGjggIUMIICEDAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAgEEAwAwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ4 FSGPMJNnhKKMKGStCzA58jMkmjAfBgNVHSMEGDAWgBSqH9h3FW6Z5F+Q1uxjJk4Z6mcUUDAp BgNVHREEIjAggR5kaXJrLmthc3RlbnNAdW5pLW9zbmFicnVlY2suZGUwgY8GA1UdHwSBhzCB hDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmktb3NuYWJydWVjay1jYS9wdWIv Y3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmktb3NuYWJy dWVjay1jYS9wdWIvY3JsL2NhY3JsLmNybDCBqAYIKwYBBQUHAQEEgZswgZgwSgYIKwYBBQUH MAKGPmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLW9zbmFicnVlY2stY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEoGCCsGAQUFBzAChj5odHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1v c25hYnJ1ZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA pJjFnuZVVSPNqukqAI+ZWWClujzCsBdN1Zq95kik17FqjsB8TSqelmmohw1qBQXq3EnDFmWy R6FuNqYOPjborAEkhwRPmUXDDLvCU02TvwtxFuNJZc0ALz41oR8s8l5PBYoNlpPsYz+tsbKX +15XnsH1ftR/wzqaWPMLfWhG0OnLObeEMb+y5EQPO5kKzf+EdM/JmITWnip03FAtcr9JWq3N p6APfIDoWJ4uM5CyOvnEox41V+2a6PuOKY/bPE9seCOBbduWb15pXYZB7EHWM5Hkp5bLsl7s YtnFH++SCDLyutyLq4LCw1ryt7rLzkUEQ/YZOAqkfifDY6OdW3cRqzGCA/gwggP0AgEBMIGd MIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAU BgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEct MDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZQIHFabdJe2ZsTAJBgUr DgMCGgUAoIICLzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x NTAxMTIxNTMyNDVaMCMGCSqGSIb3DQEJBDEWBBS6OOuWq562k3pz6MZsbg4R/6KqLjBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGu BgkrBgEEAYI3EAQxgaAwgZ0wgZExCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRh ZXQgT3NuYWJydWVjazEWMBQGA1UECxMNUmVjaGVuemVudHJ1bTEjMCEGA1UEAxMaVW5pLU9z bmFicnVlY2sgUlotQ0EgRy0wMDIxIzAhBgkqhkiG9w0BCQEWFGNhQHVuaS1vc25hYnJ1ZWNr LmRlAgcVpt0l7ZmxMIGwBgsqhkiG9w0BCRACCzGBoKCBnTCBkTELMAkGA1UEBhMCREUxIDAe BgNVBAoTF1VuaXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVt MSMwIQYDVQQDExpVbmktT3NuYWJydWVjayBSWi1DQSBHLTAwMjEjMCEGCSqGSIb3DQEJARYU Y2FAdW5pLW9zbmFicnVlY2suZGUCBxWm3SXtmbEwDQYJKoZIhvcNAQEBBQAEggEABJqxTgyv 1x/zocqOjXizXSpa0Lpa++ONFhItrhQUGdAIYaw600kwwl686ds4CLDRBOqlmqrQg4YOb8QR eSqVyK4OR6VZ65MBJ5mHVDKepgUBoZM7gh9LX4DUW4xVdvvsjBvUhhtq/JXC/2VfBBoNhSMH 8fJgisL5+k7YRgG3sgCJm0mQq2er9qRWHSlNssbUUb5SGbfvOTFvcVxDCBbEL1JYgT0dPd4U V/1WppJBkex2+7Wf2EA3kBDdFTmq5yg4C1mYgLb0647A1wVYzxufidcRCFiYjcroEVXu3pdC N+JJII0RN0nVqsZiOzU3K271xH136pFF5UkUKsvdCtNapAAAAAAAAA== --------------ms020609010007010102020405--

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by hyc＠symas.com 12 Jan '15

12 Jan '15

dirk.kastens(a)uni-osnabrueck.de wrote: > Full_Name: Dirk Kastens > Version: 2.4.40 > OS: RedHat SL 7.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:638:508:3d0:579:e63b:2c0e:3a09) > > > This is a duplicate of #7983 Then you should have simply followed up to #7983. Does ldapsearch work against the target servers using the certificate configurations you listed? Without a reproducible test case you'll get the same response as #7983 - no evidence of an OpenLDAP software bug, take this to the -technical list for help fixing your configuration. Or take this to RedHat support for help using their build of TLS software. > I'm running an openldap server with a meta backend that combines the > trees of three different ldap servers. Two of them are connected via > starttls and one via ssl over port 636. This perfectly works with > openldap-2.4.23. > Now I have upgraded the server to RedHat SL 7.0 with openldap-2.4.39. > The ssl server cannot be reached by the meta backend any more. I > manually compiled openldap 2.4.40, but the effect is the same. I tried > openssl and moznss, but this makes no difference. I only see the trees > of the tls connected servers. > The tls servers also speak ssl, so I simply changed the uri from "ldap:" > to "ldaps:". The effect is, that the servers also became unreachable. > > Here is my configuration: > ------------------------------- > database meta > suffix "ou=new,dc=xyz,dc=de" > > uri "ldap://ldap.xyz.de/ou=a,ou=new,dc=xyz,dc=de" > suffixmassage "ou=a,ou=new,dc=xyz,dc=de" "ou=people,dc=xyz,dc=de" > idassert-bind bindmethod=simple binddn="cn=proxy,dc=xyz,dc=de" > credentials="secret" mode=self > tls_cert=/etc/openldap/certs/client.pem > tls_key=/etc/openldap/certs/client.key > tls_cacert=/etc/openldap/cacerts/cacerts.pem > tls_cacertdir=/etc/openldap/cacerts > tls_rcecert=never > idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" > > uri "ldaps://ldap.abc.de:636/ou=b,ou=new,dc=xyz,dc=de" > suffixmassage "ou=b,ou=new,dc=xyz,dc=de" "ou=people,dc=abc,dc=de" > idassert-bind bindmethod=simple binddn="cn=proxy,dc=abc,dc=de" > credentials="secret" mode=self starttls=no > tls_cert=/etc/openldap/certs/client.pem > tls_key=/etc/openldap/certs/client.key > tls_cacert=/etc/openldap/cacerts/cacerts.pem > tls_cacertdir=/etc/openldap/cacerts > tls_reqcert=never > idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" > ------------------------------- > > When I search the meta directory, I only see the ou=a branch. > slapd logs the following: > > conn=1000 op=1 SRCH base="ou=new,dc=xyz,dc=de" scop3D3D1 deref=3 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=objectclass > conn=1000 op=1: meta_back_getconn[0] > conn=1000 op=1: meta_back_getconn[1] > conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN-TLS inserted > conn=1000 op=1 >E%E> meta_back_search_start[0] > conn=1000 op=1 >>> meta_search_dobind_init[0] > conn=1000 op=1 <<< meta_search_dobind_init[0]=2 > conn=1000 op=1 <<< meta_back_search_start[0]=2 > conn=1000 op=1 >>> meta_back_search_start[1] > conn=1000 op=1 >>> meta_search_dobind_init[1] > conn=1000 op=1 <<< meta_search_dobind_init[1]=4 > conn=1000 op=1 <<< meta_back_search_start[1]=4 > conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" > conn=1000 op=1 >>> meta_back_search_start[0] > conn=1000 op=1 >>> meta_search_dobind_init[5D5D > conn=1000 op=1 <<< meta_search_dobind_init[0]=1 > ... > conn=1000 op=1 <<< meta_back_search_start[0]=1 > conn=1000 op=1 >>> meta_search_dobind_init[1] > conn=1000 op=1 <<< meta_search_dobind_init[1]=0 > ------------------------------- > > It seems to find both servers, but it only connects to the first one. > With ldapsearch I only see the branch "ou=a,ou=new,dc=xyz,dc=de". > slapd hangs and can only be terminated by "kill -4". When the first server is > specified with ldaps, none of the servers are reachable. > > > -- -- 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#8022) Backend Meta does not work with ssl-backends
by dirk.kastens＠uni-osnabrueck.de 12 Jan '15

12 Jan '15

Full_Name: Dirk Kastens Version: 2.4.40 OS: RedHat SL 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:508:3d0:579:e63b:2c0e:3a09) This is a duplicate of #7983 I'm running an openldap server with a meta backend that combines the trees of three different ldap servers. Two of them are connected via starttls and one via ssl over port 636. This perfectly works with openldap-2.4.23. Now I have upgraded the server to RedHat SL 7.0 with openldap-2.4.39. The ssl server cannot be reached by the meta backend any more. I manually compiled openldap 2.4.40, but the effect is the same. I tried openssl and moznss, but this makes no difference. I only see the trees of the tls connected servers. The tls servers also speak ssl, so I simply changed the uri from "ldap:" to "ldaps:". The effect is, that the servers also became unreachable. Here is my configuration: ------------------------------- database meta suffix "ou=new,dc=xyz,dc=de" uri "ldap://ldap.xyz.de/ou=a,ou=new,dc=xyz,dc=de" suffixmassage "ou=a,ou=new,dc=xyz,dc=de" "ou=people,dc=xyz,dc=de" idassert-bind bindmethod=simple binddn="cn=proxy,dc=xyz,dc=de" credentials="secret" mode=self tls_cert=/etc/openldap/certs/client.pem tls_key=/etc/openldap/certs/client.key tls_cacert=/etc/openldap/cacerts/cacerts.pem tls_cacertdir=/etc/openldap/cacerts tls_rcecert=never idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" uri "ldaps://ldap.abc.de:636/ou=b,ou=new,dc=xyz,dc=de" suffixmassage "ou=b,ou=new,dc=xyz,dc=de" "ou=people,dc=abc,dc=de" idassert-bind bindmethod=simple binddn="cn=proxy,dc=abc,dc=de" credentials="secret" mode=self starttls=no tls_cert=/etc/openldap/certs/client.pem tls_key=/etc/openldap/certs/client.key tls_cacert=/etc/openldap/cacerts/cacerts.pem tls_cacertdir=/etc/openldap/cacerts tls_reqcert=never idassert-authzFrom "dn.exact:cn=root,ou=new,dc=xyz,dc=de" ------------------------------- When I search the meta directory, I only see the ou=a branch. slapd logs the following: conn=1000 op=1 SRCH base="ou=new,dc=xyz,dc=de" scop3D3D1 deref=3 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=objectclass conn=1000 op=1: meta_back_getconn[0] conn=1000 op=1: meta_back_getconn[1] conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN-TLS inserted conn=1000 op=1 >E%E> meta_back_search_start[0] conn=1000 op=1 >>> meta_search_dobind_init[0] conn=1000 op=1 <<< meta_search_dobind_init[0]=2 conn=1000 op=1 <<< meta_back_search_start[0]=2 conn=1000 op=1 >>> meta_back_search_start[1] conn=1000 op=1 >>> meta_search_dobind_init[1] conn=1000 op=1 <<< meta_search_dobind_init[1]=4 conn=1000 op=1 <<< meta_back_search_start[1]=4 conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" conn=1000 op=1 >>> meta_back_search_start[0] conn=1000 op=1 >>> meta_search_dobind_init[5D5D conn=1000 op=1 <<< meta_search_dobind_init[0]=1 ... conn=1000 op=1 <<< meta_back_search_start[0]=1 conn=1000 op=1 >>> meta_search_dobind_init[1] conn=1000 op=1 <<< meta_search_dobind_init[1]=0 ------------------------------- It seems to find both servers, but it only connects to the first one. With ldapsearch I only see the branch "ou=a,ou=new,dc=xyz,dc=de". slapd hangs and can only be terminated by "kill -4". When the first server is specified with ldaps, none of the servers are reachable.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 12 Jan '15

12 Jan '15

On 01/06/2015 04:31 PM, hyc(a)symas.com wrote: > Leonid Yuriev wrote: >> Yes of course, all warnings could be hushed by compiler options, but >> this also hides the real mistakes. >> So, I prefer fix the warnings, instead of disable gcc/clang features. >> >> Please review attached patchset and merge. > > Your patch assumes CPP features that are not guaranteed to be present. > Rejecting this patchset. The Debug() change is going to give merge conflicts all over the place when your <https://github.com/ReOpen/ReOpenLDAP> and OpenLDAP pull updates from each other. How about defining Debug1(), Debug2(), etc for 1,2... arguments? That's still annoying, but it keeps the code C90-compatible and keeps -Wformat quiet. There's already similar code for Log<N>() in include/ldap_log.h, but it was never used much or even merged into RE24. (Because it got scheduled for RE25 which was going to start Real Soon Now, IIRC:-) -- Hallvard

1 0

Re: (ITS#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by h.b.furuseth＠usit.uio.no 08 Jan '15

08 Jan '15

On 08/01/15 20:52, h.b.furuseth(a)usit.uio.no wrote: > Users are likely doing the same thing anyway: Using MDB_RDONLY > instead of MDB_RDONLY|MDB_WRITEMAP on WRITEMAP-written DBs. Er, I mean if any users are doing this. But users do come up with things that the developers never thought of.

1 0

Re: (ITS#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by h.b.furuseth＠usit.uio.no 08 Jan '15

08 Jan '15

On 08/01/15 20:59, Howard Chu wrote: > mdb_env_sync() shouldn't even be doing any work at all if the env was > opened RDONLY. We should return nop in that case. RDONLY means RDONLY! Currently it syncs changes written by another process.

1 0

Re: (ITS#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by hyc＠symas.com 08 Jan '15

08 Jan '15

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: lmdb 0.9.14 > OS: > URL: > Submission from: (NULL) (81.191.45.22) > Submitted by: hallvard > > > mdb_env_sync() works with MDB_RDONLY at least on Unix, but > it syncs MDB_WRITEMAP changes incorrectly: fdatasync instead > of msync because mdb_env_open() cleared MDB_WRITEMAP. > > Users are likely doing the same thing anyway: Using MDB_RDONLY > instead of MDB_RDONLY|MDB_WRITEMAP on WRITEMAP-written DBs. mdb_env_sync() shouldn't even be doing any work at all if the env was opened RDONLY. We should return nop in that case. RDONLY means RDONLY! No writes, no calls that will alter the storage layer. -- -- 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#8021) Wrong mdb_env_sync() with at least MDB_RDONLY
by h.b.furuseth＠usit.uio.no 08 Jan '15

08 Jan '15

Full_Name: Hallvard B Furuseth Version: lmdb 0.9.14 OS: URL: Submission from: (NULL) (81.191.45.22) Submitted by: hallvard mdb_env_sync() works with MDB_RDONLY at least on Unix, but it syncs MDB_WRITEMAP changes incorrectly: fdatasync instead of msync because mdb_env_open() cleared MDB_WRITEMAP. Users are likely doing the same thing anyway: Using MDB_RDONLY instead of MDB_RDONLY|MDB_WRITEMAP on WRITEMAP-written DBs. Finally, writers committing with and without WRITEMAP will sync each others' commits incorrectly. lmdb.h does warn they will "not cooperate well", but it should warn it breaks ACID. LMDBv2 can instead fix all this with 2 bits in MDB_meta: "Changed with/without WRITEMAP since last sync". In LMDBv1, I think the smallest-impact fix is for env_sync to both msync and fdatasync when RDONLY is set and WRITEMAP is clear. A greedier fix would be to always sync both ways when the user calls env_sync. Either way, it may be best to keep WRITEMAP when RDONLY. Only env_map() needs to deal with that. Pushing suggestions except doc to "mdb/wmap-fix" in my repo.

1 0

(ITS#8020) 64bit indexer broken
by hyc＠openldap.org 07 Jan '15

07 Jan '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Only 32 bits of the hash were being used. patch coming shortly

1 0

Re: (ITS#8019) LDAP Replication By attribute
by quanah＠zimbra.com 07 Jan '15

07 Jan '15

--On Wednesday, January 07, 2015 4:19 PM +0000 sofiene.blouza(a)etiam.com wrote: > Full_Name: SOFIENE BLOUZA > Version: 2.4.23-34.el6_5.1 > OS: Centos 6.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.109.110.145) The ITS system is for reporting bugs, not for usage questions. Usage questions belong on the openldap-technical(a)openldap.org list. I would note that the version you reference is extremely old, and it would be advised as your first step to upgrade to a current OpenLDAP release. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

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