openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#5153) Performance of large multi-valued attributes
by hyc＠OpenLDAP.org 25 Sep '07

25 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc A bit late, but this is just for tracking purposes. HEAD now supports a "sortvals" directive for declaring that specific attributes' values be maintained in sorted order. This allows Compare/Filter operations on attributes with very many values to be completed more efficiently. (From O(n) to O(logn).) Modify operations are also similarly improved.

1 0

Re: (ITS#5152) too much logging
by hyc＠symas.com 25 Sep '07

25 Sep '07

babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3.32 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.11.27) > > > Hello, > > We are having hell of problems in production with # logs getting > generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb > files). > > No debugging/logging turned in slapd. > > Log rotate scripts is moving the logs to diff location to keep the prod up..but > few times we ran of space and I don't find any clue on minimize and log only for > updated transactions. It seems BDB is recording every read/write(not sure)..I > can't enable Auto_Achieve as need them for recovery. > > Any known issue in the space? How to turn of unwanted logging of BDB? Learn how to use BerkeleyDB. http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/… The ITS is for reporting actual bugs in the software. There is no bug here. This ITS will be closed. -- -- 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#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by quanah＠zimbra.com 25 Sep '07

25 Sep '07

--On Monday, September 24, 2007 3:23 PM +0000 tan7f(a)virginia.edu wrote: > > --Apple-Mail-1--260703270 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > Hello OpenLdap Developers, > > I haven't heard anything about the two bugs I've submitted in the > jldap libraries, so I'd like to explain why I feel that these two > issues are important to have fixed. Note that the work on JLDAP is generally done a very different set of developers than most of the OpenLDAP folks, so how soon they'll be addressed I don't know. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5152) too much logging
by Babu.Suresh＠pacificlife.com 25 Sep '07

25 Sep '07

Guys, Any input is greatly appreciated. Please let me know if you need more details of the issue. Thank you _babu -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: Monday, September 24, 2007 3:30 PM To: Suresh, Babu Subject: Re: (ITS#5152) too much logging *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5152. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#5152) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5152) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=5152 Please remember to retain your issue tracking number (ITS#5152) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

(ITS#5152) too much logging
by babu.suresh＠pacificlife.com 25 Sep '07

25 Sep '07

Full_Name: Babu Version: 2.3.32 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.11.27) Hello, We are having hell of problems in production with # logs getting generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb files). No debugging/logging turned in slapd. Log rotate scripts is moving the logs to diff location to keep the prod up..but few times we ran of space and I don't find any clue on minimize and log only for updated transactions. It seems BDB is recording every read/write(not sure)..I can't enable Auto_Achieve as need them for recovery. Any known issue in the space? How to turn of unwanted logging of BDB? ==================Here are the detail of prod volume & DB_CONFIG file===== openldap-2.3.32&BDB 4.5.20 our ldap/BDB is generating too many logs file. Total records in ldap/BDB - 110k Reads - 10k/day Updates - 1k/day =================DB_CONFIG======= # one 0.25 GB cache #set_cachesize 0 268435456 1 set_cachesize 0 5242880 1 # Data Directory set_lk_max_locks 8000 set_lk_max_lockers 8000 set_lk_max_objects 8000 set_lg_max 8048576 ===============SLAPD.conf======== Nothing special in and inxed we have are======== #index index uid eq index cn eq index uniqueMember eq index objectClass pres,eq ============= thank you # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152

1 0

Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by tan7f＠virginia.edu 24 Sep '07

24 Sep '07

--Apple-Mail-1--260703270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello OpenLdap Developers, I haven't heard anything about the two bugs I've submitted in the jldap libraries, so I'd like to explain why I feel that these two issues are important to have fixed. I'd like to create a new LdapConnection with a custom LdapSocketFactory and I want a timeout value set on the socket so that the connect method will timeout in case there is no route to the host or some other networking issue. The documentation leads me to believe that I can do the following. LdapConnection.setSocketFactory(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc = new LdapConnection(timeout); lc.connect ("127.0.0.1", 636); This won't work because the LdapConnection(int) constructor disregards the LdapSocketFactory that is set with the setSocketFactory method and instead uses the default non-SSL encrypted socket. Ok, lets try a workaround. lc = new LdapConnection(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc.setTimeout(timeout); // <--- causes a nullPointerException lc.connect("127.0.0.1", 636); // Program never even gets here. Ok, this is even worse. I now get a nullPointerException in the jldap library itself. Again, nothing in the documentation says to avoid setting the timeout until after you call connect() lc = new LdapConnection(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc.connect("127.0.0.1", 636); lc.setTimeout(timeout); Well, that works, but I'm not setting the timeout until after the connect which isn't what I need. What follows is the only way I can think of getting it to work. class TimeoutLdapSocketFactory extends LDAPJSSESecureSocketFactory { m_timeout = 0; TimeoutLdapSocketFactory() { super (); } TimeoutLdapSocketFactory(int timeout) { this(); m_timeout = timeout; } Socket createSocket (host, port) { Socket socket = super.createSocket(host,port); if (timeout > 0) socket.setSoTimeout(m_timeout); return socket; } lc = new LdapConnection(new TimeoutLdapSocket(timeout)); lc.connect("127.0.0.1", 636); That's a lot of code to do what is already there in the LdapConnection class. If either of the two bugs I've submitted is fixed, then the above use case would be easy to do with-out the uglyness above. I believe #5142 to be a serious bug indeed since it can lead to a nullPointerException in the library. Thank you, Tim Nowaczyk -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f(a)virginia.edu --Apple-Mail-1--260703270 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 DTA3MDkyNDE1MjI1OFowIwYJKoZIhvcNAQkEMRYEFD9bKXbPWwwDKjUSyibAUFSKfHnjMIHIBgkr BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID AgQUMA0GCSqGSIb3DQEBAQUABIGAKppmxD98ZrUSeu76i+2qXl3WV18+NCFKNFF//HeUl4aTKtEq x7K/BLdtJWyU8P+5SqoLRWG/86hBb2ERZNDozP5/6BC/0Gwuh9TUfVyRgxldQL9z8RNoMfv5T9g4 RlrQB9LGxVyAz3t7w3go8xkTBuRR2zLEn183lLBLY6CCpB8AAAAAAAA= --Apple-Mail-1--260703270--

1 0

(ITS#5151) certificateListValidate rejects valid lists
by hyc＠OpenLDAP.org 24 Sep '07

24 Sep '07

Full_Name: Howard Chu Version: HEAD/re24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc I ran into a couple problems; the check for timestamps doesn't take into account that Time is a CHOICE of UTCTime and GeneralizedTime. Also the check for the revocation list doesn't verify that it's a SEQUENCE OF SEQUENCE, so it mistakenly skips over closing signatureAlgorithm if the revocation list is absent. Will be fixed in HEAD shortly.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 24 Sep '07

24 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails >> to parse it because it is an integer with length equal to 9, which is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means from > 0 up to 2^31-1... I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self-consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. I just got tripped trying to import an LDIF with a cert with 16 byte SerialNumber. I've patched this to just use the same hexadecimal format that OpenSSL uses when the number is larger than ber_int_t. We really don't want the format to change just because someone has a BigNum library available; it needs to stay consistent. Normalizing to a string format like this still seems pretty gross, but I guess that's the best we can do given dumb clients that aren't aware of schema. -- -- 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#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 23 Sep '07

23 Sep '07

Ralf Haferkamp wrote: > Please note that test020 currently fails in HEAD sometime. I think this > depends on the order in which the results for queries that hit the > sizelimit are returned. I added tests for sizelimit that were consistent with my changes; however, I'm now short of time to work on this, so feel free to back out those test changes if you believe the code is working correctly, while we design test improvements that are consistent with all fixes. 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#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 23 Sep '07

23 Sep '07

hyc(a)symas.com wrote: > Ralf Haferkamp wrote: >> On Freitag, 21. September 2007, hyc(a)symas.com wrote: >>> It seems to be failing for me more often than not. Why is it >>> non-deterministic? >> It seems that the order in which the entries are inserted into the cache is >> non-deterministic. Because of that the order in which they are returned from >> cache varies as well. The final test that compares the ldapsearch results >> with proxycache.out relies on the order. >> >> I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log >> it seems that sometimes the entries from Query 9 get inserted into the cache >> before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology >> Division, ...") and sometimes after. Depending on that the test either fails >> or succeeds. >> > OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I > see 3 threads still trying to add entries to the cache when the deadlock > occurs. This appears to be a consequence of letting the client continue on > before the pcache overlay has finished its work. But, I thought you were > locking the cache so that requests would not run while query processing was > incomplete? I see, you're only locking individual queries. That's certainly inadequate, you'll probably have to lock the entire cache as a whole. Remember that an entry that you're adding may actually satisfy multiple queries. -- -- 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

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