- openldap-bugs - openldap.org

Re: (ITS#5142) NullPointerException in com.novell.ldap.Connection.setSocketTimeOut
by tan7f＠virginia.edu 18 Sep '07

18 Sep '07

--Apple-Mail-6--762438716 Content-Type: multipart/alternative; boundary=Apple-Mail-5--762438771 --Apple-Mail-5--762438771 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed --- openldap-jldap.orig/com/novell/ldap/Connection.java 2006-09-07 02:18:29.000000000 -0400 +++ openldap-jldap/com/novell/ldap/Connection.java 2007-09-18 15:56:17.000000000 -0400 @@ -689,7 +689,7 @@ { try { - socket.setSoTimeout(timeout); + if (socket != null) socket.setSoTimeout(timeout); myTimeOut = timeout; } catch(SocketException e) {} return; -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f(a)virginia.edu --Apple-Mail-5--762438771 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; "><DIV>--- = openldap-jldap.orig/com/novell/ldap/Connection.java 2006-09-07 = 02:18:29.000000000 -0400</DIV><DIV>+++ = openldap-jldap/com/novell/ldap/Connection.java=A0 =A0 =A0 2007-09-18 = 15:56:17.000000000 -0400</DIV><DIV>@@ -689,7 +689,7 @@</DIV><DIV>=A0 =A0=A0= {</DIV><DIV>=A0 =A0 =A0 =A0 try</DIV><DIV>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= {</DIV><DIV>-=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = socket.setSoTimeout(timeout);</DIV><DIV>+=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = if (socket !=3D null) socket.setSoTimeout(timeout);</DIV><DIV>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 myTimeOut =3D timeout;</DIV><DIV>=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 } catch(SocketException e) {}</DIV><DIV>=A0 =A0 =A0 =A0 = return;</DIV><BR><DIV> <SPAN class=3D"Apple-style-span" = style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; text-align: auto; = -khtml-text-decorations-in-effect: none; text-indent: 0px; = -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; = "><DIV>--</DIV><DIV>Timothy Nowaczyk</DIV><DIV>Network Systems = Engineer</DIV><DIV>University of Virginia - ITC</DIV><DIV><A = href=3D"mailto:tan7f@virginia.edu">tan7f(a)virginia.edu</A></DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><BR = class=3D"Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>= --Apple-Mail-5--762438771-- --Apple-Mail-6--762438716 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPujCCBIIw ggNqoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn aW5pYTEYMBYGA1UEBxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZp cmdpbmlhMRswGQYDVQQDExJVVkEgVVNIRVIgUEtQIENBIDExJTAjBgkqhkiG9w0BCQEWFnBraW1h c3RlckB2aXJnaW5pYS5lZHUwHhcNMDcwNzEyMjEyNzE0WhcNMjYwMjI1MDAwMDAwWjCBrzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExJTAjBgkqhkiG9w0BCQEWFnBraW1hc3RlckB2 aXJnaW5pYS5lZHUxKzApBgNVBAMTIlVWQSBTdGFuZGFyZCBBc3N1cmFuY2UgVVNIRVIgU0tQIDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbO90WPYQnSOSvhwkIlhh3fLVaHi6X2v2+ kJ7njhzZg8zYoTwMa/sag84dgGu9CCmkzvYryD23mwdQ5oZX58ZyrYCETkcuV5Aycbi70ekTrQPP 1b4x4/sK3PDFSn2S2RB1sNlYy15DI6sIO5mVrV16ML+DGBSJbwGoJRjd+2L5MxkhPJraw5+k2us7 ABxvRpFgaA4TXwJiM8/idtsTNMv2XTR6zUJ9FPq8uOMLtiupbWe2K2tXDDeBSzBu7Z7RzNzxSsZz 72PjtEHhuNQ4I1hsKx/HT2gdxrCb6KxSyGo+QbYxwj5znRkIAFNEQPh6U6EPeDuzJbY/VuFfpsil 3tPZAgMBAAGjgbYwgbMwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFAGp d8MuTIwww/Lbfd5nlCrBvuQZMB8GA1UdIwQYMBaAFDdB3axEwhAHmpxMkx2UHyiXRyUxMFMGA1Ud IARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucGtpLnZpcmdpbmlh LmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAfEvJKxRHr9gy0MufEFva x+QQs2dUN8oocl8jxWsQrQt5Hc6Azzfn2Zp3es10iYkCGNOqj+cRtwoljuWv2yVWm869+xgxskjn uHPnaat84VzXN85i8ILbBZkVYPk1bO2SHjL97RrGvUqi2bJf8cSlzO7g+yTX9/yX0r0QKL4UNHdI p3l3OeTZ0PBLKNhlr1wb6LRpl5+lRZQPWeCij/4e3wA7v9OmWXvevT9YprYTwEmCypPUbnjFeMnP F+hwSgCC+Yov12kP3M+kDwXWpidFGk5p6nQ5c/cGGPd+x8Ek4VjjCw+7TfumwxEJSIX0NmjM+lDx ykVtAMDS11nQ65/VEjCCBVwwggREoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjEwHhcNMDcwNzExMjIyOTQ3WhcNMjYwMjI2MTgwMDAwWjCBnzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExGzAZBgNVBAMTElVWQSBVU0hFUiBQS1AgQ0Eg MTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdpbmlhLmVkdTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANnbscQ3ClhftaALCDqjnqvzU1MVfDmnSNFjSBcGyRRKxNEduA/O4/iD CQ3lKJkRdjhIXN5e5UTe6LsmMY14uPBJOVINmFPiGfsi22LxslYiaGMStWIj3lNF+ZawyUX53WDD IrjlYaBn3wi/m0tkWPLzsgeiRIovL0KVG4XRlkJ70upNCIv6GHP4W6rsa2hqC/gU1QdL+V2XJzE7 sT7l6CysRr01FiyRTOxdoSz+jJFmTTt892sWVry8B7nocD/ltffQ1pQJta4Ve/xWT+TvRPF3X7jn ggOPIYbq0mYRAhWduV1BzlBA8bkTc8AHf8ukjRGydCAPc4OXMamhJ4uETCECAwEAAaOCAeowggHm MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ3Qd2sRMIQB5qcTJMd lB8ol0clMTB9BgNVHSMEdjB0gBQmnSLq7LAPayEK9tkvIMplUOwb06FZpFcwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjGCAQQweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzAChidodHRwOi8v aDEudXNoZXJjYS5vcmcvYWlhL2NhMS1jZXJ0cy5wN2IwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9oMi51 c2hlcmNhLm9yZy9haWEvY2ExLWNlcnRzLnA3YjBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vaDEu dXNoZXJjYS5vcmcvY3JsL2NhMS5jcmwwJ6AloCOGIWh0dHA6Ly9oMi51c2hlcmNhLm9yZy9jcmwv Y2ExLmNybDBOBgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cudXNo ZXJjYS5vcmcvcHJhY3RpY2VzL2NhMS9jcHMucGRmMA0GCSqGSIb3DQEBBQUAA4IBAQCHbtcZxR5o 9B0MgMds0g3g9DBLZSJEi6kRY6heNocsmSsRxEsqE37R6gVtRg3xfTcjJG9E4J4fClB8EK5EDPRo UAJZExJE47aHNXT7KtHgYKqU5dQUXlGi/ZyPpJOA5Nm8xQ+wiDw3kg8AAnM1WrPNnTUiTCYEUqBI KY8AABaJ9CwVHsnu0wV04z4DtbiZgEhxBOczp8L+AveIsJhCTRc3VNlDmHPu9bh4VoyMnbzwlYKk ItLkehDC5xE2ZPTMfC0VYtL+LEDlbGfR0YpzbTzxP3X3dxsmFbIyXAfNvj5gTqViDcgN9CTzblDv oseZLtO0Te+e/YFeTRUBe/CcmUlmMIIF0DCCBLigAwIBAgIDAgQUMA0GCSqGSIb3DQEBBQUAMIGv MQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxs ZTEfMB0GA1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFz dGVyQHZpcmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBT S1AgMTAeFw0wNzA4MDgxMzAzMDBaFw0wODA4MDgxMzAzMDBaMIGVMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTEeMBwGA1UECxMVVVZBIFN0YW5kYXJkIFBLSSBV c2VyMSEwHwYJKoZIhvcNAQkBFhJ0YW43ZkB2aXJnaW5pYS5lZHUxIjAgBgNVBAMTGVRpbW90aHkg QWxsZW4gTm93YWN6eWsgMTMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKEo43l7/lWiNKOe vtraIMIje77qJCSifhZ0CtrBT15E8HPQajBcFnqJ3U//6vvrEeN79de3Gvwygia0SwkgzjtFEsh8 /fLHKvYUDDlhyJxgbaVw3Ay1Ii9cHTyA8hopglAhyVweu08hwrnmSUDBsV+ugqV3AANQ0QwkXPDs WbIbAgMBAAGjggKPMIICizALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBSt9bmjP/g2cbvyzw+7IfnWfnDliDAJBgNVHRMEAjAAMB8GA1UdIwQYMBaA FAGpd8MuTIwww/Lbfd5nlCrBvuQZMEEGA1UdEQQ6MDigIgYKKwYBBAGCNxQCA6AUDBJ0YW43ZkBW aXJnaW5pYS5FRFWBEnRhbjdmQFZpcmdpbmlhLkVEVTCCAXgGA1UdHwSCAW8wggFrMH2ge6B5hnds ZGFwOi8vd3d3LnBraS52aXJnaW5pYS5lZHUvYz1VUyxvPVVuaXZlcnNpdHklMjBvZiUyMFZpcmdp bmlhLG91PVVWQSUyMFN0YW5kYXJkJTIwQXNzdXJhbmNlJTIwVVNIRVIlMjBTS1AlMjAxLGNuPTAy MDQxNDB9oHugeYZ3bGRhcDovL3d3dy5wa2kudmlyZ2luaWEuZWR1L2NuPTAyMDQxNCxvdT1VVkEl MjBTdGFuZGFyZCUyMEFzc3VyYW5jZSUyMFVTSEVSJTIwU0tQJTIwMSxvPVVuaXZlcnNpdHklMjBv ZiUyMFZpcmdpbmlhLGM9VVMwa6BpoGeGZWh0dHA6Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9jZ2kt YmluL2dldC1jcmw/b3U9VVZBJTIwU3RhbmRhcmQlMjBBc3N1cmFuY2UlMjBVU0hFUiUyMFNLUCUy MDEmY249MDIwNDE0MFMGA1UdIARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6 Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOC AQEAY0SUBCrlT0E9VPUQy3lTVDYNQ+ewR3dPa+D4U+gqThk3mbOWSXWEOsYTw9BYOljv4UClAY5M Uhp1Iyj7twzIG8lJnZhVP3G/ToU+8fkCCPUdAH+MJ6eshdZaeEEA/a2RzB0XvvmAfYK5x3e2yYLM tOvfBHrRAl6m5O7wU2t6iykU6vGdL+MB9iqlylY2bxQ0x0NaW5KPL0XuPLgwxVvcds7eIDGOoy7+ WMDaY0miUqsq4PKjg98dnY5BaSUwGFyxhFocw8xtTVdls5VKh3jEvhYyq9ejTHFv49dEnXdmSZ1Y Z3p98sEfQ12+CtFUbzlwphhJELXdC4nm71zFPcXg8zGCA1cwggNTAgEBMIG3MIGvMQswCQYDVQQG EwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0GA1UE ChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdp bmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQIDAgQU MAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDkxODIwMDA0MlowIwYJKoZIhvcNAQkEMRYEFIGAUW9QManJE1XZQo+8fUfKsdWmMIHIBgkr BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID AgQUMA0GCSqGSIb3DQEBAQUABIGAlfRcxdm7UDgGefGGySEL0m3M3UV6QEywpDiBBdEdFRctjycu lA6+VUwNx7ItaRCFBad7xFEqijqqo2Z3HjpiVzgxOag7DaQWJDQqaP8mvDtdf5xTcuu/dPdcRYip YJVs/6elnCxsDFrHj7mnLANhDPHHTrbKABUhyY2WA8w8oF0AAAAAAAA= --Apple-Mail-6--762438716--

1 0

(ITS#5142) NullPointerException in com.novell.ldap.Connection.setSocketTimeOut
by tan7f＠virginia.edu 18 Sep '07

18 Sep '07

Full_Name: Timothy Nowacyzk Version: jldap 4.3 OS: OS X URL: Submission from: (NULL) (137.54.129.39) com.novell.ldap.Connection.setSocketTimeOut should check that socket is != null before attempting socket.setSoTimeout(timeout);

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by richton＠nbcs.rutgers.edu 18 Sep '07

18 Sep '07

Per Ando's comment above, this should be taken into account with SO_KEEPALIVE, but SO_KEEPALIVE didn't come into play with syncrepl until ITS#4708 (2.3.28). The submitter notes "Version: openldap2-2.3.27-25" and I'd recommend an update before this goes too far out...

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by hyc＠symas.com 17 Sep '07

17 Sep '07

ando(a)sys-net.it wrote: > audrius.valunas(a)teo.lt wrote: > >> There is synchronous replication between mastyer and slave. When network >> connectivity problems occur master closes tcp connection but slave doesn't >> notice those problems, it still has tcp connection open, but in real it is not >> receiving updates any more. >> I think that can be solved adding some ack from slave because sending on such a >> socket would fail and force slave to retry connection. > Well, this should already be taken into consideration by SO_KEEPALIVE, > which is always set when available on all connections. I concur that it > usually requires quite a long time before a connection is actually > checked (usually more than 2 hours), so some better policy could be put > in place. On most systems the TCP keepalive timing is a system-wide parameter, so it wouldn't be practical to try to manipulate that here. I suppose if we were to implement our own retry timer we'd need to use a benign op that triggers a reply. Searching the rootDSE for attr 1.1 would suffice. The question is, do we really want to be generating a lot of keepalive traffic like this? The default of 2 hours that most systems use is pretty sane, really. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5140) Solaris 10 test000 root dse bus error
by james.hartley＠gmail.com 17 Sep '07

17 Sep '07

Full_Name: james hartley Version: 2.3.27 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.140.46.100) built with gcc 3.4.6 using the following configure command. $env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib \-L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include \ -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl compile looks good... However I get the following errors during make test... I could not find anything in the archives that pointed to a solution. Only others asking the same question for earlier versions of solaris ,, specifically solaris 8. Can anyone give me a good lead in how to proceed. BTW I have run tests before I installed the software and after I installed the software... After the first test I installed the software anyway. Thanks for any help. cd tests; make test make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' Initiating LDAP tests for BDB... Cleaning up test run directory leftover from previous run. Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 11851 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_bind: Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 1) make[2]: *** [bdb-yes] Error 1 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' make: *** [test] Error 2

1 0

Potential Java LDAPEntry bug when searching with invalid DN.
by Timothy Nowaczyk 17 Sep '07

17 Sep '07

Good Afternoon OpenLDAP list, I have been working with some java code and found what I think may be a bug. If it isn't a bug, then I believe that the documentation should be updated to describe this behavior. I create an LDAPConnection and attempt a search with an invalid search base. The search function returns an LDAPSearchResults that is not null and results.hasMore() returns true. Because there are results we print the number of results and attempt to print them. The call to results.next() causes an exception. The behavior I expected is to throw an exception on the search itself. It seems very misleading to be told that there are entries and then have an exception thrown when the program attempts to analyze them. If this behavior is expected, then is there a better way of detecting an invalid search base as a workaround? Here is the relevant piece of code and my output. try { boolean attributeOnly = true; String attrs[] = { LDAPConnection.NO_ATTRS }; int searchScope = LDAPConnection.SCOPE_ONE; String searchBase = "invalid dn"; String searchFilter = "(objectclass=*)"; LDAPSearchResults results = null; results = lc.search(searchBase, searchScope, searchFilter, attrs, attributeOnly); if (results != null && results.hasMore()) { System.out.println("search yielded " + results.getCount() + " results"); while (results.hasMore()) { LDAPEntry entry = results.next(); System.out.println("Got entry"); System.out.println(entry.toString()); } } System.out.println (lc.read("").toString()); } catch (LDAPException e) { System.out.println ("Could not search: " + e); } and the output search yielded 1 results Could not search: LDAPException: Invalid DN Syntax (34) Invalid DN Syntax LDAPException: Server Message: Invalid DN LDAPException: Matched DN: Many Thanks, Tim Nowaczyk -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f(a)virginia.edu

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by hyc＠symas.com 17 Sep '07

17 Sep '07

bgmilne(a)staff.telkomsa.net wrote: > On Thursday 13 September 2007 23:05:29 ando(a)sys-net.it wrote: >> audrius.valunas(a)teo.lt wrote: >>> There is synchronous replication between mastyer and slave. When network >>> connectivity problems occur master closes tcp connection but slave >>> doesn't notice those problems, it still has tcp connection open, but in >>> real it is not receiving updates any more. >>> I think that can be solved adding some ack from slave because sending on >>> such a socket would fail and force slave to retry connection. >> Well, this should already be taken into consideration by SO_KEEPALIVE, >> which is always set when available on all connections. I concur that it >> usually requires quite a long time before a connection is actually >> checked (usually more than 2 hours), so some better policy could be put >> in place. > I think I filed a previous ITS on this, but the servers exhibiting this Are you referring to ITS#4691, or some other one? (Since 4691 is refreshOnly, I guess it must be something else.) > behaviour in a remote site were lost (power supplies died) so I couldn't test > Howard's fix at the time. We have recently installed some QA servers, which > now also need to traverse a PIX firewall to get to the production master > (from which they replicate one database), and I have seen the behaviour again > (they go out of sync on most of the rare changes to this database until I > restart them or the check kicks in). > I note that a keepalive probably needs to be sent at least once an hour for a > PIX not to drop the connection. I haven't looked up any relevant RFCs on this > though ... A router/firewall should not silently kill an established connection. It should send a TCP RST to notify the endpoints that the connection is gone. > I can now test a fix a lot more easily (since I can upgrade one of these > servers at-will, as opposed to the previous slaves which were in production). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by bgmilne＠staff.telkomsa.net 17 Sep '07

17 Sep '07

On Thursday 13 September 2007 23:05:29 ando(a)sys-net.it wrote: > audrius.valunas(a)teo.lt wrote: > > There is synchronous replication between mastyer and slave. When network > > connectivity problems occur master closes tcp connection but slave > > doesn't notice those problems, it still has tcp connection open, but in > > real it is not receiving updates any more. > > I think that can be solved adding some ack from slave because sending on > > such a socket would fail and force slave to retry connection. > > Well, this should already be taken into consideration by SO_KEEPALIVE, > which is always set when available on all connections. I concur that it > usually requires quite a long time before a connection is actually > checked (usually more than 2 hours), so some better policy could be put > in place. I think I filed a previous ITS on this, but the servers exhibiting this behaviour in a remote site were lost (power supplies died) so I couldn't test Howard's fix at the time. We have recently installed some QA servers, which now also need to traverse a PIX firewall to get to the production master (from which they replicate one database), and I have seen the behaviour again (they go out of sync on most of the rare changes to this database until I restart them or the check kicks in). I note that a keepalive probably needs to be sent at least once an hour for a PIX not to drop the connection. I haven't looked up any relevant RFCs on this though ... I can now test a fix a lot more easily (since I can upgrade one of these servers at-will, as opposed to the previous slaves which were in production). Regards, Buchan

1 0

(ITS#5139) s/should/must/ in slapo-translucent(5)
by ando＠sys-net.it 15 Sep '07

15 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando slapo-translucent(5) states that: The Translucent Proxy overlay uses a remote LDAP server which is con- figured with the options shown in slapd-ldap(5). These slapd.conf options are specific to the Translucent Proxy overlay; they should appear after the overlay directive. I believe this "should" is rather a "must", since before the overlay directive is used, slapd cannot know that slapd-ldap(5) has anything to do with that database stanza. p.

1 0

(ITS#5138) back-ldap still mis-handles search controls
by hyc＠OpenLDAP.org 14 Sep '07

14 Sep '07

Full_Name: Howard Chu Version: RE23/RE24/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc ldap_build_entry() builds the entry's attributes by using ber_scanf until it gets to the end of the LDAP message. Unfortunately, it will read past the sequence of attributes and parse any attached controls as if they were also attributes. Fix coming up...

1 0

(ITS#5137) Potential double-free (on slab) in slapo-chain
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See subject. A fix is coming... p.

1 0

(ITS#5136) Normalized ordered values don't get added consistently
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando A malformed test in ordered_value_add() causes discarding the normalized values during addition from scratch of ordered values. Then a_nvals gets set to a_vals, resulting in incorrect use of normalized values. A fix is coming... p.

1 0

(ITS#5135) Dynlist does not release entry
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando AN entry acquired with overlay_entry_get_ov() is never released by overlay_entry_release_ov(). A fix is coming... p.

1 0

Re: (ITS#5132) test052 fails: ldapadd failed (21)!
by ando＠sys-net.it 14 Sep '07

14 Sep '07

Michael Ströder wrote: > Pierangelo Masarati wrote: >> Fixed in HEAD (HEAD only); please test. > > Still does not work. Something's missing in current HEAD synced now? Probably I forgot to commit the regenerated configure... :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

hyc(a)symas.com wrote: > Once again - does the DB_CONFIG file exist already? That's the only condition > that matters. If you edit the slapd.conf and then delete the existing DB_CONFIG > file, then of course the change will take effect on the next restart. Otherwise > not. Don't make this more complicated than it is. Well, that's a good point: the man page does not say that Berkeley will read its configuration from DB_CONFIG and only from that. It says "The dbconfig directive is just a convenience to allow all necessary configuration to be set in the slapd.conf file." which implies the above, but the more we imply the more we risk getting requests for clarification. I know that Berkeley will read its configuration only from DB_CONFIG, so this point didn't catch my attention at first. Adding such a (yes, redundant for those that already read Berkeley's documentation, but important enough, IMHO, to deserve repetition) statement would probably have made all the remaining unsaid things automatically and logically implied. > Look again. "Specify a configuration directive to be placed in the DB_CONFIG > file of the database directory." It does not say that it specifies settings to > be used by the database, through any temporary magical means. Nowhere does it > imply that the settings will have any effect at all. It simply says that if no > DB_CONFIG file was present, then one will be created. Whether the BDB library > will ever see these settings is completely unstated. Right, +1 for you :) > >> I believe it should clearly state that if DB_CONFIG is present, any >> dbconfig directives are simply ignored. > > I think such a statement is redundant, but I've added it. Thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Russ Allbery wrote: > Perhaps you're only looking at the database directory after slapd starts, > at which point slapd itself has already written out the DB_CONFIG file? I'm just reporting what has been reported to me by people asking for advice on interpreting slapd's behavior. If what has been reported to me is not correct then fine. I'm not going to install Debian just for the purpose of verifying this, but I think I can act on making our own manuals as clear as possible, without adding more than required. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by hyc＠symas.com 13 Sep '07

13 Sep '07

Pierangelo Masarati wrote: > Howard Chu wrote: > >> The manpage also says "This allows one to set initial values without >> overwriting/destroying a DB_CONFIG file that was already customized >> through other means." If the dbconfig settings had any other effect they >> would (a) no longer be *initial* values and (b) overwrite/destroy an >> existing DB_CONFIG file. Clearly that's not the intended behavior. > > Indeed, I found the man page clear about the fact that Debian's behavior > was incorrect (actually, useless). But a second point arose: what if > dbconfig statements not present in the original DB_CONFIG were > subsequently added as dbconfig? This is what would need to disambiguate. Once again - does the DB_CONFIG file exist already? That's the only condition that matters. If you edit the slapd.conf and then delete the existing DB_CONFIG file, then of course the change will take effect on the next restart. Otherwise not. Don't make this more complicated than it is. > > Another point is that slapd-bdb(5) man page insists on the fact that the > DB_CONFIG is not overwritten, but it seems to leave room to speculation > that changes to the dbconfig could **temporarily** take effect, which is > not true. Look again. "Specify a configuration directive to be placed in the DB_CONFIG file of the database directory." It does not say that it specifies settings to be used by the database, through any temporary magical means. Nowhere does it imply that the settings will have any effect at all. It simply says that if no DB_CONFIG file was present, then one will be created. Whether the BDB library will ever see these settings is completely unstated. > I believe it should clearly state that if DB_CONFIG is present, any > dbconfig directives are simply ignored. I think such a statement is redundant, but I've added it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

Howard Chu wrote: > The manpage also says "This allows one to set initial values without > overwriting/destroying a DB_CONFIG file that was already customized > through other means." If the dbconfig settings had any other effect they > would (a) no longer be *initial* values and (b) overwrite/destroy an > existing DB_CONFIG file. Clearly that's not the intended behavior. Indeed, I found the man page clear about the fact that Debian's behavior was incorrect (actually, useless). But a second point arose: what if dbconfig statements not present in the original DB_CONFIG were subsequently added as dbconfig? This is what would need to disambiguate. Another point is that slapd-bdb(5) man page insists on the fact that the DB_CONFIG is not overwritten, but it seems to leave room to speculation that changes to the dbconfig could **temporarily** take effect, which is not true. I believe it should clearly state that if DB_CONFIG is present, any dbconfig directives are simply ignored. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by rra＠stanford.edu 13 Sep '07

13 Sep '07

ando(a)sys-net.it writes: > I didn't mention that the whole discussion started because Debian seems > to ship with both a default DB_CONFIG installed in the database > directory, and the very same directives echoed in slapd.conf. The current Debian packages do not do this so far as I can determine. They do install a DB_CONFIG file when *upgrading* the slapd package, but only if a database already exists and no DB_CONFIG file exists, since that's known to cause extremely poor performance. A new installation of the slapd package does not create a separate DB_CONFIG file in the database directory. It puts dbconfig parameters into slapd.conf and then lets slapd write a DB_CONFIG file. Perhaps you're only looking at the database directory after slapd starts, at which point slapd itself has already written out the DB_CONFIG file? -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by hyc＠symas.com 13 Sep '07

13 Sep '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >>> Reading the man page, I thought that the directives don't modify >>> DB_CONFIG, but were applied at slapd's startup. >> For slapd.conf, the directives can only take effect after they are written to >> DB_CONFIG. They will only be written to DB_CONFIG at startup time, and only if >> no such file already existed. >> >> The main reason this directive was added was for the benefit of cn=config. >> Using it in slapd.conf is rather pointless. Once you start managing slapd >> through cn=config, you are expected to stop editing DB_CONFIG manually. > > I didn't mention that the whole discussion started because Debian seems > to ship with both a default DB_CONFIG installed in the database > directory, and the very same directives echoed in slapd.conf. People > find the dbconfig directives, modify them and complain because they > don't take effect. And, I couldn't disambiguate the man page because I > didn't find it clear enough about this point. The manpage also says "This allows one to set initial values without overwriting/destroying a DB_CONFIG file that was already customized through other means." If the dbconfig settings had any other effect they would (a) no longer be *initial* values and (b) overwrite/destroy an existing DB_CONFIG file. Clearly that's not the intended behavior. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ando＠sys-net.it 13 Sep '07

13 Sep '07

hyc(a)symas.com wrote: >> Reading the man page, I thought that the directives don't modify >> DB_CONFIG, but were applied at slapd's startup. > > For slapd.conf, the directives can only take effect after they are written to > DB_CONFIG. They will only be written to DB_CONFIG at startup time, and only if > no such file already existed. > > The main reason this directive was added was for the benefit of cn=config. > Using it in slapd.conf is rather pointless. Once you start managing slapd > through cn=config, you are expected to stop editing DB_CONFIG manually. I didn't mention that the whole discussion started because Debian seems to ship with both a default DB_CONFIG installed in the database directory, and the very same directives echoed in slapd.conf. People find the dbconfig directives, modify them and complain because they don't take effect. And, I couldn't disambiguate the man page because I didn't find it clear enough about this point. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by rra＠stanford.edu 13 Sep '07

13 Sep '07

hyc(a)symas.com writes: > Raphaël Ouazana-Sustowski wrote: >> Thank you very much for the clarification. >> Just for the records, it seems that Debian packages (and maybe others) >> use dbconfig directives without warning users that they should not >> modify these parameters here... > Thanks for that bit of information, I was not aware of that. For the > record, Debian packagers have never asked us whether what they're doing > makes any bit of sense. Well, that's not exactly true, given that I have in fact talked with Quanah about this and he recommended setting everything in slapd.conf instead of using a separate DB_CONFIG file, although the code in the Debian package predates that. Certainly there should be a comment explaining that changes there only take effect if the DB_CONFIG file doesn't exist. I'll file a bug against the Debian package for whenever someone gets a chance to upload a new version. (I wish I had more time to work on this.) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by ghenry＠suretecsystems.com 13 Sep '07

13 Sep '07

<quote who="Howard Chu"> > Gavin Henry wrote: >> <quote who="Howard Chu"> >>> ghenry(a)suretecsystems.com wrote: >>>> I would say since dbconfig directives only work on a restart of slapd, >>>> and >>>> that if a DB_CONFIG is present, the DB_CONFIG should *always* take >>>> precedence. If dbconfig changes could make a difference via >>>> back-config, >>>> which they can't without a restart, then dbconfig stuff should >>>> override >>>> any DB_CONFIG. >>> dbconfig behavior via cn=config is fully dynamic, and thus quite >>> different >>> from >>> slapd.conf. Changes to dbconfig via cn=config take effect immediately >>> and >>> will >>> completely rewrite the DB_CONFIG file. >> >> Understood, but a restart would still be needed to make the db env >> honour >> DB_CONFIG, right? > > NO. "Fully dynamic" and "take effect immediately" means exactly that. I > did not > say "the file is written immediately but there's no effect until the > server is > restarted." Immediate effect means immediate effect. Do we really have to > say > everything twice or thrice here before people get it? Ok, I get it. I didn't know the db env was reopened when needed with cn=config. Now I do. I'll make sure this is in the docs. I'll try to make it crystal clear! P.S. What does thrice mean? ;-)

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by ando＠sys-net.it 13 Sep '07

13 Sep '07

audrius.valunas(a)teo.lt wrote: > There is synchronous replication between mastyer and slave. When network > connectivity problems occur master closes tcp connection but slave doesn't > notice those problems, it still has tcp connection open, but in real it is not > receiving updates any more. > I think that can be solved adding some ack from slave because sending on such a > socket would fail and force slave to retry connection. Well, this should already be taken into consideration by SO_KEEPALIVE, which is always set when available on all connections. I concur that it usually requires quite a long time before a connection is actually checked (usually more than 2 hours), so some better policy could be put in place. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5134) dbconfig vs. DB_CONFIG
by hyc＠symas.com 13 Sep '07

13 Sep '07

Raphaël Ouazana-Sustowski wrote: > Le Jeu 13 septembre 2007 22:40, Howard Chu a écrit : >> Raphaël Ouazana-Sustowski wrote: >>> Hi, >>> >>> Le Jeu 13 septembre 2007 21:29, hyc(a)symas.com a écrit : >>>> There is nothing ambiguous here. When slapd.conf is being used, the >>>> dbconfig >>>> directive *only* takes effect *if* no DB_CONFIG file exists. If one >>>> exists, the >>>> dbconfig directives are ignored. >>> So if someone first create its DB_CONFIG by putting dbconfig directives >>> in >>> slapd.conf, and then modify these directives, the modification has no >>> effect ? >> Correct. >> >>> Reading the man page, I thought that the directives don't modify >>> DB_CONFIG, but were applied at slapd's startup. >> For slapd.conf, the directives can only take effect after they are written >> to >> DB_CONFIG. They will only be written to DB_CONFIG at startup time, and >> only if >> no such file already existed. >> >> The main reason this directive was added was for the benefit of cn=config. >> Using it in slapd.conf is rather pointless. Once you start managing slapd >> through cn=config, you are expected to stop editing DB_CONFIG manually. > > Thank you very much for the clarification. > > Just for the records, it seems that Debian packages (and maybe others) use > dbconfig directives without warning users that they should not modify > these parameters here... Thanks for that bit of information, I was not aware of that. For the record, Debian packagers have never asked us whether what they're doing makes any bit of sense. I believe it is the packager's responsibility to proactively check these things out; certainly we (OpenLDAP Project) cannot go out and poll every packager. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs