- openldap-bugs - openldap.org

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 05 Apr '12

05 Apr '12

michael(a)stroeder.com wrote: > Emmanuel Lécharny wrote: >> One more question : why is this AT multi-valued ? Does it make sense ? (Just >> curious) > > I tried this static configuration: > > overlay auditlog > auditlog /tmp/auditlog1.ldif > auditlog /tmp/auditlog2.ldif > > Only file /tmp/auditlog2.ldif is created and changes get writte to this single > file. > > So yes, I support to > 1. set SINGLE-VALUE for this attribute type and Probably a good idea. > 2. add an equality matching rule. My approach with config attrs has been to skip the equality rule for single-valued attrs. Since they are single-valued, there's obviously no need to allow for comparing multiple values. -- -- 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#7227) Problem to add new entry
by rai.abhishek＠yahoo.com 05 Apr '12

05 Apr '12

Full_Name: Abhishek Rai Version: 3 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.46.55.29) Hi All I am using OPENLDAP on windows server 2008 R2 but i face some issue regarding add new entry like (Country and Organization etc). the error message are An error occurred while creating entry. The server is not willing to handle directory requests. but with the same setting i am able to create some entry like (Person,GrouoofNames,Organizational Unit) i am new for LDAP but as per my understanding it's a access problem in slapd.conf file. for safe point i am modifyed the config file and provide below access slapd.conf access to * by * write Please suggest what need to do to perform add new entry operation for all objects. thanks in advance. Abhishek Rai

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

Emmanuel Lécharny wrote: > One more question : why is this AT multi-valued ? Does it make sense ? (Just > curious) I tried this static configuration: overlay auditlog auditlog /tmp/auditlog1.ldif auditlog /tmp/auditlog2.ldif Only file /tmp/auditlog2.ldif is created and changes get writte to this single file. So yes, I support to 1. set SINGLE-VALUE for this attribute type and 2. add an equality matching rule. Ciao, Michael.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms010606090903000904060909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Re-added Cc: openldap-its(a)openldap.org) Emmanuel L=C3=A9charny wrote: > Le 4/5/12 1:55 PM, Michael Str=C3=B6der a =C3=A9crit : >> elecharny(a)apache.org wrote: >>> When trying to inject more than one value into the olcAuditlogFile AT= , we get >>> the following error : >>> >>> LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matchi= ng rule >> How did the modification list look like in your modify request? >> >> This LDAP error code is typically returned if you try to add or remove= >> specific value(s) to an existing multi-valued attribute which does not= have an >> equality matching rule defined for it. In this case the server is not = capable >> to check whether the value exists or not. > The olcAuditlogFile does have a Syntax (DirectoryString) thus an equali= ty MR. No it does not have an equality matching rule. And the diagnosticMessage returned by the server is pretty clear on that. Look at the subschema. > The error is really not associated with the value we are trying to inje= ct : It is because... > Second value : > #!RESULT ERROR > #!CONNECTION ldap://10.211.55.4:10389 > #!DATE 2012-04-05T11:32:50.776 > #!ERROR [LDAP: error code 18 - modify/add: olcAuditlogFile: no equality= > matching rule] > dn: olcOverlay=3D{0}auditlog,olcDatabase=3D{1}bdb,cn=3Dconfig > changetype: modify > add: olcAuditlogFile > olcAuditlogFile: /ldap/file2.log > - =2E..with such a modify request the server wants to check whether the new= value '/ldap/file2.log' is already present in the attribute value set. An equal= ity matching rule has to be defined for the attribute type to make this work.= >> =3D> Your client should never do that if it's meant to be generally u= sable. > Really, it seems to be something the server is not handling correctly. Nope. >> Safest approach is to send a MOD_DEL without value and MOD_ADD with al= l values. > That would be totally overkilling if you have thousands of values in yo= ur AT. It's the only valid approach in case there's no equality matching rule de= fined for the attribute type. > Plus that forces the client to first fetch the values from the server, = to > compute locally the differences Yes. > (what if the value we try to add is already > present ?), It depends... ;-) > which means we have a way to do the comparison locally, which > means we have some knowledge about the MR locally. Yes. In practice it turned out to be sufficient to compare the byte buffers. := -) And that's why my web2ldap looks for equality matching rule definition in= the schema and generates different attribute value diffs accordingly. Tested = with many different LDAP servers... Ciao, Michael. --------------ms010606090903000904060909 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTEyMTYwNVowIwYJKoZIhvcNAQkEMRYE FM+iAFFRy97LDfUOWFNxFPhbfyYoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAuMqNcfc7oloFkZwyG6NM8IbEbOenwM9VV9eeNGRgcz3RdhUBt47RCErfi5y8Kae0yI1L 9PMksGezPPCZbtKoTbknMRRrigzpVBRjiKF8MLWF0ny0VzUj8j2uljQWy7xTHE+5yx0e61P7 airHwIQS8u63y50kvg3PT6POJB0TyRQqvZ8UUFBK6JEqXkY7DVrS9VxS6SelbOuJUtiNKkRD AkEbrE5ug8rTafR+onCa1gNlUNHLomc+0zLKb+8VRr4etfVOyLDhdYLPhJ/u5qePh3PHpX8B i3/I2bRD72ktlZYL48mwFKEma7LrUPf9Ky0EVYLCk9FR8/w4kCvxEOfmPQAAAAAAAA== --------------ms010606090903000904060909--

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000508090704090002020303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable elecharny(a)apache.org wrote: > When trying to inject more than one value into the olcAuditlogFile AT, = we get > the following error : >=20 > LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matching= rule How did the modification list look like in your modify request? This LDAP error code is typically returned if you try to add or remove specific value(s) to an existing multi-valued attribute which does not ha= ve an equality matching rule defined for it. In this case the server is not cap= able to check whether the value exists or not. =3D> Your client should never do that if it's meant to be generally usabl= e. Safest approach is to send a MOD_DEL without value and MOD_ADD with all v= alues. I do not comment on whether this particular attribute could/should be multi-valued or not though. Ciao, Michael. --------------ms000508090704090002020303 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTExNTU0M1owIwYJKoZIhvcNAQkEMRYE FFTBFviMbNYD5i9VnOyiqWgQXXQ/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEARQ6sifL1/BiD13CFPOFaEYCvpCq3ap4S8Yo3NUi3RhU9kG2dME2iUKUF98327sLNX+B2 b0czRaFeWckhCg+sKi7N810mMHpatZpdzQMTryYLQf8a7GlWW7tdk5sqyE8CcXFx3AOD7kll l+VIGaSdUjo9ao+RnP0m2HTO/lzCyy0KdVqUvOT0FvoIRIvUStcALrETOH8q+5kjM2kB9+c/ JBsbAti5xwomP+DuXdogRuTx1ondqSzny9h44sctok3ojmNtXO5IC9NeMwwWmYp94nYyTXOf 6UWi9Nfop98Z+O+SjaC2pFY3z7dYS/vLIl9gya+aX7IMf52ToTGf/pm1NQAAAAAAAA== --------------ms000508090704090002020303--

1 0

(ITS#7226) olcAuditlogFile At dos not accept multiple values
by elecharny＠apache.org 05 Apr '12

05 Apr '12

Full_Name: Emmanuel Lecharny Version: 2.4.24 OS: Mac OSX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.4.211) When trying to inject more than one value into the olcAuditlogFile AT, we get the following error : LDAP: error code 18 - modify/add: olcAuditlogFile: no equality matching rule We assume that this AT should be SINGLE-VALUE, and this is why we get this error, even if the description states it's not single valued : ( 1.3.6.1.4.1.4203.1.12.2.3.3.15.1 NAME 'olcAuditlogFile' DESC 'Filename for auditlogging' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Also note that the error message is quite strange, as the DirectoryString syntax as an equality MR.

1 0

Re: (ITS#7197) olcTLSVerifyClient missing options
by quanah＠zimbra.com 04 Apr '12

04 Apr '12

--On Sunday, March 04, 2012 8:40 PM +0000 quanah(a)OpenLDAP.org wrote: see also <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658749> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 04 Apr '12

04 Apr '12

(gdb) p oc $1 = (ObjectClass *) 0x7b91460 (gdb) p *oc $2 = {soc_oclass = {oc_oid = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16", oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions = 0x0}, soc_cname = {bv_len = 26, bv_val = 0x7b910e0 "1.3.6.1.4.1.6152.10.3.2.16"}, soc_sups = 0x7b91110, soc_required = 0x7b91130, soc_allowed = 0x0, soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next = 0x7b92d40}} (gdb) p names $3 = (char **) 0x0 (gdb) p *names Cannot access memory at address 0x0

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is that this happened in "pthread_mutex_lock" which is in libpthread.so ...? Another bug in centos libs? I would appreciate if you could take a look. Thx. H. p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 04 Apr '12

04 Apr '12

hyc(a)symas.com wrote: > Ondrej Kuznik wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: >>> ondrej.kuznik(a)acision.com wrote: >>>> Full_Name: Ondrej Kuznik >>>> Version: HEAD >>>> OS: Linux >>>> >>> I have pushed patches 1-3 to git master. patch 4 seems to require additional work. >> >> I have reworked the remaining patches according to your suggestions, the >> resulting patchset is at: >> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… > > Committed to master, thanks for the patches. See ITS#7225. Even after the SEGV is patched, the pcache slapd fails to start in test020 because the monitor calls are unable to register their entries. Something is wrong in your initialization code. Also, you're using monitor_entry_stub() directly in the back-ldap code. It is forbidden for modules to directly reference each other's symbols. If you need this function, add it to monitor_extra_t first and call it through there. -- -- 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#7225) back-monitor/ldap crash in test020-proxycache
by h.b.furuseth＠usit.uio.no 04 Apr '12

04 Apr '12

Full_Name: Hallvard B Furuseth Version: master, fc1396fa2e94ee2e752fd7c3ea5bb22f6592398a OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard back-ldap:ldap_back_monitor_conn_init() calls monitor_back_register_entry_attrs(,,,nbase=NULL,,) which crashes at: 1093 if ( !BER_BVISNULL( nbase ) ) { That checks if nbase->bv_val is NULL, it does not check nbase itself. Backtrace: #0 monitor_back_register_entry_attrs (ndn_in=0x1023d50, a=0x1092be8, cb=0x10f59b0, nbase=0x0, scope=0, filter=0x0) at init.c:1093 #1 ldap_back_monitor_conn_init (be=0x104d0c0, ms=0x1023d28) at monitor.c:658 #2 monitor_back_db_open (be=0x104d0c0, cr=0x7fff704846e0) at init.c:2365 #3 backend_startup_one (be=0x104d0c0, cr=0x7fff704846e0) at backend.c:224 #4 backend_startup (be=0x104d0c0) at backend.c:325 #5 slap_startup (be=0x0) at init.c:219

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: >> >> So, am i doing something wrong or openldap is...? > > > Looks like your glibc malloc is deadlocked. A Centos bug, not an > OpenLDAP bug. > > In the trace, you could confirm this in gdb with: > thread 13 > frame 3 > print *mutex > > most likely the "owner" field of this mutex will be 1502, which > corresponds to thread 17, which is waiting for a lock inside libc > malloc/free. > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. Thanx for inside info ... :-) And sorry that i was unable to provide more info - core dump alone is 16gb! Also, small sidenote - when this "hang" happens, it only affects existing connections - i'm attacking it with two procesess, each 4 connection. New searches using ldapsearch work fine ... And correction for typo - by "high load" i wrote (1-2 req/sec) - actually it should write 1-2k reg/sec ... What is interesting regarding this, that this "problem" goes back to db-4.7 and openldap-2.4.23 (provided with centos) ... I'll try alternate malloc and report back ... H.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 04 Apr '12

04 Apr '12

On 04/04/2012 02:39 AM, ashish(a)sendmail.com wrote: > Full_Name: Ashish Gawarikar > Version: 2.4.30 > OS: Redhat 5.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.80.56.188) > > > I got a core dump while trying to run slapd: > > This is the stack trace of the core: > > (gdb) where > #0 oc_delete_names (oc=0xeaa6080) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x00000000004050bf in main (argc=<value optimized out>, argv=0x7fff1b533918) > at main.c:1068 > > > A similar stack trace was produced while trying to do slapadd: > > #0 oc_delete_names (oc=0x171e86f0) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 > #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value > optimized out>) at slapadd.c:493 > #5 0x0000000000404f32 in main (argc=3, argv=0x7fffa4770db8) at main.c:410 > > > These are the configuration params: > --enable-accesslog --enable-auditlog --enable-collect --enable-constraint > --enable-dyngroup --enable-dynlist --enable-hdb --enable-memberof > --enable-ppolicy --enable-refint --enable-relay --enable-retcode --enable-rwm > --enable-seqmod --enable-translucent --enable-unique --enable-valsort > --enable-slapd --disable-mdb --enable-bdb --enable-proctitle --enable-ldap > --enable-meta --enable-rewrite --enable-monitor --enable-aci --enable-cleartext > --enable-crypt --enable-debug --enable-local --enable-lmpasswd > --enable-proxycache --with-threads --enable-static --disable-shared > --enable-local --enable-syslog --localstatedir=/var --sysconfdir=/etc/mail > --enable-ipv6 --with-cyrus-sasl --enable-spasswd --with-tls > > > Please let me know if you need more information. Con you provide: p oc p *oc p names p *names Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 03 Apr '12

03 Apr '12

Full_Name: Ashish Gawarikar Version: 2.4.30 OS: Redhat 5.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.80.56.188) I got a core dump while trying to run slapd: This is the stack trace of the core: (gdb) where #0 oc_delete_names (oc=0xeaa6080) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x00000000004050bf in main (argc=<value optimized out>, argv=0x7fff1b533918) at main.c:1068 A similar stack trace was produced while trying to do slapadd: #0 oc_delete_names (oc=0x171e86f0) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:493 #5 0x0000000000404f32 in main (argc=3, argv=0x7fffa4770db8) at main.c:410 These are the configuration params: --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dyngroup --enable-dynlist --enable-hdb --enable-memberof --enable-ppolicy --enable-refint --enable-relay --enable-retcode --enable-rwm --enable-seqmod --enable-translucent --enable-unique --enable-valsort --enable-slapd --disable-mdb --enable-bdb --enable-proctitle --enable-ldap --enable-meta --enable-rewrite --enable-monitor --enable-aci --enable-cleartext --enable-crypt --enable-debug --enable-local --enable-lmpasswd --enable-proxycache --with-threads --enable-static --disable-shared --enable-local --enable-syslog --localstatedir=/var --sysconfdir=/etc/mail --enable-ipv6 --with-cyrus-sasl --enable-spasswd --with-tls Please let me know if you need more information.

1 0

Re: (ITS#7219) back-mdb crash when used as accesslog
by quanah＠zimbra.com 03 Apr '12

03 Apr '12

--On Friday, March 30, 2012 11:37 PM +0000 quanah(a)OpenLDAP.org wrote: How to reproduce: What I do is run the add/del of 50k entries used in ITS#7210 5-6 times to > get a reasonably sized accesslog. Initially, I have the log purge set to > run once a day, deleting anything a week old (so nothing gets deleted). > > Then I change the logpurge to "00+00:10 00+00:05". > > After this, slapd dies from hitting the assert. -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7223) back-mdb: accesslog segv on second cleanup run
by quanah＠OpenLDAP.org 03 Apr '12

03 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/1/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If you have an accesslog setup using back-mdb, it will segv in the following condition: Do a bunch of modifications, and then set up accesslog to clean them out periodically. In my test, I had it so that the accesslog DB was cleaned every 5 minutes, of any entries > 10 minutes old. Initially I had it set to clean up everything > 1 week old, running once a day, so I could gather data in the accesslog DB without triggering the purge. The first cleanup ran @ 5 minutes, and removed all entries from the accesslog DB, as they were all older than 10 minutes. The second run, with the now empty DB, triggered a SEGV: Program terminated with signal 11, Segmentation fault. #0 0x00007f38dfeb17b0 in mdb_page_alloc (mc=0xd3d8a80, num=1) at ./../../../libraries/libmdb/mdb.c:1317 1317 ./../../../libraries/libmdb/mdb.c: No such file or directory. in ./../../../libraries/libmdb/mdb.c #0 0x00007f38dfeb17b0 in mdb_page_alloc (mc=0xd3d8a80, num=1) at ./../../../libraries/libmdb/mdb.c:1317 txn = 0xd3ce000 np = 0x323d747261745371 pgno = 69385 mid = {mid = 139710414625424, mptr = 0x7f38dfeb5cdf} #1 0x00007f38dfeb18c6 in mdb_page_touch (mc=0xd3d8a80) at ./../../../libraries/libmdb/mdb.c:1349 np = 0xd3f2000 mp = 0x7f24f0114000 pgno = 69525 __PRETTY_FUNCTION__ = "mdb_page_touch" #2 0x00007f38dfeb7bc7 in mdb_cursor_touch (mc=0xd3d8a80) at ./../../../libraries/libmdb/mdb.c:4116 rc = 0 #3 0x00007f38dfeb93dd in mdb_cursor_del (mc=0xd3d8a80, flags=0) at ./../../../libraries/libmdb/mdb.c:4486 leaf = 0x0 rc = 0 #4 0x00007f38dfeaec65 in mdb_idl_delete_keys (cursor=0xd3d8a80, keys=0x3782c08, id=64) at idl.c:597 rc = 0 k = 0 key = {mv_size = 5, mv_data = 0x3782c30} data = {mv_size = 8, mv_data = 0x7f24f012c068} lo = 5 hi = 139706696817899 tmp = 40 i = 0x7f24f012c010 err = 0x7f38dfec37f4 "c_get" __PRETTY_FUNCTION__ = "mdb_idl_delete_keys" #5 0x00007f38dfea4faf in indexer (op=0x7f10dda2a440, txn=0xd3ce000, ai=0x12172c0, ad=0x11b87c0, atname=0x11e9028, vals=0x3782b48, id=64, opid=2, mask=4) at index.c:219 rc = 0 i = 26075136 keys = 0x3782c08 mc = 0xd3d8a80 keyfunc = 0x7f38dfeaea37 <mdb_idl_delete_keys> err = 0x7f38dfec27ea "c_open" __PRETTY_FUNCTION__ = "indexer" #6 0x00007f38dfea5363 in index_at_values (op=0x7f10dda2a440, txn=0xd3ce000, ad=0x11b87c0, type=0x11e8fc0, tags=0x11b87e0, vals=0x3782b48, id=64, opid=2) at index.c:337 rc = 0 mask = 4 ixop = 2 ai = 0x12172c0 #7 0x00007f38dfea54e7 in mdb_index_values (op=0x7f10dda2a440, txn=0xd3ce000, desc=0x11b87c0, vals=0x3782b48, id=64, opid=2) at index.c:386 rc = 0 #8 0x00007f38dfea59af in mdb_index_entry (op=0x7f10dda2a440, txn=0xd3ce000, opid=2, e=0x37823c8) at index.c:558 rc = 0 ap = 0x3782620 #9 0x00007f38dfe994ae in mdb_delete (op=0x7f10dda2a440, rs=0x7f10dda2a2b0) at delete.c:348 mdb = 0x18de000 pdn = {bv_len = 12, bv_val = 0xd5bec20 "cn=accesslog"} e = 0x37823c8 p = 0x3782158 manageDSAit = 0 children = 0x11b8ec0 entry = 0x11b8f00 txn = 0xd3ce000 mc = 0xd3d8a80 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x18de000}, moi_txn = 0xd3ce000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f10dda29ed0 preread_ctrl = 0x0 ctrls = {0x0, 0xfffffffffffffff9, 0x7f10dda29f10, 0x0, 0x0, 0x4} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #10 0x00000000004d4a48 in overlay_op_walk (op=0x7f10dda2a440, rs=0x7f10dda2a2b0, which=op_delete, oi=0x166d680, on=0x0) at backover.c:671 func = 0x7f38e00c7d18 rc = 32768 #11 0x00000000004d4c86 in over_op_func (op=0x7f10dda2a440, rs=0x7f10dda2a2b0, which=op_delete) at backover.c:723 oi = 0x166d680 on = 0x1706f00 be = 0x11ee9c0 db = {bd_info = 0x7f38e00c7cc0, bd_self = 0x11ee9c0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x1687840, be_nsuffix = 0x1687820, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x16766d0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x16766b0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x16a0e00, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x14bf900, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7f38e00c7ac0, be_private = 0x18de000, be_next = {stqe_next = 0x11ef6c0}} cb = {sc_next = 0x7f38dfa51c60, sc_response = 0x4d3780 <over_back_response>, sc_cleanup = 0, sc_private = 0x166d680} sc = 0x7f10dda2a578 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x00000000004d4e6f in over_op_delete (op=0x7f10dda2a440, rs=0x7f10dda2a2b0) at backover.c:780 No locals. #13 0x00007f38df847f61 in accesslog_purge (ctx=0x7f10dda2ab50, arg=0x1298000) at accesslog.c:689 i = 62 rtask = 0x1298000 li = 0x17ea090 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_listener = 0x501ca0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x454a15 <slap_send_ldap_result>, c_send_search_entry = 0x45571d <slap_send_search_entry>, c_send_search_reference = 0x457c43 <slap_send_search_reference>, c_send_ldap_extended = 0x45527c <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4554fa <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f10dda2a5b0, o_tag = 74, o_time = 1333399445, o_tincr = 0, o_bd = 0x7f10dda2a0c0, o_req_dn = {bv_len = 44, bv_val = 0xd5bec30 "reqStart=20120402202935.000125Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0xd5bec00 "reqStart=20120402202935.000125Z,cn=accesslog"}, o_request = {oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rb_ssf = 3718423536, rb_mech = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = { rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rs_nnewrdn = {bv_len = 139710414627824, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x3780008, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x75cd60, rs_filter = 0x7f10dda2a3f0, rs_filterstr = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = { bv_len = 7720288, bv_val = 0x7f10dda2a3f0 "\246"}, rs_new = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7f10dda2a6f8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x16766d0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x16766b0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x37820b0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f10dda2aac0 "20120402203319.698132Z#000000#000#000000\v\336C"}, o_private = 0x0, o_extra = {slh_first = 0x7f10dda29ed0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7f10dda2a800, oh_msgid = 0, oh_protocol = 0, oh_tid = 139710414632704, oh_threadctx = 0x7f10dda2ab50, oh_tmpmemctx = 0x1651a00, oh_tmpmfuncs = 0x75d320, oh_counters = 0x7607a0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7f10dda2a440 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x7f38df84787e <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7f10dda2a360} f = {f_choice = 166, f_un = {f_un_result = -576543792, f_un_desc = 0x7f10dda2a3d0, f_un_ava = 0x7f10dda2a3d0, f_un_ssa = 0x7f10dda2a3d0, f_un_mra = 0x7f10dda2a3d0, f_un_complex = 0x7f10dda2a3d0}, f_next = 0x0} ava = {aa_desc = 0x1251240, aa_value = {bv_len = 15, bv_val = 0x7f10dda2ab00 "20120402203405Z"}} pd = {slots = 100000, used = 100000, dn = 0xe3b8000, ndn = 0xe588000, csn = {bv_len = 40, bv_val = 0x7f10dda2aac0 "20120402203319.698132Z#000000#000#000000\v\336C"}} timebuf = "20120402203405Z\000\241\210\001\000\000" csnbuf = "20120402203319.698132Z#000000#000#000000\v\336C\000\000\000\000\000\366\250\322\343\070\177\000\000\000\000\000\000\002\000\000" old = 1333398845 __PRETTY_FUNCTION__ = "accesslog_purge" #14 0x00007f38e51e9cc9 in ldap_int_thread_pool_wrapper (xpool=0x11d21c0) at tpool.c:688 pool = 0x11d21c0 task = 0x14ca440 work_list = 0x11d2258 ctx = {ltu_id = 139710414632704, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x1651a00, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x317c000, ltk_data = 0x14cc000, ltk_free = 0x7f38dfeac523 <mdb_reader_free>}, {ltk_key = 0x347e000, ltk_data = 0x14cf400, ltk_free = 0x7f38dfeac523 <mdb_reader_free>}, {ltk_key = 0x7f38dfea23c4, ltk_data = 0x3e80000, ltk_free = 0x7f38dfea23a1 <search_stack_free>}, {ltk_key = 0x7f38dfe9fda9, ltk_data = 0x3880000, ltk_free = 0x7f38dfe9fd61 <scope_chunk_free>}, { ltk_key = 0x43d3cd, ltk_data = 0x167ae00, ltk_free = 0x43d211 <conn_counter_destroy>}, {ltk_key = 0x459151, ltk_data = 0x16fc800, ltk_free = 0x4590a4 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0xd5d1600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 965 hash = 2784641989 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007f38e3d259ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #16 0x00007f38e3a8270d in clone () from /lib/libc.so.6 No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#7222) Slapd hangs on high load
by hyc＠symas.com 03 Apr '12

03 Apr '12

hrvoje.habjanic(a)zg.t-com.hr wrote: > Full_Name: Hrvoje > Version: 2.4.30 > OS: Centos 6.2 x86_64 > URL: http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log > Submission from: (NULL) (195.29.148.138) > > > > Hi. > > While testing openlap, with some of my data, slapd regularly hangs. I did manage > to "catch" it, but i need expert's interpretation of traces. > > I' using db-5.3.15 (latest), compiled with: > > ../dist/configure \ > --enable-shared --enable-static \ > --enable-tcl --with-tcl=/usr/lib64 \ > --enable-cxx --enable-sql \ > --enable-java \ > --enable-test \ > --with-tcl=/usr/lib64/tcl8.5 \ > --disable-rpath \ > --enable-debug \ > --prefix=/usr/local/db > > and openldap-2.4.30, compiled with: > > CFLAGS="-g -I/usr/local/db/include" CPPFLAGS="-g -I/usr/local/db/include" > LDFLAGS="-L/usr/local/db/lib -Wl,-R/usr/local/db/lib" ./configure \ > --prefix=/usr/local/openldap \ > --enable-local \ > --enable-rlookups \ > --with-tls=no \ > --with-cyrus-sasl \ > --enable-wrappers \ > --enable-passwd \ > --enable-cleartext \ > --enable-crypt \ > --enable-spasswd \ > --disable-lmpasswd \ > --enable-modules \ > --disable-sql \ > --enable-slapd \ > --enable-bdb \ > --enable-hdb \ > --enable-ldap \ > --enable-meta \ > --enable-monitor \ > --enable-null \ > --enable-shell \ > --disable-ndb \ > --enable-passwd \ > --enable-sock \ > --disable-perl \ > --enable-relay \ > --disable-shared \ > --disable-dynamic \ > --enable-overlays=mod \ > --enable-mdb \ > --enable-debug=yes > > Slapd is configured to use slapd.d directory (db). Inside, two databases are > configured - ie. ou=p,dc=pero,dc=com and ou=d,dc=pero,dc=com, including monitor > db. First database is using 10Gb on disk, and have around 10M unique dn's, while > second one is using around 3-4Gb, few mil. dn's. > > Server have 16G of ram, and 2xquad core CPU - total of 8 cpu's (and disks are > local). > > I'm using python scripts to generate load on openldap. First i fill in required > data (10Gb), and then do some transaction processing (read/update/write). > > Filling part goes without problems, but on transaction processing, slapd > regularly gets stuck. I'm only able to trigger this using more than one > connection - simulating couple of clients, and high load (1-2 req/sec). > Complete traces from gdb when this happens, are > http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log . > > So, am i doing something wrong or openldap is...? Looks like your glibc malloc is deadlocked. A Centos bug, not an OpenLDAP bug. In the trace, you could confirm this in gdb with: thread 13 frame 3 print *mutex most likely the "owner" field of this mutex will be 1502, which corresponds to thread 17, which is waiting for a lock inside libc malloc/free. You may be able to avoid this bug by using an alternate malloc library, such as Google tcmalloc. -- -- 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#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 03 Apr '12

03 Apr '12

Full_Name: Hrvoje Version: 2.4.30 OS: Centos 6.2 x86_64 URL: http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log Submission from: (NULL) (195.29.148.138) Hi. While testing openlap, with some of my data, slapd regularly hangs. I did manage to "catch" it, but i need expert's interpretation of traces. I' using db-5.3.15 (latest), compiled with: ../dist/configure \ --enable-shared --enable-static \ --enable-tcl --with-tcl=/usr/lib64 \ --enable-cxx --enable-sql \ --enable-java \ --enable-test \ --with-tcl=/usr/lib64/tcl8.5 \ --disable-rpath \ --enable-debug \ --prefix=/usr/local/db and openldap-2.4.30, compiled with: CFLAGS="-g -I/usr/local/db/include" CPPFLAGS="-g -I/usr/local/db/include" LDFLAGS="-L/usr/local/db/lib -Wl,-R/usr/local/db/lib" ./configure \ --prefix=/usr/local/openldap \ --enable-local \ --enable-rlookups \ --with-tls=no \ --with-cyrus-sasl \ --enable-wrappers \ --enable-passwd \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --disable-lmpasswd \ --enable-modules \ --disable-sql \ --enable-slapd \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-null \ --enable-shell \ --disable-ndb \ --enable-passwd \ --enable-sock \ --disable-perl \ --enable-relay \ --disable-shared \ --disable-dynamic \ --enable-overlays=mod \ --enable-mdb \ --enable-debug=yes Slapd is configured to use slapd.d directory (db). Inside, two databases are configured - ie. ou=p,dc=pero,dc=com and ou=d,dc=pero,dc=com, including monitor db. First database is using 10Gb on disk, and have around 10M unique dn's, while second one is using around 3-4Gb, few mil. dn's. Server have 16G of ram, and 2xquad core CPU - total of 8 cpu's (and disks are local). I'm using python scripts to generate load on openldap. First i fill in required data (10Gb), and then do some transaction processing (read/update/write). Filling part goes without problems, but on transaction processing, slapd regularly gets stuck. I'm only able to trigger this using more than one connection - simulating couple of clients, and high load (1-2 req/sec). Complete traces from gdb when this happens, are http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log . So, am i doing something wrong or openldap is...? H.

1 0

(ITS#7221) Support private keys in PKCS #8 in slapd when linked with gnutls
by komyagin＠altell.ru 03 Apr '12

03 Apr '12

Full_Name: Alexander Komyagin Version: 2.4.23 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.16.156.18) Hi! I found out that when slapd is linked with gnutls, it fails to parse private key on startup if the one is given in PKCS #8 form (TLS init def ctx failed: -207). The problem is in tlsg_ctx_init() (tls_g.c) function, which calls gnutls_x509_privkey_import() from gnutls. But gnutls_x509_privkey_import() is designed to support only RSA/DSA keys, while for PKCS#8 gnutls_x509_privkey_import_pkcs8() shall be used. I think that incorporating such enhancement for slapd would make it even better (for example, some popular commands like "openssl req" generate keys in PKCS #8) :) Especially when such enhancement can be done in a few lines of code (just like certtool does): if (!info.pkcs8) ret = gnutls_x509_privkey_import (key, &pem, info.incert_format); /* If we failed to import the certificate previously try PKCS #8 */ if (info.pkcs8 || ret == GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) { /* first try to import the key without asking any password */ ret = gnutls_x509_privkey_import_pkcs8 (key, &pem, info.incert_format, NULL, GNUTLS_PKCS_PLAIN); if (ret < 0) { if (info.pass) pass = info.pass; else pass = get_pass (); ret = gnutls_x509_privkey_import_pkcs8 (key, &pem, info.incert_format, pass, 0); } }

1 0

Re: RE : RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Apr '12

02 Apr '12

jiashun.qian(a)atos.net wrote: > After the tests, these patchs work but not work for what we expect. According to Howard Chu, "Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules." These patchs send binary data to backends. Could you change this ? I probably mis-spoke. Only back-shell deals exclusively in LDIF, back-perl is obviously passing native perl variables around. > ________________________________________ > De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de quanah(a)zimbra.com [quanah(a)zimbra.com] > Date d'envoi : jeudi 29 mars 2012 19:26 > À : openldap-its(a)openldap.org > Objet : Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data > > --On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net > wrote: > >> This is a multi-part message in MIME format. >> --------------060203070300020608020002 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: quoted-printable >> >> Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >>> Laurent.LeGrandois(a)atos.net wrote: >>>> This is a multi-part message in MIME format. >>>> --------------070001090703090002060300 >>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> Hi, >>>> >>>> any news concerning integration of this patch ? >>> An alternate patch is now in git master, please test. >> Ok, we will test it : any modifications to do for 2.4.28 version ? > > Please respond once you've tested. Since there were changes to back-perl > for 2.4.29, it may not apply cleanly to a 2.4.28 build. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > ________________________________ > > > Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. > > > > -- -- 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

Re: (ITS#7220) Ldap_search_ext API blocked for around 20mints
by masarati＠aero.polimi.it 02 Apr '12

02 Apr '12

> Full_Name: Kona Jagan > Version: libldap-2.2.so.7.0.6 > OS: Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (125.17.121.249) > > > Hi All, > > I have written a ldap client application in Linux which uses > ldap_search_ext() > API for querying details of a user. I am using two threads, one for > sending ldap > search queries and other for receiving response from Ldap server which > uses > ldap_result API. > > At production i am facing a issue which breaks down to ldap_search_ext() > API got > blocked which is causing all ldap request's to timeout. Can anyone help me > to > understand about the blocking behavior of ldap_search_ext() API. I mean > when > ldap_search_ext() API gets blocked.please provide me the user cases which > can > cause this behavior. As far as I know, asynchronous LDAP calls can only block when connect(2) blocks. There's a workaround for that (which only prevents blocking) but since blocking on connect(2) indicates a more serious issue (e.g. network misconfiguration), I'd address that issue first. In any case, there is nothing so far indicating a bug in OpenLDAP software, so I'd consider this ITS closed.

1 0

(ITS#7220) Ldap_search_ext API blocked for around 20mints
by konajagan＠gmail.com 02 Apr '12

02 Apr '12

Full_Name: Kona Jagan Version: libldap-2.2.so.7.0.6 OS: Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.17.121.249) Hi All, I have written a ldap client application in Linux which uses ldap_search_ext() API for querying details of a user. I am using two threads, one for sending ldap search queries and other for receiving response from Ldap server which uses ldap_result API. At production i am facing a issue which breaks down to ldap_search_ext() API got blocked which is causing all ldap request's to timeout. Can anyone help me to understand about the blocking behavior of ldap_search_ext() API. I mean when ldap_search_ext() API gets blocked.please provide me the user cases which can cause this behavior. Thanks in advance. regards, Jagan

1 0

RE : RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 02 Apr '12

02 Apr '12

After the tests, these patchs work but not work for what we expect. According to Howard Chu, "Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules." These patchs send binary data to backends. Could you change this ? ________________________________________ De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de quanah(a)zimbra.com [quanah(a)zimbra.com] Date d'envoi : jeudi 29 mars 2012 19:26 À : openldap-its(a)openldap.org Objet : Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data --On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net wrote: > This is a multi-part message in MIME format. > --------------060203070300020608020002 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >> Laurent.LeGrandois(a)atos.net wrote: >>> This is a multi-part message in MIME format. >>> --------------070001090703090002060300 >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> Content-Transfer-Encoding: quoted-printable >>> >>> Hi, >>> >>> any news concerning integration of this patch ? >> An alternate patch is now in git master, please test. > Ok, we will test it : any modifications to do for 2.4.28 version ? Please respond once you've tested. Since there were changes to back-perl for 2.4.29, it may not apply cleanly to a 2.4.28 build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

1 0

(ITS#7219) back-mdb crash when used as accesslog
by quanah＠OpenLDAP.org 30 Mar '12

30 Mar '12

Full_Name: Quanah Gibson-Mount Version: HEAD 3/30/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) 4f764244 => access_allowed: search access to "reqStart=20120330232137.000001Z,cn=accesslog" "reqStart" requested 4f764244 <= root access granted 4f764244 => access_allowed: search access granted by manage(=mwrscxd) 4f764244 <= test_filter 6 4f764244 send_ldap_result: conn=-1 op=0 p=0 4f764244 send_ldap_result: err=0 matched="" text="" 4f764244 ==> mdb_delete: reqStart=20120330215514.000205Z,cn=accesslog 4f764244 mdb_dn2entry("cn=accesslog") 4f764244 => mdb_dn2id("cn=accesslog") 4f764244 <= mdb_dn2id: got id=0x1 4f764244 => mdb_entry_decode: 4f764244 <= mdb_entry_decode 4f764244 mdb_dn2entry("reqStart=20120330215514.000205Z,cn=accesslog") 4f764244 => mdb_dn2id("reqStart=20120330215514.000205Z,cn=accesslog") 4f764244 <= mdb_dn2id: got id=0x12d 4f764244 => mdb_entry_decode: 4f764244 <= mdb_entry_decode 4f764244 => access_allowed: delete access to "cn=accesslog" "children" requested 4f764244 <= root access granted 4f764244 => access_allowed: delete access granted by manage(=mwrscxd) 4f764244 => access_allowed: delete access to "reqStart=20120330215514.000205Z,cn=accesslog" "entry" requested 4f764244 <= root access granted 4f764244 => access_allowed: delete access granted by manage(=mwrscxd) 4f764244 => mdb_dn2id_delete 0x12d slapd: ./../../../libraries/libmdb/mdb.c:5136: mdb_node_move: Assertion `!((long)srcnode&1)' failed. Thread 6 (Thread 0x7fd7d82b6700 (LWP 32051)): #0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550, mutex=0x7d4528) at thr_posix.c:277 No locals. #2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:675 pool = 0x7d4520 task = 0x0 work_list = 0x7d45b8 ctx = {ltu_id = 140565021419264, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x934f10, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x7fffda4bc010, ltk_data = 0x934f50, ltk_free = 0x7ffff13fc523 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>, {ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 448 hash = 3457894848 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 0x7fd7d8ab7700 (LWP 32050)): #0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550, mutex=0x7d4528) at thr_posix.c:277 No locals. #2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:675 pool = 0x7d4520 task = 0x0 work_list = 0x7d45b8 ctx = {ltu_id = 140565029811968, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>, {ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 336 hash = 1932182864 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 0x7fd7d92b8700 (LWP 32049)): #0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550, mutex=0x7d4528) at thr_posix.c:277 No locals. #2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:675 pool = 0x7d4520 task = 0x0 work_list = 0x7d45b8 ctx = {ltu_id = 140565038204672, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>, {ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 545 hash = 1836313121 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 0x7fd7d9ab9700 (LWP 32048)): #0 0x00007ffff6372a75 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007ffff63765c0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00007ffff140aedc in mdb_node_move (csrc=0x7fd7d9ab7890, cdst=0x7fd7d9ab7b30) at ./../../../libraries/libmdb/mdb.c:5136 rc = 0 srcnode = 0x661d8b9 key = {mv_size = 44, mv_data = 0x7fffda4bc0d0} data = {mv_size = 1, mv_data = 0x817c60} srcpg = 140737240913598 flags = 0 __PRETTY_FUNCTION__ = "mdb_node_move" #4 0x00007ffff140c8e7 in mdb_rebalance (mc=0x7fd7d9ab7b30) at ./../../../libraries/libmdb/mdb.c:5537 node = 0x661a502 rc = 0 ptop = 1 mn = {mc_next = 0x100000000, mc_orig = 0x700000008, mc_xcursor = 0x0, mc_txn = 0x6613300, mc_dbi = 4, mc_db = 0x934d10, mc_dbx = 0x934d40, mc_dbflag = 0x800000008 <Address 0x800000008 out of bounds>, mc_snum = 3, mc_top = 2, mc_flags = 5, mc_pg = {0x6619030, 0x661a040, 0x661d070, 0x7fd7d9ab7920, 0x7ffff140fb9c, 0x7fd7d9ab7af0, 0x7fffda4bc0d0, 0x7fd7d9ab7b80, 0x400000004, 0x7fd7d9ab7b80, 0x7ffff1401865, 0x1d9ab99c0, 0x934a00, 0x78, 0x7fd7d9ab7bd0, 0x6613328, 0x84, 0x1, 0x1, 0x7fd7d9ab79b0, 0x1f14056be, 0x934d40, 0x7fd7d9ab7bd0, 0x6614ff0, 0x6614ff0, 0x6614ff0, 0x6613300, 0x7fd7d9ab7bb0, 0x7ffff1405cdf, 0x8, 0x1da52fff0, 0x661c8b8}, mc_ki = {1, 12, 30, 0, 20464, 1633, 0, 0, 49142, 1633, 0, 0, 49224, 1633, 0, 0, 48240, 1633, 0, 0, 984, 0, 0, 0, 18409, 63036, 32767, 0, 4, 0, 23, 0}} __PRETTY_FUNCTION__ = "mdb_rebalance" #5 0x00007ffff140bf61 in mdb_page_merge (csrc=0x7fd7d9ab7b30, cdst=0x934b88) at ./../../../libraries/libmdb/mdb.c:5366 rc = 0 i = 12 j = 24 srcnode = 0x7febda5e4c28 key = {mv_size = 74, mv_data = 0x7febda5e4c30} data = {mv_size = 0, mv_data = 0x7febda5e4c7a} nkeys = 12 __PRETTY_FUNCTION__ = "mdb_page_merge" #6 0x00007ffff140c938 in mdb_rebalance (mc=0x934b88) at ./../../../libraries/libmdb/mdb.c:5541 node = 0x661bff6 rc = 0 ptop = 2 mn = {mc_next = 0x661c060, mc_orig = 0x7ffff140195a, mc_xcursor = 0x0, mc_txn = 0x6613300, mc_dbi = 4, mc_db = 0x934d10, mc_dbx = 0x934d40, mc_dbflag = 0x6613328 "x\372\317", mc_snum = 3, mc_top = 2, mc_flags = 5, mc_pg = {0x6619030, 0x661a040, 0x661b050, 0x7febda5e4000, 0x300000000, 0x6613300, 0x6613300, 0x7fd7d9ab7d70, 0x7ffff1407bc7, 0x817c60, 0x934b88, 0x6618020, 0x0, 0x0, 0x6613300, 0x1, 0x6613398, 0x91bcb0, 0x6614f69, 0x1, 0x6614ff0, 0x7fd7d9ab7d70, 0x0, 0x0, 0x6613300, 0x1, 0x6613398, 0x91bcb0, 0x6614f69, 0x1, 0x6614ff0, 0x1}, mc_ki = {1, 13, 0, 0, 32208, 55723, 32727, 0, 53262, 1633, 0, 0, 53344, 1633, 0, 0, 52360, 1633, 0, 0, 984, 0, 0, 0, 18409, 63036, 32767, 0, 32056, 55723, 32727, 0}} __PRETTY_FUNCTION__ = "mdb_rebalance" #7 0x00007ffff140caf0 in mdb_cursor_del0 (mc=0x934b88, leaf=0x661d00e) at ./../../../libraries/libmdb/mdb.c:5569 rc = 0 #8 0x00007ffff1409637 in mdb_cursor_del (mc=0x934b88, flags=0) at ./../../../libraries/libmdb/mdb.c:4524 leaf = 0x661d00e rc = 0 #9 0x00007ffff14094f8 in mdb_cursor_del (mc=0x934a00, flags=0) at ./../../../libraries/libmdb/mdb.c:4497 leaf = 0x6618f7c rc = 0 #10 0x00007ffff13f9c30 in mdb_dn2id_delete (op=0x7fd7d9ab8460, mc=0x934a00, id=301) at dn2id.c:220 rc = 0 #11 0x00007ffff13e938c in mdb_delete (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0) at delete.c:336 mdb = 0x7ffff7e2c010 pdn = {bv_len = 12, bv_val = 0x937500 "cn=accesslog"} e = 0xeffce0 p = 0xeffb40 manageDSAit = 0 children = 0x7cfc20 entry = 0x7cf980 txn = 0x6613300 mc = 0x934a00 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7ffff7e2c010}, moi_txn = 0x6613300, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fd7d9ab7ef0 preread_ctrl = 0x0 ctrls = {0x0, 0xfffffffffffffff9, 0x7fd7d9ab7f30, 0x800000, 0x7fd7d9ab99c0, 0x4} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #12 0x00000000004d4a48 in overlay_op_walk (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0, which=op_delete, oi=0x9a3d80, on=0x0) at backover.c:671 func = 0x7ffff1617d18 rc = 32768 #13 0x00000000004d4c86 in over_op_func (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0, which=op_delete) at backover.c:723 oi = 0x9a3d80 on = 0x8bca80 be = 0x8b75f0 db = {bd_info = 0x7ffff1617cc0, bd_self = 0x8b75f0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x8bdcd0, be_nsuffix = 0x8b8390, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x8aab00 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8c4af0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8a34a0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x91bc60, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7ffff1617ac0, be_private = 0x7ffff7e2c010, be_next = {stqe_next = 0x8a7a80}} cb = {sc_next = 0x7ffff0fa1c60, sc_response = 0x4d3780 <over_back_response>, sc_cleanup = 0, sc_private = 0x9a3d80} sc = 0x823978 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #14 0x00000000004d4e6f in over_op_delete (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0) at backover.c:780 No locals. #15 0x00007ffff0d97f61 in accesslog_purge (ctx=0x7fd7d9ab8b70, arg=0x8c4220) at accesslog.c:689 i = 0 rtask = 0x8c4220 li = 0x8c4110 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_listener = 0x501ca0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x454a15 <slap_send_ldap_result>, c_send_search_entry = 0x45571d <slap_send_search_entry>, c_send_search_reference = 0x457c43 <slap_send_search_reference>, c_send_ldap_extended = 0x45527c <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4554fa <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fd7d9ab85d0, o_tag = 74, o_time = 1333150209, o_tincr = 3, o_bd = 0x7fd7d9ab80e0, o_req_dn = {bv_len = 44, bv_val = 0x926990 "reqStart=20120330215514.000205Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0x9374e0 "reqStart=20120330215514.000205Z,cn=accesslog"}, o_request = { oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rb_ssf = 3651896336, rb_mech = {bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = { rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rs_nnewrdn = {bv_len = 140565046592528, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0xeffa98, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x75cd60, rs_filter = 0x7fd7d9ab8410, rs_filterstr = {bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = { bv_len = 7720288, bv_val = 0x7fd7d9ab8410 "\246"}, rs_new = {bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7fd7d9ab8718, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x8aab00 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x8c4af0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0xeffa98, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fd7d9ab8ae0 "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177"}, o_private = 0x0, o_extra = {slh_first = 0x7fd7d9ab7ef0}, o_next = { stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7fd7d9ab8820, oh_msgid = 0, oh_protocol = 0, oh_tid = 140565046597376, oh_threadctx = 0x7fd7d9ab8b70, oh_tmpmemctx = 0x932e70, oh_tmpmfuncs = 0x75d320, oh_counters = 0x7607a0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7fd7d9ab8460 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x7ffff0d9787e <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7fd7d9ab8380} f = {f_choice = 166, f_un = {f_un_result = -643070992, f_un_desc = 0x7fd7d9ab83f0, f_un_ava = 0x7fd7d9ab83f0, f_un_ssa = 0x7fd7d9ab83f0, f_un_mra = 0x7fd7d9ab83f0, f_un_complex = 0x7fd7d9ab83f0}, f_next = 0x0} ava = {aa_desc = 0x825a60, aa_value = {bv_len = 15, bv_val = 0x7fd7d9ab8b20 "20120330232509Z"}} pd = {slots = 699800, used = 699702, dn = 0x7fd7d43d0010, ndn = 0x7fd7d32eb010, csn = {bv_len = 40, bv_val = 0x7fd7d9ab8ae0 "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177"}} timebuf = "20120330232509Z\000\300\231\253\331\327\177" csnbuf = "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177", '\000' <repeats 11 times>"\227, \253\331\327\177\000" old = 1333149909 __PRETTY_FUNCTION__ = "accesslog_purge" #16 0x00007ffff7b8ccc9 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at tpool.c:688 pool = 0x7d4520 task = 0x9267e0 work_list = 0x7d45b8 ctx = {ltu_id = 140565046597376, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x932e70, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x7fffda4bc010, ltk_data = 0x933110, ltk_free = 0x7ffff13fc523 <mdb_reader_free>}, {ltk_key = 0x7ffff13f23c4, ltk_data = 0x7fd7d54b4010, ltk_free = 0x7ffff13f23a1 <search_stack_free>}, { ltk_key = 0x7ffff13efda9, ltk_data = 0x7fd7d74b5010, ltk_free = 0x7ffff13efd61 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, { ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 433 hash = 310601137 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #18 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #19 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7fd7da2ba700 (LWP 32047)): #0 0x00007ffff6425d03 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x0000000000439597 in slapd_daemon_task (ptr=0x7fffffffe3bc) at daemon.c:2539 ns = 1 at = 0 nfds = 2 revents = 0x7ffff4b31010 tvp = 0x7fd7da2b7dc0 cat = {tv_sec = 1333150509, tv_usec = 0} i = 1 nwriters = 0 now = 1333150209 tv = {tv_sec = 300, tv_usec = 0} tdelta = 1 rtask = 0x8ab9c0 l = 1 last_idle_check = 1333150209 ebadf = 0 tid = 0 #2 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007ffff642570d in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ffff7fef700 (LWP 32046)): #0 0x00007ffff66ca03d in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007ffff7b8e1ff in ldap_pvt_thread_join (thread=140565054990080, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043a7a9 in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 listener_tid = 0x926840 #3 0x0000000000416d4f in main (argc=11, argv=0x7fffffffe5c8) at main.c:1012 i = 11 no_detach = 1 rc = 0 urls = 0x7b10b0 "ldapi:///" username = 0x7b1090 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {3817984, 0} g_argc = 11 g_argv = 0x7fffffffe5c8 configfile = 0x0 configdir = 0x7b10d0 "/opt/zimbra/data/ldap/config" serverName = 0x7fffffffe871 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9828 "" l = 140737488348318 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by quanah＠zimbra.com 29 Mar '12

29 Mar '12

--On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net wrote: > This is a multi-part message in MIME format. > --------------060203070300020608020002 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >> Laurent.LeGrandois(a)atos.net wrote: >>> This is a multi-part message in MIME format. >>> --------------070001090703090002060300 >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> Content-Transfer-Encoding: quoted-printable >>> >>> Hi, >>> >>> any news concerning integration of this patch ? >> An alternate patch is now in git master, please test. > Ok, we will test it : any modifications to do for 2.4.28 version ? Please respond once you've tested. Since there were changes to back-perl for 2.4.29, it may not apply cleanly to a 2.4.28 build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 29 Mar '12

29 Mar '12

Ondrej Kuznik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: >> ondrej.kuznik(a)acision.com wrote: >>> Full_Name: Ondrej Kuznik >>> Version: HEAD >>> OS: Linux >>> >> I have pushed patches 1-3 to git master. patch 4 seems to require additional work. > > I have reworked the remaining patches according to your suggestions, the > resulting patchset is at: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… Committed to master, thanks for the patches. > > The attached file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Acision. Acision has not assigned rights > and/or interest in this work to any party. I, Ondrej Kuznik am > authorized by Acision, my employer, to release this work under the > following terms. > > The attached modifications to OpenLDAP Software are subject to the > following notice: > Copyright 2012 Acision > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > - -- > Ondrej Kuznik > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk90XwAACgkQ9GWxeeH+cXuruQCfenFjCDLAbx+kk/jzpoogGGu5 > YLoAn1SwLfVvCZtl1SHEQsuSyi+bAThP > =8OdU > -----END PGP SIGNATURE----- > > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding. > > > -- -- 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

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net 29 Mar '12

29 Mar '12

This is a multi-part message in MIME format. --------------060203070300020608020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : > Laurent.LeGrandois(a)atos.net wrote: >> This is a multi-part message in MIME format. >> --------------070001090703090002060300 >> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> Content-Transfer-Encoding: quoted-printable >> >> Hi, >> >> any news concerning integration of this patch ? > An alternate patch is now in git master, please test. Ok, we will test it : any modifications to do for 2.4.28 version ? Thanks >> Thanks >> >> Laurent Le Grandois >> >> >> Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =3DE9crit : >>> Now the new patch encode the binary data to base64 by using slap_ad_i= s_=3D >> binary to check if it's binary data, and using lutil_b64_ntop for the = enc=3D >> ode. > --=20 Cordialement, *Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>= * Architecte Open Source Campus AtoS - River Ouest Pacific 3 Sud 8 +33 (0) 1 73 26 16 32 +33 (0) 6 70 01 25 61 80, Quai Voltaire 95877 Bezons Cedex Signature IOC <http://www.atos.net> --------------060203070300020608020002 Content-Type: multipart/related; boundary="------------050102040904060500010807" --------------050102040904060500010807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Le 29/03/2012 15:14, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit : <blockquote cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org" type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:Laurent.LeGrandois@atos.net">Laurent.LeGrandois(a)atos.net</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">This is a multi-part message in MIME format. --------------070001090703090002060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, any news concerning integration of this patch ? </pre> </blockquote> <pre wrap=""> An alternate patch is now in git master, please test.</pre> </blockquote> Ok, we will test it : any modifications to do for 2.4.28 version ? <br> Thanks<br> <blockquote cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> Thanks Laurent Le Grandois Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a =E9crit : </pre> <blockquote type="cite"> <pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_= </pre> </blockquote> <pre wrap="">binary to check if it's binary data, and using lutil_b64_ntop for the enc= ode. </pre> <blockquote type="cite"> <pre wrap=""> </pre> </blockquote> </blockquote> <pre wrap=""> </pre> </blockquote> <br> <br> <div class="moz-signature">-- <br> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-signature"><br> <font face="CMU Sans Serif"> Cordialement,<br> <img src="cid:part1.08050501.09040401@atos.net" border="0"><br> <br> <b><a href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent Le Grandois</a></b><br> <font style="font-size: 8pt;"> <br> Architecte Open Source<br> <br> Campus AtoS - River Ouest<br> Pacific 3 Sud 8<br> +33 (0) 1 73 26 16 32<br> +33 (0) 6 70 01 25 61<br> 80, Quai Voltaire 95877 Bezons Cedex<br> </font> </font> <a href="http://www.atos.net"> <img src="cid:part3.07070802.03040503@atos.net" alt="Signature IOC" border="0"></a> </div> </div> </body> </html> --------------050102040904060500010807 Content-Type: image/gif; name="blue_strip.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.08050501.09040401(a)atos.net> Content-Disposition: inline; filename="blue_strip.gif" R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7 --------------050102040904060500010807 Content-Type: image/gif; name="atos_logo_small.gif" Content-Transfer-Encoding: base64 Content-ID: <part3.07070802.03040503(a)atos.net> Content-Disposition: inline; filename="atos_logo_small.gif" R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P 4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7 fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6 rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11 xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2 NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD 3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq 4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw qBchAAA7 --------------050102040904060500010807-- --------------060203070300020608020002--

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 29 Mar '12

29 Mar '12

Laurent.LeGrandois(a)atos.net wrote: > This is a multi-part message in MIME format. > --------------070001090703090002060300 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: quoted-printable > > Hi, > > any news concerning integration of this patch ? An alternate patch is now in git master, please test. > > Thanks > > Laurent Le Grandois > > > Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit : >> Now the new patch encode the binary data to base64 by using slap_ad_is_= > binary to check if it's binary data, and using lutil_b64_ntop for the enc= > ode. >> -- -- 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

Re: (ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com 29 Mar '12

29 Mar '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2012 01:30 PM, hyc(a)symas.com wrote: > ondrej.kuznik(a)acision.com wrote: >> Full_Name: Ondrej Kuznik >> Version: HEAD >> OS: Linux >> > I have pushed patches 1-3 to git master. patch 4 seems to require additional work. I have reworked the remaining patches according to your suggestions, the resulting patchset is at: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitoring… The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk90XwAACgkQ9GWxeeH+cXuruQCfenFjCDLAbx+kk/jzpoogGGu5 YLoAn1SwLfVvCZtl1SHEQsuSyi+bAThP =8OdU -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net 29 Mar '12

29 Mar '12

This is a multi-part message in MIME format. --------------070001090703090002060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, any news concerning integration of this patch ? Thanks Laurent Le Grandois Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit : > Now the new patch encode the binary data to base64 by using slap_ad_is_= binary to check if it's binary data, and using lutil_b64_ntop for the enc= ode. > > > *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11= -25 19:52:29.000000000 +0100 > --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 += 0100 > *************** > *** 16,21 **** > --- 16,22 ---- > */ > > #include "perl_back.h" > + #include "lutil.h" > > int > perl_back_modify( > *************** > *** 26,31 **** > --- 27,33 ---- > Modifications *modlist =3D op->orm_modlist; > int count; > int i; > + struct berval b64_data; > > PERL_SET_CONTEXT( PERL_INTERPRETER ); > ldap_pvt_thread_mutex_lock(&perl_interpreter_mutex ); > *************** > *** 61,67 **** > mods->sm_values !=3D NULL&& mods->sm_= values[i].bv_val !=3D NULL; > i++ ) > { > ! XPUSHs(sv_2mortal(newSVpv( mods->sm_val= ues[i].bv_val, 0 ))); > } > > /* Fix delete attrib without value. */ > --- 63,80 ---- > mods->sm_values !=3D NULL&& mods->sm_= values[i].bv_val !=3D NULL; > i++ ) > { > ! if ( slap_ad_is_binary(mods->sm_desc) )= { > ! b64_data.bv_len =3D LUTIL_BASE6= 4_ENCODE_LEN(mods->sm_values[i].bv_len) + 1; > ! b64_data.bv_val =3D ber_memallo= c( b64_data.bv_len + 1 ); > ! b64_data.bv_len =3D lutil_b64_n= top( > ! (unsigned char = *) mods->sm_values[i].bv_val, > ! mods->sm_values= [i].bv_len, > ! b64_data.bv_val= , b64_data.bv_len ); > ! XPUSHs(sv_2mortal(newSVpv( b64_= data.bv_val, 0 ))); > ! ber_memfree( b64_data.bv_val ); > ! } else { > ! XPUSHs(sv_2mortal(newSVpv( mods= ->sm_values[i].bv_val, 0 ))); > ! } > } > > /* Fix delete attrib without value. */ > > > *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11= -25 19:52:29.000000000 +0100 > --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 += 0100 > *************** > *** 37,42 **** > --- 37,43 ---- > > #include "slap.h" > #include "shell.h" > + #include "lutil.h" > > int > shell_back_modify( > *************** > *** 50,55 **** > --- 51,57 ---- > Entry e; > FILE *rfp, *wfp; > int i; > + struct berval b64_data; > > if ( si->si_modify =3D=3D NULL ) { > send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, > *************** > *** 105,112 **** > > if( mod->sm_values !=3D NULL ) { > for ( i =3D 0; mod->sm_values[i].bv_val !=3D N= ULL; i++ ) { > ! fprintf( wfp, "%s: %s\n", mod->sm_desc-= >ad_cname.bv_val, > ! mod->sm_values[i].bv_val /* bin= ary! */ ); > } > } > > --- 107,126 ---- > > if( mod->sm_values !=3D NULL ) { > for ( i =3D 0; mod->sm_values[i].bv_val !=3D N= ULL; i++ ) { > ! if ( slap_ad_is_binary(mod->sm_desc) ) = { > ! b64_data.bv_len =3D LUTIL_BASE6= 4_ENCODE_LEN(mod->sm_values[i].bv_len) + 1; > ! b64_data.bv_val =3D ber_memallo= c( b64_data.bv_len + 1 ); > ! b64_data.bv_len =3D lutil_b64_n= top( > ! (unsigned char = *) mod->sm_values[i].bv_val, > ! mod->sm_values[= i].bv_len, > ! b64_data.bv_val= , b64_data.bv_len ); > ! fprintf( wfp, "%s: %s\n", mod->= sm_desc->ad_cname.bv_val, > ! b64_data.bv_val ); > ! ber_memfree( b64_data.bv_val ); > ! } else { > ! fprintf( wfp, "%s: %s\n", mod->= sm_desc->ad_cname.bv_val, > ! mod->sm_values[i].bv_va= l ); > ! } > } > } > > > ________________________________________ > De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces@OpenLDAP= .org] de la part de hyc(a)symas.com [hyc(a)symas.com] > Date d'envoi : jeudi 2 f=E9vrier 2012 21:44 > =C0 : openldap-its(a)openldap.org > Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data > > llg(a)portaildulibre.fr wrote: >> Le 02/02/2012 20:32, hyc(a)symas.com a =E9crit : >>> jiashun.qian(a)atos.net wrote: >>>> Full_Name: Jiashun QIAN >>>> Version: 2.4.28 >>>> OS: CentOS 6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (85.115.60.180) >>>> >>>> >>>> The backend shell and the backend perl can't handle some binary data= . >>>> >>>> This occurs only with MODIFY because when ADD the binary data is enc= oded in >>>> base64 but not MODIFY. >>>> >>>> The binary data is truncated when if it contains \0. In fact, data i= s stored in >>>> a linked list of char * and treated as characters. >>>> >>>> --- >>>> servers/slapd/back-perl/modify.c >>>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); >>>> --- >>>> >>>> The type of mods->sm_values[i].bv_val is char*. >>>> >>>> To handle the binary data, for back-perl, just change another functi= on mXPUSHp, >>>> which we can put the exacte length of mod->sm_values[i].bv_val as pa= rameter, >>>> it's mod->sm_values[i].bv_len. So it will push the total data. >>> That is obviously the wrong approach. Since these backends communicat= e using >>> LDIF, binary values should be base64 encoded according to the LDIF ru= les. >> The input LDIF file for ldap_modify contains base64 encoded >> usercertificate, but back-perl receives binary data. >> This behaviour only occured with modification action : with add action= , >> certificate is received base64 encoded. > Yes, I already understood that. You're still not understanding what I s= aid. > Your patch should do the appropriate checks for binary data and do the = proper > base64 encoding for the modify values that back-perl (or back-shell) se= nds to > the perl module (or shell script). > > This has nothing to do with the input LDIF file, this is about how slap= d > transmits internal data from a backend to the external perl or shell sc= ripts. > >>> Thanks for the patch, but we can't merge it since the provided soluti= on is wrong. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > ________________________________ > > > Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0= l'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9= g=E9 par le secret professionnel. Si vous recevez ce message par erreur, = merci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'= int=E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la res= ponsabilit=E9 du groupe Atos ne pourra =EAtre engag=E9e quant au contenu = de ce message. Bien que les meilleurs efforts soient faits pour maintenir= cette transmission exempte de tout virus, l'exp=E9diteur ne donne aucune= garantie =E0 cet =E9gard et sa responsabilit=E9 ne saurait =EAtre engag=E9= e pour tout dommage r=E9sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended so= lely for the addressee; it may also be privileged. If you receive this e-= mail in error, please notify the sender immediately and destroy it. As it= s integrity cannot be secured on the Internet, the Atos group liability c= annot be triggered for the message content. Although the sender endeavors= to maintain a computer virus-free network, the sender does not warrant t= hat this transmission is virus-free and will not be liable for any damage= s resulting from any virus transmitted. > > --=20 Cordialement, *Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>= * Architecte Open Source Campus AtoS - River Ouest Pacific 3 Sud 8 +33 (0) 1 73 26 16 32 +33 (0) 6 70 01 25 61 80, Quai Voltaire 95877 Bezons Cedex Signature IOC <http://www.atos.net> --------------070001090703090002060300 Content-Type: multipart/related; boundary="------------050007050004070007020800" --------------050007050004070007020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi,<br> <br>   any news concerning integration of this patch ? <br> <br> Thanks<br> <br> Laurent Le Grandois<br> <br> <br> Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a écrit : <blockquote cite="mid:201202061723.q16HNLgD077070@boole.openldap.org" type="cite"> <pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_binary to check if it's binary data, and using lutil_b64_ntop for the encode. *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +0100 *************** *** 16,21 **** --- 16,22 ---- */ #include "perl_back.h" + #include "lutil.h" int perl_back_modify( *************** *** 26,31 **** --- 27,33 ---- Modifications *modlist = op->orm_modlist; int count; int i; + struct berval b64_data; PERL_SET_CONTEXT( PERL_INTERPRETER ); ldap_pvt_thread_mutex_lock( &perl_interpreter_mutex ); *************** *** 61,67 **** mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); } /* Fix delete attrib without value. */ --- 63,80 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mods->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mods->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mods->sm_values[i].bv_val, ! mods->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! XPUSHs(sv_2mortal(newSVpv( b64_data.bv_val, 0 ))); ! ber_memfree( b64_data.bv_val ); ! } else { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); ! } } /* Fix delete attrib without value. */ *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +0100 *************** *** 37,42 **** --- 37,43 ---- #include "slap.h" #include "shell.h" + #include "lutil.h" int shell_back_modify( *************** *** 50,55 **** --- 51,57 ---- Entry e; FILE *rfp, *wfp; int i; + struct berval b64_data; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, *************** *** 105,112 **** if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val /* binary! */ ); } } --- 107,126 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! if ( slap_ad_is_binary(mod->sm_desc) ) { ! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mod->sm_values[i].bv_len) + 1; ! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 ); ! b64_data.bv_len = lutil_b64_ntop( ! (unsigned char *) mod->sm_values[i].bv_val, ! mod->sm_values[i].bv_len, ! b64_data.bv_val, b64_data.bv_len ); ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! b64_data.bv_val ); ! ber_memfree( b64_data.bv_val ); ! } else { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val ); ! } } } ________________________________________ De : <a class="moz-txt-link-abbreviated" href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces(a)OpenLDAP.org</a> [<a class="moz-txt-link-abbreviated" href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces(a)OpenLDAP.org</a>] de la part de <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> [<a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a>] Date d'envoi : jeudi 2 février 2012 21:44 À : <a class="moz-txt-link-abbreviated" href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data <a class="moz-txt-link-abbreviated" href="mailto:llg@portaildulibre.fr">llg(a)portaildulibre.fr</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Le 02/02/2012 20:32, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit : </pre> <blockquote type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Full_Name: Jiashun QIAN Version: 2.4.28 OS: CentOS 6 URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (85.115.60.180) The backend shell and the backend perl can't handle some binary data. This occurs only with MODIFY because when ADD the binary data is encoded in base64 but not MODIFY. The binary data is truncated when if it contains \0. In fact, data is stored in a linked list of char * and treated as characters. --- servers/slapd/back-perl/modify.c XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); --- The type of mods->sm_values[i].bv_val is char*. To handle the binary data, for back-perl, just change another function mXPUSHp, which we can put the exacte length of mod->sm_values[i].bv_val as parameter, it's mod->sm_values[i].bv_len. So it will push the total data. </pre> </blockquote> <pre wrap="">That is obviously the wrong approach. Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules. </pre> </blockquote> <pre wrap="">The input LDIF file for ldap_modify contains base64 encoded usercertificate, but back-perl receives binary data. This behaviour only occured with modification action : with add action, certificate is received base64 encoded. </pre> </blockquote> <pre wrap=""> Yes, I already understood that. You're still not understanding what I said. Your patch should do the appropriate checks for binary data and do the proper base64 encoding for the modify values that back-perl (or back-shell) sends to the perl module (or shell script). This has nothing to do with the input LDIF file, this is about how slapd transmits internal data from a backend to the external perl or shell scripts. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Thanks for the patch, but we can't merge it since the provided solution is wrong. </pre> </blockquote> </blockquote> <pre wrap=""> -- -- Howard Chu CTO, Symas Corp. <a class="moz-txt-link-freetext" href="http://www.symas.com">http://www.symas.com</a> Director, Highland Sun <a class="moz-txt-link-freetext" href="http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a> Chief Architect, OpenLDAP <a class="moz-txt-link-freetext" href="http://www.openldap.org/project/">http://www.openldap.org/project/</a> ________________________________ Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. </pre> </blockquote> <br> <div class="moz-signature">-- <br> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-signature"><br> <font face="CMU Sans Serif"> Cordialement,<br> <img src="cid:part1.08020906.06070706@atos.net" border="0"><br> <br> <b><a href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent Le Grandois</a></b><br> <font style="font-size: 8pt;"> <br> Architecte Open Source<br> <br> Campus AtoS - River Ouest<br> Pacific 3 Sud 8<br> +33 (0) 1 73 26 16 32<br> +33 (0) 6 70 01 25 61<br> 80, Quai Voltaire 95877 Bezons Cedex<br> </font> </font> <a href="http://www.atos.net"> <img src="cid:part3.07050008.03070309@atos.net" alt="Signature IOC" border="0"></a> </div> </div> </body> </html> --------------050007050004070007020800 Content-Type: image/gif; name="blue_strip.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.08020906.06070706(a)atos.net> Content-Disposition: inline; filename="blue_strip.gif" R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7 --------------050007050004070007020800 Content-Type: image/gif; name="atos_logo_small.gif" Content-Transfer-Encoding: base64 Content-ID: <part3.07050008.03070309(a)atos.net> Content-Disposition: inline; filename="atos_logo_small.gif" R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P 4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7 fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6 rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11 xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2 NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD 3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq 4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw qBchAAA7 --------------050007050004070007020800-- --------------070001090703090002060300--

1 0

Re: (ITS#7218) Not deleted in Syncrepl
by hyc＠symas.com 28 Mar '12

28 Mar '12

s_hira(a)nifty.com wrote: > Full_Name: HIRABAYASHI Satoshi > Version: v2.4.30 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (221.250.200.130) > > > I confirmed the problem that was not deleted in syncrepl of V2.4.30. Thanks for the report, fixed now in git master. > > The provider operates it in "syncprov-sessionlog 100". > After I delete 150 in a provider, and going syncrepl > Only 100 cases are deleted in the consumer side. > > After examining it, the following parts seem to have a problem. > > servers/slapd/overlays/syncprov.c:2638 > if ( sl->sl_num> 0 ) { > int i; > for ( i=0; i<sl->sl_numcsns; i++ ) { > /* SID not present == new enough */ > if ( minsid< sl->sl_sids[i] ) { > do_play = 1; > break; > } > /* SID present and new enough */ > if ( minsid == sl->sl_sids[i] > && ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) { > do_play = 1; > break; > } > } > /* SID not present == new enough */ > if ( i == sl->sl_numcsns ) > do_play = 1; > } > if ( do_play ) { > do_present = 0; > /* mutex is unlocked in playlog */ > syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); > } else { > ldap_pvt_thread_mutex_unlock(&sl->sl_mutex ); > } > > Then, it corrected as follows. > === > - if ( minsid == sl->sl_sids[i] > -&& ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) { > + if ( minsid == sl->sl_sids[i] ) { > + if ( ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) { > do_play = 1; > + } > break; > } > > Is this correction wrong? > > > HIRABAYASHI Satoshi > s_hira(a)nifty.com > > -- -- 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#7218) Not deleted in Syncrepl
by s_hira＠nifty.com 28 Mar '12

28 Mar '12

Full_Name: HIRABAYASHI Satoshi Version: v2.4.30 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (221.250.200.130) I confirmed the problem that was not deleted in syncrepl of V2.4.30. The provider operates it in "syncprov-sessionlog 100". After I delete 150 in a provider, and going syncrepl Only 100 cases are deleted in the consumer side. After examining it, the following parts seem to have a problem. servers/slapd/overlays/syncprov.c:2638 if ( sl->sl_num > 0 ) { int i; for ( i=0; i<sl->sl_numcsns; i++ ) { /* SID not present == new enough */ if ( minsid < sl->sl_sids[i] ) { do_play = 1; break; } /* SID present and new enough */ if ( minsid == sl->sl_sids[i] && ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) { do_play = 1; break; } } /* SID not present == new enough */ if ( i == sl->sl_numcsns ) do_play = 1; } if ( do_play ) { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); } else { ldap_pvt_thread_mutex_unlock( &sl->sl_mutex ); } Then, it corrected as follows. === - if ( minsid == sl->sl_sids[i] - && ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) { + if ( minsid == sl->sl_sids[i] ) { + if ( ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) { do_play = 1; + } break; } Is this correction wrong? HIRABAYASHI Satoshi s_hira(a)nifty.com

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com 27 Mar '12

27 Mar '12

ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitoring… > Submission from: (NULL) (62.168.56.1) > > > I have prepared some patches to back-ldap (and one to back-monitor) that expose > operation and connection monitoring information from a running back-ldap > database and I would like to see this or similar functionality included in the > OpenLDAP codebase. > > The url above contains a patchset against HEAD for review. > > The following things are yet to be resolved: > - there is no monitoring of completed operations yet, only operations initiated > against the remote database(s). > - the binds performed by the ldap_back_default_rebind function are not counted > - slapo-chain has not been tested yet > - test suite integration: back-ldap looks excluded from the test suite > - better connection handling (connections should have stable identifiers) I have pushed patches 1-3 to git master. patch 4 seems to require additional work. -- -- 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

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by hyc＠symas.com 27 Mar '12

27 Mar '12

Ondrej Kuznik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/12/2012 12:27 PM, hyc(a)symas.com wrote: >> This ITS still appears to me to be invalid. bconfig treats all siblings *of >> the same type* as a single ordering. Your demonstration code is claiming your >> entries are all of the same type, even though they aren't. I.e., all entries >> in cn=config of a given type have only one distinguished naming attribute. You >> have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config >> doesn't distinguish them in its sort order. > > I tried implementing a check for Cft_Misc that considers only siblings > of the same distinguished naming attribute: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20120309-ITS-6987.patch I've committed a cleaned up version of this patch to git master. Thanks for the patch. > > During an IRC conversation in January you suggested not renumbering > Cft_Misc entries at all, like the patch below. Such a change might > however affect other overlays since captive backends seem to be regarded > as Cft_Misc entries too, based on my tests with it: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20120309-ITS-6987-no-renumber… Decided we don't know enough about how Cft_misc entries will be used in the future to take this approach. > > The attached file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Acision. Acision has not assigned rights > and/or interest in this work to any party. I, Ondrej Kuznik am > authorized by Acision, my employer, to release this work under the > following terms. > > The attached modifications to OpenLDAP Software are subject to the > following notice: > Copyright 2012 Acision > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > - -- > Ondrej Kuznik > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9aHu0ACgkQ9GWxeeH+cXvpGgCeN5iMhB6iyq3MjFJVx45AWmX+ > uykAnjidKeewlH1EhlBBr+BTFgxZNodM > =+FEP > -----END PGP SIGNATURE----- > > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding. > > > -- -- 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

Re: (ITS#7215) Configuration Bug of index_substr_if_{max, min}len
by h.b.furuseth＠usit.uio.no 26 Mar '12

26 Mar '12

On Mon, 26 Mar 2012 19:16:11 GMT, tixu(a)cs.ucsd.edu wrote: > just set the following two lines in the beginning of the slapd.conf, > > index_substr_if_maxlen 100 > index_substr_if_minlen 5 > > slapd starts without a warning and can serve requests. That's not the example you gave in last message. The error message should be more helpful: If you want minlen that big, you have to set maxlen first. Except, this can still break cn=config replication: Either setting this configuration or reverting to the old one will not work. I don't know if cn=config supports delaying this check until the entire new entry is available, and reverting if the check fails? -- Hallvard

1 0

Re: (ITS#7215) Configuration Bug of index_substr_if_{max, min}len
by tixu＠cs.ucsd.edu 26 Mar '12

26 Mar '12

--000325575576f2e15a04bc2a31c8 Content-Type: text/plain; charset=ISO-8859-1 hmmm... I have to say I can replay it every time. just set the following two lines in the beginning of the slapd.conf, index_substr_if_maxlen 100 index_substr_if_minlen 5 slapd starts without a warning and can serve requests. T On Mon, Mar 26, 2012 at 2:43 AM, Howard Chu <hyc(a)symas.com> wrote: > tixu(a)cs.ucsd.edu wrote: > >> Full_Name: Tianyin Xu >> Version: 2.4.30 >> OS: Ubuntu Linux 10.04 >> URL: ftp://ftp.openldap.org/**incoming/<ftp://ftp.openldap.org/incoming/> >> Submission from: (NULL) (128.54.167.68) >> >> >> 1. Symptom: >> >> In the main configuration file of OpenLDAP (slapd.conf), set the following >> configuration: >> >> index_substr_if_minlen 100 >> index_substr_if_maxlen 5 >> >> Then, everything is fine. The system behaves as expectation. However, if >> reverse >> the order of the two configuration line as follows: >> >> index_substr_if_maxlen 5 >> index_substr_if_minlen 100 >> >> Then, the system refused to start, with the following misleading message: >> >> Mar 25 21:29:18 tianyin-desktop slapd[12700]: >> /home/tianyin/openldap-2.4.30/**etc/openldap/slapd.conf: line 1: >> <index_substr_if_minlen> invalid value (5) >> > > Unable to reproduce this symptom. In both cases I get > > testrun/slapd.1.conf: line 31: <index_substr_if_minlen> invalid value (100) > > Closing this ITS. > > >> ------------------------------**--------------------------- >> >> 2. Root cause in terms of code snippet >> >> (1) servers/slapd/slap.h >> >> #define SLAP_INDEX_SUBSTR_IF_MINLEN_**DEFAULT 2 >> #define SLAP_INDEX_SUBSTR_IF_MAXLEN_**DEFAULT 4 >> >> (2) servers/slapd/schema_init.c >> >> unsigned int index_substr_if_minlen = SLAP_INDEX_SUBSTR_IF_MINLEN_** >> DEFAULT; >> unsigned int index_substr_if_maxlen = SLAP_INDEX_SUBSTR_IF_MAXLEN_** >> DEFAULT; >> >> (3) servers/slapd/bconfig.c >> >> case CFG_SSTR_IF_MAX: >> if (c->value_uint< index_substr_if_minlen) { >> snprintf(c->cr_msg, sizeof(c->cr_msg), "<%s> invalid value", >> c->argv[0]); >> Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, >> c->value_int); >> return(1); >> } >> index_substr_if_maxlen = c->value_uint; >> break; >> >> case CFG_SSTR_IF_MIN: >> if (c->value_uint> index_substr_if_maxlen) { >> snprintf(c->cr_msg, sizeof( c->cr_msg ), "<%s> invalid value", >> c->argv[0]); >> Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, >> c->value_int >> ); >> return(1); >> } >> index_substr_if_minlen = c->value_uint; >> break; >> >> (4) backtrace >> >> #0 config_generic (c=0x915760) at bconfig.c:1996 >> #1 0x0000000000433a00 in config_set_vals (Conf=0x8146c0, c=0x915760) at >> config.c:345 >> #2 0x0000000000433f5f in config_add_vals (Conf=0x8146c0, c=0x915760) at >> config.c:418 >> #3 0x00000000004351b3 in read_config_file (fname=0x5a0a98 >> "/home/tianyin/openldap-2.4.**30/etc/openldap/slapd.conf", depth=0, >> cf=0x0, >> cft=0x8140c0) at config.c:783 >> #4 0x000000000042846b in read_config (fname=0x0, dir=0x0) at >> bconfig.c:4213 >> #5 0x000000000041c217 in main (argc=1, argv=0x7fffffffe2f8) at main.c:792 >> >> ------------------------------**--------------------------- >> >> It's quite clear that the order matters, and this should be a bug related >> to >> configuration. >> >> Thanks, >> Tianyin >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > -- Tianyin XU, http://cseweb.ucsd.edu/~tixu/ --000325575576f2e15a04bc2a31c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hmmm... I have to say I can replay it every time.<div><br></div><div>just s= et the following two lines in the beginning of the slapd.conf,</div><div><b= r></div><div><div>index_substr_if_maxlen 100</div><div>index_substr_if_minl= en 5</div> <div><br></div><div>slapd starts without a warning and can serve requests.<= /div><div><br></div><div>T</div> <div><br></div><br><div class=3D"gmail_quote">On Mon, Mar 26, 2012 at 2:43 = AM, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" targe= t=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> <div><a href=3D"mailto:tixu@cs.ucsd.edu" target=3D"_blank">tixu(a)cs.ucsd.edu= </a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Tianyin Xu<br> Version: 2.4.30<br> OS: Ubuntu Linux 10.04<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (128.54.167.68)<br> <br> <br> 1. Symptom:<br> <br> In the main configuration file of OpenLDAP (slapd.conf), set the following<= br> configuration:<br> <br> index_substr_if_minlen 100<br> index_substr_if_maxlen 5<br> <br> Then, everything is fine. The system behaves as expectation. However, if re= verse<br> the order of the two configuration line as follows:<br> <br> index_substr_if_maxlen 5<br> index_substr_if_minlen 100<br> <br> Then, the system refused to start, with the following misleading message:<b= r> <br> Mar 25 21:29:18 tianyin-desktop slapd[12700]:<br> /home/tianyin/openldap-2.4.30/<u></u>etc/openldap/slapd.conf: line 1:<br> <index_substr_if_minlen> =A0invalid value (5)<br> </blockquote> <br></div> Unable to reproduce this symptom. In both cases I get<br> <br> testrun/slapd.1.conf: line 31: <index_substr_if_minlen> invalid value= (100)<br> <br> Closing this ITS.<div><div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> ------------------------------<u></u>---------------------------<br> <br> 2. Root cause in terms of code snippet<br> <br> (1) servers/slapd/slap.h<br> <br> #define SLAP_INDEX_SUBSTR_IF_MINLEN_<u></u>DEFAULT =A0 =A0 2<br> #define SLAP_INDEX_SUBSTR_IF_MAXLEN_<u></u>DEFAULT =A0 =A0 4<br> <br> (2) servers/slapd/schema_init.c<br> <br> unsigned int index_substr_if_minlen =3D SLAP_INDEX_SUBSTR_IF_MINLEN_<u></u>= DEFAULT;<br> unsigned int index_substr_if_maxlen =3D SLAP_INDEX_SUBSTR_IF_MAXLEN_<u></u>= DEFAULT;<br> <br> (3) servers/slapd/bconfig.c<br> <br> case CFG_SSTR_IF_MAX:<br> =A0 =A0 if (c->value_uint< =A0index_substr_if_minlen) {<br> =A0 =A0 =A0 =A0 snprintf(c->cr_msg, sizeof(c->cr_msg), "<%s&= gt; =A0invalid value",<br> c->argv[0]);<br> =A0 =A0 =A0 =A0 Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log= , c->cr_msg,<br> c->value_int);<br> =A0 =A0 =A0 =A0 return(1);<br> =A0 =A0 }<br> =A0 =A0 index_substr_if_maxlen =3D c->value_uint;<br> =A0 =A0 break;<br> <br> case CFG_SSTR_IF_MIN:<br> =A0 =A0 if (c->value_uint> =A0index_substr_if_maxlen) {<br> =A0 =A0 =A0 =A0 snprintf(c->cr_msg, sizeof( c->cr_msg ), "<%= s> =A0invalid value",<br> c->argv[0]);<br> =A0 =A0 =A0 =A0 Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log= , c->cr_msg, c->value_int<br> );<br> =A0 =A0 =A0 =A0 return(1);<br> =A0 =A0 }<br> =A0 =A0 index_substr_if_minlen =3D c->value_uint;<br> =A0 =A0 break;<br> <br> (4) backtrace<br> <br> #0 =A0config_generic (c=3D0x915760) at bconfig.c:1996<br> #1 =A00x0000000000433a00 in config_set_vals (Conf=3D0x8146c0, c=3D0x915760)= at<br> config.c:345<br> #2 =A00x0000000000433f5f in config_add_vals (Conf=3D0x8146c0, c=3D0x915760)= at<br> config.c:418<br> #3 =A00x00000000004351b3 in read_config_file (fname=3D0x5a0a98<br> "/home/tianyin/openldap-2.4.<u></u>30/etc/openldap/slapd.conf", d= epth=3D0, cf=3D0x0,<br> cft=3D0x8140c0) at config.c:783<br> #4 =A00x000000000042846b in read_config (fname=3D0x0, dir=3D0x0) at bconfig= .c:4213<br> #5 =A00x000000000041c217 in main (argc=3D1, argv=3D0x7fffffffe2f8) at main.= c:792<br> <br> ------------------------------<u></u>---------------------------<br> <br> It's quite clear that the order matters, and this should be a bug relat= ed to<br> configuration.<br> <br> Thanks,<br> Tianyin<br> <br> <br> </blockquote> <br> <br></div></div><span><font color=3D"#888888"> -- <br> =A0-- Howard Chu<br> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r><span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;= text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:no= rmal;border-collapse:separate;text-transform:none;font-size:medium;white-sp= ace:normal;font-family:'Times New Roman';word-spacing:0px"><span st= yle=3D"color:rgb(102,102,102);font-family:arial;font-size:small">Tianyin XU= ,<br> <a href=3D"http://cseweb.ucsd.edu/%7Etixu/" target=3D"_blank">http://cseweb= .ucsd.edu/~tixu/</a></span></span><br> </div> --000325575576f2e15a04bc2a31c8--

1 0

Re: (ITS#7213) back-mdb corruption with quickmode
by hyc＠symas.com 26 Mar '12

26 Mar '12

quanah(a)zimbra.com wrote: > --On Wednesday, March 21, 2012 1:41 AM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.30 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> Using quickmode with slapadd can result in a corrupt database. Fixed in git master >> > > zimbra@zqa-067:~$ /opt/zimbra/openldap/sbin/slapadd -q -F > /opt/zimbra/data/ldap/config -b '' -l /opt/zimbra/data/ldap/ldap.80 > _#################### 100.00% eta none elapsed none fast! > Closing DB... > zimbra@zqa-067:~$ ldap start > Started slapd: pid 27998 > zimbra@zqa-067:~$ ./libexec/zmslapcat /tmp > # no data for entry id=00000024 > > No issue when you don't use -q: > > /opt/zimbra/openldap/sbin/slapadd -F /opt/zimbra/data/ldap/config -b '' -l > /opt/zimbra/data/ldap/ldap.80 > _#################### 100.00% eta none elapsed none fast! > Closing DB... > zimbra@zqa-067:~$ ldap start > Started slapd: pid 30573 > zimbra@zqa-067:~$ ./libexec/zmslapcat /tmp > zimbra@zqa-067:~$ > > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- -- 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

Re: (ITS#7217) libperl-dev check is missing in configure
by hyc＠symas.com 26 Mar '12

26 Mar '12

robert.eikermann(a)rwth-aachen.de wrote: > Full_Name: Robert Eikermann > Version: 2.4.30 > OS: Ubuntu 11.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.226.168.117) > > > Hi, > "configure" checked a lot libraries in my system, but not libperl-dev the error > (/usr/bin/ld: cannot find -lperl) appears first when I was compiling openldap. > > sudo apt-get install libperl-dev helped. Not an OpenLDAP bug. 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#7217) libperl-dev check is missing in configure
by robert.eikermann＠rwth-aachen.de 26 Mar '12

26 Mar '12

Full_Name: Robert Eikermann Version: 2.4.30 OS: Ubuntu 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.226.168.117) Hi, "configure" checked a lot libraries in my system, but not libperl-dev the error (/usr/bin/ld: cannot find -lperl) appears first when I was compiling openldap. sudo apt-get install libperl-dev helped.

1 0

Re: (ITS#7207) Re-binding to a failed connection segfaults
by hyc＠symas.com 26 Mar '12

26 Mar '12

jsynacek(a)redhat.com wrote: > 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. Fixed now in git master, thanks for the report. > > 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 > > -- -- 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

Re: (ITS#7205) olcSuffix does not support modifications
by hyc＠symas.com 26 Mar '12

26 Mar '12

elecharny(a)apache.org wrote: > 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. No. The attribute is not single-valued, but individual backend implementations may only allow a single suffix. > 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. Thanks for the report, now fixed in master. > > Deleting the olcSuffix AT and injcting a new one works. > > -- -- 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

Re: (ITS#7214) Openldap contextCSN issue on seconday ldap server
by hyc＠symas.com 26 Mar '12

26 Mar '12

pawank.kamboj(a)gmail.com wrote: > Full_Name: Pawan Kumar > Version: openldap-2.3.32 > OS: CentOS release 4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (14.140.116.135) > > That release is over 5 years old and the Project stopped supporting it years ago. If you require support on this release contact your distribution provider. Otherwise, upgrade to a current release (2.4.30 is latest). > Hi, > We are using openldap-2.3.32 on CentOS release 4.5(2.6.9-89.0.25.ELsmp). > We have master-slave setup and we have two secondary ldap servers on which we > are only replicating the one of our OU. We are not able see the contextCSN on > secondary ldap servers. we are using the syncreplca(delta sync replication using > accesslog. > Below are the secondary slapd.conf replication section. > > syncrepl rid=111 provider=ldap://masterldapserver type=refreshAndPersist > retry="60 10 300 +" searchbase="ou=people,dc=example,dc=co,dc=in" > schemachecking=off bindmethod=simple binddn="cn=Manager,dc=example,dc=co,dc=in" > credentials=password logbase="cn=accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog > > And how we can monitor ldap replication in that case where we are replicating > only one OU from master ldap server? > > any quick response will be appreciated. > > > > > > > > -- -- 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

Re: (ITS#7215) Configuration Bug of index_substr_if_{max, min}len
by hyc＠symas.com 26 Mar '12

26 Mar '12

tixu(a)cs.ucsd.edu wrote: > Full_Name: Tianyin Xu > Version: 2.4.30 > OS: Ubuntu Linux 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.54.167.68) > > > 1. Symptom: > > In the main configuration file of OpenLDAP (slapd.conf), set the following > configuration: > > index_substr_if_minlen 100 > index_substr_if_maxlen 5 > > Then, everything is fine. The system behaves as expectation. However, if reverse > the order of the two configuration line as follows: > > index_substr_if_maxlen 5 > index_substr_if_minlen 100 > > Then, the system refused to start, with the following misleading message: > > Mar 25 21:29:18 tianyin-desktop slapd[12700]: > /home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf: line 1: > <index_substr_if_minlen> invalid value (5) Unable to reproduce this symptom. In both cases I get testrun/slapd.1.conf: line 31: <index_substr_if_minlen> invalid value (100) Closing this ITS. > > --------------------------------------------------------- > > 2. Root cause in terms of code snippet > > (1) servers/slapd/slap.h > > #define SLAP_INDEX_SUBSTR_IF_MINLEN_DEFAULT 2 > #define SLAP_INDEX_SUBSTR_IF_MAXLEN_DEFAULT 4 > > (2) servers/slapd/schema_init.c > > unsigned int index_substr_if_minlen = SLAP_INDEX_SUBSTR_IF_MINLEN_DEFAULT; > unsigned int index_substr_if_maxlen = SLAP_INDEX_SUBSTR_IF_MAXLEN_DEFAULT; > > (3) servers/slapd/bconfig.c > > case CFG_SSTR_IF_MAX: > if (c->value_uint< index_substr_if_minlen) { > snprintf(c->cr_msg, sizeof(c->cr_msg), "<%s> invalid value", > c->argv[0]); > Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, > c->value_int); > return(1); > } > index_substr_if_maxlen = c->value_uint; > break; > > case CFG_SSTR_IF_MIN: > if (c->value_uint> index_substr_if_maxlen) { > snprintf(c->cr_msg, sizeof( c->cr_msg ), "<%s> invalid value", > c->argv[0]); > Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, c->value_int > ); > return(1); > } > index_substr_if_minlen = c->value_uint; > break; > > (4) backtrace > > #0 config_generic (c=0x915760) at bconfig.c:1996 > #1 0x0000000000433a00 in config_set_vals (Conf=0x8146c0, c=0x915760) at > config.c:345 > #2 0x0000000000433f5f in config_add_vals (Conf=0x8146c0, c=0x915760) at > config.c:418 > #3 0x00000000004351b3 in read_config_file (fname=0x5a0a98 > "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf", depth=0, cf=0x0, > cft=0x8140c0) at config.c:783 > #4 0x000000000042846b in read_config (fname=0x0, dir=0x0) at bconfig.c:4213 > #5 0x000000000041c217 in main (argc=1, argv=0x7fffffffe2f8) at main.c:792 > > --------------------------------------------------------- > > It's quite clear that the order matters, and this should be a bug related to > configuration. > > Thanks, > Tianyin > > -- -- 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

Re: (ITS#7216) Recursive function call of "include"
by hyc＠symas.com 26 Mar '12

26 Mar '12

tixu(a)cs.ucsd.edu wrote: > Full_Name: Tianyin Xu > Version: 2.4.30 > OS: Ubuntu Linux 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.54.167.68) > > > 1. Problem > > In OpenLDAP-2.4.30, the recursive "include" directive in the configuration files > cannot be detected but only terminated by the OS. The message cannot pinpoint > the root cause (it's quite misleading). Here, the recursive "include" is > referred to the following case: > > In slapd.conf: include sub.conf > In sub.conf: include slapd.conf Don't do that. Closing this ITS. > > The message will be like: > > Mar 22 11:39:03 tianyin-desktop start_slapd[30825]: could not open config file > "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf": Too many open files > (24) > > > 2. Root Cause > > (1) The bomb point is in read_config_file() in servers/slapd/config.c > > if ( stat( fname,&s ) != 0 ) { > ldap_syslog = 1; > Debug(LDAP_DEBUG_ANY, > "could not stat config file \"%s\": %s (%d)\n", > fname, strerror(errno), errno); > ch_free( c ); > return(1); > } > > (2) The recursive call chain: notice #0, #4, and #8 > > #0 read_config_file (fname=0x94ebc8 > "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf", depth=1, cf=0x94c790, > cft=0x845de0) at config.c:704 > #1 0x00000000004124e9 in config_include (c=0x94c790) at bconfig.c:3754 > #2 0x000000000041f0cc in config_set_vals (Conf=0x8463a0, c=0x94c790) at > config.c:345 > #3 0x000000000041f62b in config_add_vals (Conf=0x8463a0, c=0x94c790) at > config.c:418 > #4 0x000000000042087f in read_config_file (fname=0x9493f0 > "/home/tianyin/openldap-2.4.30/sub.conf", depth=1, cf=0x949ad0, cft=0x845de0) at > config.c:783 > #5 0x00000000004124e9 in config_include (c=0x949ad0) at bconfig.c:3754 > #6 0x000000000041f0cc in config_set_vals (Conf=0x8463a0, c=0x949ad0) at > config.c:345 > #7 0x000000000041f62b in config_add_vals (Conf=0x8463a0, c=0x949ad0) at > config.c:418 > #8 0x000000000042087f in read_config_file (fname=0x5c5198 > "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf", depth=0, cf=0x0, > cft=0x845de0) at config.c:783 > #9 0x0000000000413c9b in read_config (fname=0x0, dir=0x0) at bconfig.c:4213 > #10 0x0000000000407fc7 in main (argc=1, argv=0x7fffffffe2f8) at main.c:792 > > > Thanks! > Tianyin > > -- -- 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#7216) Recursive function call of "include"
by tixu＠cs.ucsd.edu 26 Mar '12

26 Mar '12

Full_Name: Tianyin Xu Version: 2.4.30 OS: Ubuntu Linux 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.54.167.68) 1. Problem In OpenLDAP-2.4.30, the recursive "include" directive in the configuration files cannot be detected but only terminated by the OS. The message cannot pinpoint the root cause (it's quite misleading). Here, the recursive "include" is referred to the following case: In slapd.conf: include sub.conf In sub.conf: include slapd.conf The message will be like: Mar 22 11:39:03 tianyin-desktop start_slapd[30825]: could not open config file "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf": Too many open files (24) 2. Root Cause (1) The bomb point is in read_config_file() in servers/slapd/config.c if ( stat( fname, &s ) != 0 ) { ldap_syslog = 1; Debug(LDAP_DEBUG_ANY, "could not stat config file \"%s\": %s (%d)\n", fname, strerror(errno), errno); ch_free( c ); return(1); } (2) The recursive call chain: notice #0, #4, and #8 #0 read_config_file (fname=0x94ebc8 "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf", depth=1, cf=0x94c790, cft=0x845de0) at config.c:704 #1 0x00000000004124e9 in config_include (c=0x94c790) at bconfig.c:3754 #2 0x000000000041f0cc in config_set_vals (Conf=0x8463a0, c=0x94c790) at config.c:345 #3 0x000000000041f62b in config_add_vals (Conf=0x8463a0, c=0x94c790) at config.c:418 #4 0x000000000042087f in read_config_file (fname=0x9493f0 "/home/tianyin/openldap-2.4.30/sub.conf", depth=1, cf=0x949ad0, cft=0x845de0) at config.c:783 #5 0x00000000004124e9 in config_include (c=0x949ad0) at bconfig.c:3754 #6 0x000000000041f0cc in config_set_vals (Conf=0x8463a0, c=0x949ad0) at config.c:345 #7 0x000000000041f62b in config_add_vals (Conf=0x8463a0, c=0x949ad0) at config.c:418 #8 0x000000000042087f in read_config_file (fname=0x5c5198 "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf", depth=0, cf=0x0, cft=0x845de0) at config.c:783 #9 0x0000000000413c9b in read_config (fname=0x0, dir=0x0) at bconfig.c:4213 #10 0x0000000000407fc7 in main (argc=1, argv=0x7fffffffe2f8) at main.c:792 Thanks! Tianyin

1 0

(ITS#7215) Configuration Bug of index_substr_if_{max, min}len
by tixu＠cs.ucsd.edu 26 Mar '12

26 Mar '12

Full_Name: Tianyin Xu Version: 2.4.30 OS: Ubuntu Linux 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.54.167.68) 1. Symptom: In the main configuration file of OpenLDAP (slapd.conf), set the following configuration: index_substr_if_minlen 100 index_substr_if_maxlen 5 Then, everything is fine. The system behaves as expectation. However, if reverse the order of the two configuration line as follows: index_substr_if_maxlen 5 index_substr_if_minlen 100 Then, the system refused to start, with the following misleading message: Mar 25 21:29:18 tianyin-desktop slapd[12700]: /home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf: line 1: <index_substr_if_minlen> invalid value (5) --------------------------------------------------------- 2. Root cause in terms of code snippet (1) servers/slapd/slap.h #define SLAP_INDEX_SUBSTR_IF_MINLEN_DEFAULT 2 #define SLAP_INDEX_SUBSTR_IF_MAXLEN_DEFAULT 4 (2) servers/slapd/schema_init.c unsigned int index_substr_if_minlen = SLAP_INDEX_SUBSTR_IF_MINLEN_DEFAULT; unsigned int index_substr_if_maxlen = SLAP_INDEX_SUBSTR_IF_MAXLEN_DEFAULT; (3) servers/slapd/bconfig.c case CFG_SSTR_IF_MAX: if (c->value_uint < index_substr_if_minlen) { snprintf(c->cr_msg, sizeof(c->cr_msg), "<%s> invalid value", c->argv[0]); Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, c->value_int); return(1); } index_substr_if_maxlen = c->value_uint; break; case CFG_SSTR_IF_MIN: if (c->value_uint > index_substr_if_maxlen) { snprintf(c->cr_msg, sizeof( c->cr_msg ), "<%s> invalid value", c->argv[0]); Debug(LDAP_DEBUG_ANY, "%s: %s (%d)\n", c->log, c->cr_msg, c->value_int ); return(1); } index_substr_if_minlen = c->value_uint; break; (4) backtrace #0 config_generic (c=0x915760) at bconfig.c:1996 #1 0x0000000000433a00 in config_set_vals (Conf=0x8146c0, c=0x915760) at config.c:345 #2 0x0000000000433f5f in config_add_vals (Conf=0x8146c0, c=0x915760) at config.c:418 #3 0x00000000004351b3 in read_config_file (fname=0x5a0a98 "/home/tianyin/openldap-2.4.30/etc/openldap/slapd.conf", depth=0, cf=0x0, cft=0x8140c0) at config.c:783 #4 0x000000000042846b in read_config (fname=0x0, dir=0x0) at bconfig.c:4213 #5 0x000000000041c217 in main (argc=1, argv=0x7fffffffe2f8) at main.c:792 --------------------------------------------------------- It's quite clear that the order matters, and this should be a bug related to configuration. Thanks, Tianyin

1 0

(ITS#7214) Openldap contextCSN issue on seconday ldap server
by pawank.kamboj＠gmail.com 25 Mar '12

25 Mar '12

Full_Name: Pawan Kumar Version: openldap-2.3.32 OS: CentOS release 4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.140.116.135) Hi, We are using openldap-2.3.32 on CentOS release 4.5(2.6.9-89.0.25.ELsmp). We have master-slave setup and we have two secondary ldap servers on which we are only replicating the one of our OU. We are not able see the contextCSN on secondary ldap servers. we are using the syncreplca(delta sync replication using accesslog. Below are the secondary slapd.conf replication section. syncrepl rid=111 provider=ldap://masterldapserver type=refreshAndPersist retry="60 10 300 +" searchbase="ou=people,dc=example,dc=co,dc=in" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=example,dc=co,dc=in" credentials=password logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog And how we can monitor ldap replication in that case where we are replicating only one OU from master ldap server? any quick response will be appreciated.

1 0

Re: (ITS#7213) back-mdb corruption with quickmode
by quanah＠zimbra.com 20 Mar '12

20 Mar '12

--On Wednesday, March 21, 2012 1:41 AM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.30 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > Using quickmode with slapadd can result in a corrupt database. > zimbra@zqa-067:~$ /opt/zimbra/openldap/sbin/slapadd -q -F /opt/zimbra/data/ldap/config -b '' -l /opt/zimbra/data/ldap/ldap.80 _#################### 100.00% eta none elapsed none fast! Closing DB... zimbra@zqa-067:~$ ldap start Started slapd: pid 27998 zimbra@zqa-067:~$ ./libexec/zmslapcat /tmp # no data for entry id=00000024 No issue when you don't use -q: /opt/zimbra/openldap/sbin/slapadd -F /opt/zimbra/data/ldap/config -b '' -l /opt/zimbra/data/ldap/ldap.80 _#################### 100.00% eta none elapsed none fast! Closing DB... zimbra@zqa-067:~$ ldap start Started slapd: pid 30573 zimbra@zqa-067:~$ ./libexec/zmslapcat /tmp zimbra@zqa-067:~$ --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7213) back-mdb corruption with quickmode
by quanah＠OpenLDAP.org 20 Mar '12

20 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Using quickmode with slapadd can result in a corrupt database.

1 0

Re: (ITS#7210) back-mdb endless database growth
by quanah＠zimbra.com 20 Mar '12

20 Mar '12

--On Tuesday, March 20, 2012 2:16 PM +0000 hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.30 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.108.184.39) >>> >>> >>> If you create a script to add& delete the same 50,000 users, and then >>> re-run that script multiple times, the MDB database on disk continues >>> to grow, despite the fact that we are only adding and deleting the same >>> data repeatedly. There should be zero growth to the database. >>> >>> Instead, the data.mdb file went from 108MB in size to over 1.2GB after >>> 5-6 runs. Time to add/delete all the users went from 3 minutes 32 >>> seconds on the first run to over 90 minutes on the final run (5th or >>> 6th, I lost count). >> >> At present, MDB is working as intended. In your test a number of overflow >> pages are being used. Currently libmdb always allocates overflow pages >> from new space, because it's not smart enough to search the free list for >> contiguous pages. Can treat this ITS as an enhancement request for that >> purpose, but this is not a new issue nor is it unexpected in the current >> version of MDB. >> > Hm, I take this back. The overflow pages are not enough to account for > the difference. Still looking. If this were truly the expected behavior, it would make using back-mdb with delta-syncrepl useless, as the accesslog would simply grow without bound. ;) Even back-bdb/hdb don't do that. While the DB will never be smaller than the maximum size ever reached without reloading, it won't unnecessarily grow past that either. :P --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs