- openldap-bugs - openldap.org

Re: (ITS#5690) cn=config cannot be rootdn
by ando＠sys-net.it 09 Sep '08

09 Sep '08

quanah(a)zimbra.com wrote: > In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be > cn=config. This no longer works in OpenLDAP 2.4, but seems like it should be > valid to me. ... > cn=config is *clearly* under "" No, cn=config is *clearly* under cn=config, which comes earlier than "". As such, auth'ing as cn=config will be intercepted by back-config, hence the config error. > and changing it to "cn=config,dc=junk" works. > So it's specific to the term "cn=config". Changing it to "cn=joe" works just > fine. It also doesn't seem to care that I use "cn=config" with back-monitor... But then you don't need to set rootpw. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 09 Sep '08

09 Sep '08

mateusz.kijowski(a)gmail.com wrote: > Full_Name: Mateusz Kijowski > Version: 2.3.43 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.126.222.22) > > > In some use scenarios, it is useful if the translucent overlay does not forward > bind operation requests to the remote server when there are values for > userPassword attribute in the local database. It would be nice if this could be > enabled or disabled by a configuration option. For consistency, enabling this > behavior should also affect the PASSMOD extended operation to modify the local > value of userPassword. The local bind feature has been added to HEAD; please test. As for the passmod feature, that requires a little bit more. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be cn=config. This no longer works in OpenLDAP 2.4, but seems like it should be valid to me. Example config: include /opt/zimbra/openldap-2.4.12/etc/openldap/schema/core.schema include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/inetorgperson.schema" pidfile /opt/zimbra/openldap-2.4.12/var/run/slapd.pid argsfile /opt/zimbra/openldap-2.4.12/var/run/slapd.args modulepath /opt/zimbra/openldap-2.4.12/libexec/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la database config rootpw secret database monitor rootdn "cn=config" access to dn.children="cn=monitor" by * read database hdb suffix cn=accesslog directory /opt/zimbra/data/openldap/accesslog/db rootdn cn=accesslog index default eq index entryCSN index objectClass index reqEnd index reqResult index reqStart access to dn.subtree="cn=accesslog" by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=admins,cn=zimbra" read # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 64 5 cachesize 10000 timelimit unlimited sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database hdb suffix "" rootdn "cn=config" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /opt/zimbra/data/openldap/db # Indices to maintain index objectClass eq index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub # recommended for replication index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 20 10 syncprov-sessionlog 500 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 Slaptest fails with: line 74 (suffix "") >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> line 75 (rootdn "cn=config") >>> dnPrettyNormal: <cn=config> <<< dnPrettyNormal: <cn=config>, <cn=config> line 79 (rootpw ***) /opt/zimbra/openldap-2.4.12/etc/openldap/slapd.conf: line 79: <rootpw> can only be set when rootdn is under suffix slaptest: bad configuration file! cn=config is *clearly* under "", and changing it to "cn=config,dc=junk" works. So it's specific to the term "cn=config". Changing it to "cn=joe" works just fine. It also doesn't seem to care that I use "cn=config" with back-monitor...

1 0

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Julien Garnier wrote: > Pierangelo Masarati a écrit : >> Should now be fixed in HEAD; please test and report. >> >> p. > > I've just install head : > @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ > > Seems to be OK, I only retrieve my 2 users > What was the problem ? In your specific case (a "liberal" local filter and a strict remote filter ANDed) the original filter was not applied to the entire entry, after merging the local and remote parts. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by julien.garnier＠dr13.cnrs.fr 08 Sep '08

08 Sep '08

Hi, I'm interersted in this option to. Juju

1 0

Re: (ITS#5679) Translucent search
by julien.garnier＠dr13.cnrs.fr 08 Sep '08

08 Sep '08

This is a cryptographically signed message in MIME format. --------------ms090702020105050508040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Pierangelo Masarati a =E9crit : > Should now be fixed in HEAD; please test and report. > > p. I've just install head : @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ Seems to be OK, I only retrieve my 2 users What was the problem ? Thanks ! Julien *************************************************************************= ** ldapsearch -x -b "ou=3DPeople,dc=3Dcnrs,dc=3Dfr" =20 "(&(ou=3DMOY1300*)(corsecu=3D*))" ou corsecu # extended LDIF # # LDAPv3 # base <ou=3DPeople,dc=3Dcnrs,dc=3Dfr> with scope subtree # filter: (&(ou=3DMOY1300*)(corsecu=3D*)) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=3Dmartine.costanzo,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D= =3D CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=3Dvincent.chicot,ou=3Dcnrs,ou=3DPeople,dc=3Dcnrs,dc=3Dfr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg=3D= =3D CorSecu: MOY1300 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 --------------ms090702020105050508040500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxTCC A2kwggJRoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NTI4WhcNMTEwNDI1MDU0NTI4WjAw MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQlSTUNpNZM31NKiH++/aLeFo2lCbD/EdAsq k8Vzl0yoN+BS3qY5EbkZbUwU3x/o0XsfvqsfOqTz4MxEavsJmlRetHAfYUPmXCiwwnxCmFS/ +N2NmN2bnWIY0Vzk6qZkgTdYZqj1eiXNyn1q1E/IpPEp7hA+KdulYJ706Xj99ih8kVFa/a8y 45ub5FOWpK4DJPBoNxS7LPsZyGtfehmcCRtj2JF7BcxJMTH6GPwZ1j/Y4DdBcxmzIfLOjQly ROrlDF5iiscuxzZOPOKUcbnjU5fgFxTE8YQ9jyqL5X6xeWaNABwPR6O+Kln/eDowWrJXnjke VBbfBKm6xYvLyzlQUQIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFFd9dKaS m4hc/uQEKfTsOmcnVOD4MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTAr MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADggEBAEc8oDJIziXlPHqdm+CF/44HRs8MOif5Un3d8x7y vgBqvLt2WV6xoI4h4Y+54Z7Aog3H65z/qtiZdxb3CehCzhltPGHZ/oNHZJa74xqUXJgXeKUk V/JQw0a/z4VLRjnhU0mzbvghbOAJsA6QqsKWC2ZiWhHZaLScVt3zrJ9F8mWX3DAf4HRN+0iY U438vLKSBM6KJhb7Mn1tXk36IcskrwAnozVizkwLendcMYpKuKyu7DofQXUouGwJF+YE6u3B L72QvPko9jHauBqNWpRm2n1ETnjw2VXs7RKfy8q8no78VLT8+x7fPCBcZMx69Ytyouj+TThX KVNQ4bxYoJEggZUwggSoMIIDkKADAgECAgIOdzANBgkqhkiG9w0BAQUFADAwMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMB4XDTA3MTEwODEyMDAw NFoXDTA4MTEwNzEyMDAwNFowczELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxEDAOBgNV BAsTB01PWTEzMDAxFzAVBgNVBAMTDkp1bGllbiBHYXJuaWVyMSowKAYJKoZIhvcNAQkBFhtK dWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDnOJa63KmBNrk1iWwIoBfaNRIoB5R+4X+aCOXHD9jXaq5WUV42JEFHvgA87t6esw5U lKgjjyDa8IEW6YQX/WQ9EuHVq4zAvYFQ37bv+obvf1icCyOxDCqqozcIaP8vawVhD244p3bx nVP18QlmlS6MAoqD2NSOgdXjrqQb2uJSE+KLwGMnjjs4zb8lRt2dYp67z7SBLYTnTq04o0Yr fOtYt+rnlleDlWKdJGgNqryiHO20tKlOAUHE4ahZHjsKhEZGdJ4KCoEuDNQtyRLznRGuuH+b 2QjecVL2DmF26hNYlgM4c4TNWETGEBSgdBnlntcEQH443LN2qEx+lRA5dIr/AgMBAAGjggGH MIIBgzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAw cAYJYIZIAYb4QgENBGMWYUNlcnRpZmljYXQgQ05SUy1QbHVzLiBQb3VyIHRvdXRlIGluZm9y bWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5jbnJzLmZyL0NOUlMt UGx1cy8wHQYDVR0OBBYEFECFdlYtLkLUfoSH/7VfvQ4hYG60MFMGA1UdIwRMMEqAFFd9dKaS m4hc/uQEKfTsOmcnVOD4oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsG A1UEAxMEQ05SU4IBATAmBgNVHREEHzAdgRtKdWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIw QgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybHMuc2VydmljZXMuY25ycy5mci9DTlJTLVBs dXMvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuz1KzmYgAcfVPB1mE8GBR0Yzz/td ij3IttaeiCmpDfArhOwdolUiLV1MF/oJGDHX+yxpcHNu6wH3E6eEVoYycPwCcN5P9mTaxrTG KYXIj6RoDPIiCQpE9zjKV+c0jJr0bwBZIIJfCIpOpmcHHW+3BbtqjuboydwOqh5ICesPnMRr BA6WEEnB7pv1sp0vAoK0O7/ctJS6C/X37LsTBYcHVkKoyjGYUYdBjWUgmPs+jsArqe+QKSRA zl/3Xc83ZZ681aKApq9hrlmDYpP50E87uK+c2ul/fm4iwvJdb3WkyQaCfc4Epot5GMusb5/C j8JLmtpc7mv+DIrhbz3jbmZ0HTCCBKgwggOQoAMCAQICAg53MA0GCSqGSIb3DQEBBQUAMDAx CzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMwHhcNMDcx MTA4MTIwMDA0WhcNMDgxMTA3MTIwMDA0WjBzMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHTU9ZMTMwMDEXMBUGA1UEAxMOSnVsaWVuIEdhcm5pZXIxKjAoBgkqhkiG 9w0BCQEWG0p1bGllbi5HYXJuaWVyQGRyMTMuY25ycy5mcjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAOc4lrrcqYE2uTWJbAigF9o1EigHlH7hf5oI5ccP2NdqrlZRXjYkQUe+ ADzu3p6zDlSUqCOPINrwgRbphBf9ZD0S4dWrjMC9gVDftu/6hu9/WJwLI7EMKqqjNwho/y9r BWEPbjindvGdU/XxCWaVLowCioPY1I6B1eOupBva4lIT4ovAYyeOOzjNvyVG3Z1inrvPtIEt hOdOrTijRit861i36ueWV4OVYp0kaA2qvKIc7bS0qU4BQcThqFkeOwqERkZ0ngoKgS4M1C3J EvOdEa64f5vZCN5xUvYOYXbqE1iWAzhzhM1YRMYQFKB0GeWe1wRAfjjcs3aoTH6VEDl0iv8C AwEAAaOCAYcwggGDMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DBwBglghkgBhvhCAQ0EYxZhQ2VydGlmaWNhdCBDTlJTLVBsdXMuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMu ZnIvQ05SUy1QbHVzLzAdBgNVHQ4EFgQUQIV2Vi0uQtR+hIf/tV+9DiFgbrQwUwYDVR0jBEww SoAUV310ppKbiFz+5AQp9Ow6ZydU4PihL6QtMCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRD TlJTMQ0wCwYDVQQDEwRDTlJTggEBMCYGA1UdEQQfMB2BG0p1bGllbi5HYXJuaWVyQGRyMTMu Y25ycy5mcjBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtUGx1cy9nZXRkZXIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC7PUrOZiABx9U8HWYT wYFHRjPP+12KPci21p6IKakN8CuE7B2iVSItXUwX+gkYMdf7LGlwc27rAfcTp4RWhjJw/AJw 3k/2ZNrGtMYphciPpGgM8iIJCkT3OMpX5zSMmvRvAFkggl8Iik6mZwcdb7cFu2qO5ujJ3A6q HkgJ6w+cxGsEDpYQScHum/WynS8CgrQ7v9y0lLoL9ffsuxMFhwdWQqjKMZhRh0GNZSCY+z6O wCup75ApJEDOX/ddzzdlnrzVooCmr2GuWYNik/nQTzu4r5za6X9+biLC8l1vdaTJBoJ9zgSm i3kYy6xvn8KPwkua2lzua/4MiuFvPeNuZnQdMYICojCCAp4CAQEwNjAwMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzAgIOdzAJBgUrDgMCGgUAoIIB QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MDgxMTQz NTBaMCMGCSqGSIb3DQEJBDEWBBT/z7sYiEHm4wcm/1VtTFildsjJlDBFBgkrBgEEAYI3EAQx ODA2MDAxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMC Ag53MEcGCyqGSIb3DQEJEAILMTigNjAwMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzES MBAGA1UEAxMJQ05SUy1QbHVzAgIOdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQDT70G5dWoLsUNxEnn23uXSg3MAa3xSAWUPJjio5a+iXc+63O2l mjkeYt/uvUyfHNtjfHldd7n8f2Ia20Q7tsIttT0llBozXtuvuJ8UYJ4aAxYxyaeLejLtojFA 5Ewh0O0YZ3vlM7SSm55uzh4MnuMPZdiGqdnw+GbF+RJiN2O9uSrcCRrlyWyCo/xLU5XokkHX hXbpRwy6e9A8QLS89Vqa3ndqtf4Uyy6GPMrCyQp5JgKW968uleP8lyB1tbyyU8mhlLLyvblo WaAWn339Nc/UPLOJy61qv2WTWDVDZzt6GbL07TQcqdx5iJf0Ra8zFN+5E5+7ffUhLtzBAa2m F9CfAAAAAAAA --------------ms090702020105050508040500--

1 0

(ITS#5689) back-config handling of olcTranslucentLocal/Remote is broken
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.148) Submitted by: ando remove the ARG_STRING to fix. p.

1 0

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Should now be fixed in HEAD; please test and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5679) Translucent search
by julien.garnier＠dr13.cnrs.fr 08 Sep '08

08 Sep '08

This is a cryptographically signed message in MIME format. --------------ms090100030100000501010002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Pierangelo Masarati a écrit : <blockquote cite="mid:48C2B56D.6000703@sys-net.it" type="cite"><a class="moz-txt-link-abbreviated" href="mailto:julien@famille-garnier.com">julien(a)famille-garnier.com</a> wrote: <blockquote type="cite">It seems to be impossible to search local and remote together : a search request against one local attribute work correctly and return result 1 (ldapsearch "(local=*)") a search on a remote atttribute works fine  and return result 2 (ldapsearch "(remote=*)") Finaly, a search with the local and remote attribute  (ldapsearch "($(local=*)(remote=*))") </blockquote> I assume "$" is a typo, while you meant "&" in the above filter. </blockquote> Hi Pierangelo, yes, it is a typo <blockquote cite="mid:48C2B56D.6000703@sys-net.it" type="cite"> <blockquote type="cite">only return results as the search on the local attribute and doesn't take the remote attribute. The respons is the same as result 1 In slapd.conf : translucent_local local translucent_remote remote </blockquote> I've checked the current code, and it appears to work as intended.  Can you confirm the fact that the local and remote attributes are contained only in the local and the remote database, respectively?  You can easily check by directly searching the remote database.  Otherwise, you don't provide enough information about configuration and database contents to reproduce the issue. </blockquote> my config : ldap_relay (remote in the translucent config) is synchronize with a master via syncrepl. : ####################################################################### # Global Directives: # Features to permit allow bind_v2 # Schema and objectClass definitions include         /etc/openldap/schema/core.schema include         /etc/openldap/schema/cosine.schema include         /etc/openldap/schema/nis.schema include         /etc/openldap/schema/inetorgperson.schema include         /etc/openldap/schema/cnrs.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile         /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile        /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel        0 # Where the dynamically loaded modules are stored # The maximum number of entries that is returned for a search operation sizelimit 500000 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 2 ####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend         bdb #checkpoint 512 30 database        bdb # The base of your directory in database #1 suffix          "ou=People,dc=cnrs,dc=fr" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn          "cn=admin,ou=People,dc=cnrs,dc=fr" rootpw          "password" # Where the database file are physically stored for database #1 directory       "/var/lib/ldap-people" # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM #dbconfig set_cachesize 0 2097152 0 dbconfig set_cachesize 0 536870912 0 dbconfig set_flags    DB_LOG_AUTOREMOVE # Sven Hartge reported that he had to set this value incredibly high # to get slapd running at all. See <a class="moz-txt-link-freetext" href="http://bugs.debian.org/303057">http://bugs.debian.org/303057</a> # for more information. # Number of objects that can be locked at the same time. dbconfig set_lk_max_objects 1500 # Number of locks (both requestd and granted) dbconfig set_lk_max_locks 1500 # Number of lockers dbconfig set_lk_max_lockers 1500 dbconfig set_flags    DB_LOG_AUTOREMOVE # Indexing options for database #1 index objectClass                       eq index ou,cn,mail,surname,givenname      eq,pres,sub index uid                               eq,pres,sub index entryUUID,entryCSN                eq,pres index cnrsRole,cnrsDepartement          eq,pres,sub index cnrsDelegation                    eq,pres,sub index departmentNumber                  eq,pres,sub # Save the time that the entry gets modified, for database #1 lastmod         on #id du client (numero DR) syncrepl rid=013         provider=<a class="moz-txt-link-freetext" href="ldap://sagan.dr15.cnrs.fr:389">ldap://sagan.dr15.cnrs.fr:389</a>         searchbase="ou=People,dc=cnrs,dc=fr"         type=refreshAndPersist         scope=sub         interval=00:00:00:10         retry="60 10 300 +"         attrs="*"         schemachecking=off         bindmethod=simple         binddn="cn=sync-dr13,ou=people,dc=cnrs,dc=fr"         credentials="password" access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to *         by dn="cn=admin,ou=People,dc=cnrs,dc=fr" write         by * read ******************************************************************* ******************************************************************* My ldap server user translucent to add attributes to ldap_relay : # Schema and objectClass definitions include         /etc/openldap/schema/core.schema include         /etc/openldap/schema/cosine.schema include         /etc/openldap/schema/nis.schema include         /etc/openldap/schema/inetorgperson.schema include         /etc/openldap/schema/DR13.schema include         /etc/openldap/schema/cnrs.schema include         /etc/openldap/schema/dyngroup.schema #include         /etc/openldap/schema/calendar.schema #include         /etc/openldap/schema/julien.schema pidfile         /var/run/slapd/slapd.pid argsfile        /var/run/slapd/slapd.args loglevel      0 allow bind_v2 # The maximum number of entries that is returned for a search operation sizelimit       50000 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads    1 ####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend         bdb ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database        bdb # The base of your directory in database #1 suffix          "ou=People,dc=cnrs,dc=fr" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn          "cn=admin,ou=People,dc=cnrs,dc=fr" rootpw          "password" # Where the database file are physically stored for database #1 directory       "/var/lib/ldap-people" dbconfig set_cachesize 0 536870912 0 dbconfig set_flags    DB_LOG_AUTOREMOVE dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 # Indexing options for database #1 index objectClass                       eq,pres index ou,cn,mail,surname,givenname      eq,pres,sub index uid                               eq,pres index entryCSN,entryUUID                eq,pres index cnrsDelegation                    eq,pres,sub index Service,ACMO,corinfo,corcom,corform,corvalo,gxlab,corsecu,authtest,GLabintel                eq,pres,sub overlay         translucent translucent_no_glue off translucent_strict off translucent_local ACMO,Service,corinfo,corcom,corform,corvalo,gxlab,corsecu,userPassword,shadowLastChange,authtest,GLabintel,Poste translucent_remote sn,GivenName,mail,street,Postalcode,l,cnrsDelegation,uid uri             <a class="moz-txt-link-freetext" href="ldap://ldap_relay.dr13.cnrs.fr">ldap://ldap_relay.dr13.cnrs.fr</a> lastmod         off acl-bind        binddn="cn=admin,ou=People,dc=cnrs,dc=fr" credentials="password" access to attrs=userPassword,shadowLastChange         by dn="cn=admin,ou=People,dc=cnrs,dc=fr" write         by anonymous auth         by self write         by * none access to dn.base=""         by * read # acces de l'IBMM (UMR5247) access to dn.sub="ou=people,dc=cnrs,dc=fr"         filter=(ou=UMR5247*)         by peername.regex="IP=193\.49\.133\..+" read         by peername.regex="IP=127\.0\.0\.1" read         by peername.regex="IP=194\.214\.161\.70" read # acces de la delegation : lecture pour tout access to *         by peername.regex="IP=193\.49\.133\..+" read         by peername.regex="IP=127\.0\.0\.1" read         by dn="cn=admin,ou=People,dc=cnrs,dc=fr" write         by * none *********************************************************** *********************************************************** the searches : ou is in remote (it's ou derivated from inetorgperson) corsecu is in local : attribute is add to inetorgperson : attributetype ( 1.3.6.1.4.1.10813.13.2.9         NAME 'CorSecu'         DESC 'Correspondant Securité'         EQUALITY caseIgnoreMatch         SUBSTR caseIgnoreSubstringsMatch         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) if I search who is corsecu :  ldapsearch -x -b "ou=People,dc=cnrs,dc=fr"  "(corsecu=*)" ou corsecu # extended LDIF # # LDAPv3 # base <ou=People,dc=cnrs,dc=fr> with scope subtree # filter: (corsecu=*) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=martine.costanzo,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=vincent.chicot,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # josiane.tack.1, cnrs, People, cnrs.fr dn: uid=josiane.tack.1,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: VU1SNTI0MyAtICgxKSAtIEfDqW9zY2llbmNlcyBNb250cGVsbGllcg== CorSecu: UMR5243 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Josian Tack is in OU  = UMR5243 - (1) - Géosciences Montpellier other are in OU = MOY1300 - (1) - Délégation Languedoc-Roussillon If I only want corsecu in ou MOY1300 : ldapsearch -x -b "ou=People,dc=cnrs,dc=fr"  "(&(ou=MOY1300*)(corsecu=*))" ou corsecu # extended LDIF # # LDAPv3 # base <ou=People,dc=cnrs,dc=fr> with scope subtree # filter: (&(ou=MOY1300*)(corsecu=*)) # requesting: ou corsecu # # martine.costanzo, cnrs, People, cnrs.fr dn: uid=martine.costanzo,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # vincent.chicot, cnrs, People, cnrs.fr dn: uid=vincent.chicot,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: TU9ZMTMwMCAtICgxKSAtIETDqWzDqWdhdGlvbiBMYW5ndWVkb2MtUm91c3NpbGxvbg== CorSecu: MOY1300 # josiane.tack.1, cnrs, People, cnrs.fr dn: uid=josiane.tack.1,ou=cnrs,ou=People,dc=cnrs,dc=fr ou:: VU1SNTI0MyAtICgxKSAtIEfDqW9zY2llbmNlcyBNb250cGVsbGllcg== CorSecu: UMR5243 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Josiane Tack is always here Thanks Julien </body> </html> --------------ms090100030100000501010002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxTCC A2kwggJRoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NTI4WhcNMTEwNDI1MDU0NTI4WjAw MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQlSTUNpNZM31NKiH++/aLeFo2lCbD/EdAsq k8Vzl0yoN+BS3qY5EbkZbUwU3x/o0XsfvqsfOqTz4MxEavsJmlRetHAfYUPmXCiwwnxCmFS/ +N2NmN2bnWIY0Vzk6qZkgTdYZqj1eiXNyn1q1E/IpPEp7hA+KdulYJ706Xj99ih8kVFa/a8y 45ub5FOWpK4DJPBoNxS7LPsZyGtfehmcCRtj2JF7BcxJMTH6GPwZ1j/Y4DdBcxmzIfLOjQly ROrlDF5iiscuxzZOPOKUcbnjU5fgFxTE8YQ9jyqL5X6xeWaNABwPR6O+Kln/eDowWrJXnjke VBbfBKm6xYvLyzlQUQIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFFd9dKaS m4hc/uQEKfTsOmcnVOD4MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTAr MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8E BAMCAQYwDQYJKoZIhvcNAQEEBQADggEBAEc8oDJIziXlPHqdm+CF/44HRs8MOif5Un3d8x7y vgBqvLt2WV6xoI4h4Y+54Z7Aog3H65z/qtiZdxb3CehCzhltPGHZ/oNHZJa74xqUXJgXeKUk V/JQw0a/z4VLRjnhU0mzbvghbOAJsA6QqsKWC2ZiWhHZaLScVt3zrJ9F8mWX3DAf4HRN+0iY U438vLKSBM6KJhb7Mn1tXk36IcskrwAnozVizkwLendcMYpKuKyu7DofQXUouGwJF+YE6u3B L72QvPko9jHauBqNWpRm2n1ETnjw2VXs7RKfy8q8no78VLT8+x7fPCBcZMx69Ytyouj+TThX KVNQ4bxYoJEggZUwggSoMIIDkKADAgECAgIOdzANBgkqhkiG9w0BAQUFADAwMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzMB4XDTA3MTEwODEyMDAw NFoXDTA4MTEwNzEyMDAwNFowczELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxEDAOBgNV BAsTB01PWTEzMDAxFzAVBgNVBAMTDkp1bGllbiBHYXJuaWVyMSowKAYJKoZIhvcNAQkBFhtK dWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDnOJa63KmBNrk1iWwIoBfaNRIoB5R+4X+aCOXHD9jXaq5WUV42JEFHvgA87t6esw5U lKgjjyDa8IEW6YQX/WQ9EuHVq4zAvYFQ37bv+obvf1icCyOxDCqqozcIaP8vawVhD244p3bx nVP18QlmlS6MAoqD2NSOgdXjrqQb2uJSE+KLwGMnjjs4zb8lRt2dYp67z7SBLYTnTq04o0Yr fOtYt+rnlleDlWKdJGgNqryiHO20tKlOAUHE4ahZHjsKhEZGdJ4KCoEuDNQtyRLznRGuuH+b 2QjecVL2DmF26hNYlgM4c4TNWETGEBSgdBnlntcEQH443LN2qEx+lRA5dIr/AgMBAAGjggGH MIIBgzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAw cAYJYIZIAYb4QgENBGMWYUNlcnRpZmljYXQgQ05SUy1QbHVzLiBQb3VyIHRvdXRlIGluZm9y bWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5jbnJzLmZyL0NOUlMt UGx1cy8wHQYDVR0OBBYEFECFdlYtLkLUfoSH/7VfvQ4hYG60MFMGA1UdIwRMMEqAFFd9dKaS m4hc/uQEKfTsOmcnVOD4oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzENMAsG A1UEAxMEQ05SU4IBATAmBgNVHREEHzAdgRtKdWxpZW4uR2FybmllckBkcjEzLmNucnMuZnIw QgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NybHMuc2VydmljZXMuY25ycy5mci9DTlJTLVBs dXMvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuz1KzmYgAcfVPB1mE8GBR0Yzz/td ij3IttaeiCmpDfArhOwdolUiLV1MF/oJGDHX+yxpcHNu6wH3E6eEVoYycPwCcN5P9mTaxrTG KYXIj6RoDPIiCQpE9zjKV+c0jJr0bwBZIIJfCIpOpmcHHW+3BbtqjuboydwOqh5ICesPnMRr BA6WEEnB7pv1sp0vAoK0O7/ctJS6C/X37LsTBYcHVkKoyjGYUYdBjWUgmPs+jsArqe+QKSRA zl/3Xc83ZZ681aKApq9hrlmDYpP50E87uK+c2ul/fm4iwvJdb3WkyQaCfc4Epot5GMusb5/C j8JLmtpc7mv+DIrhbz3jbmZ0HTCCBKgwggOQoAMCAQICAg53MA0GCSqGSIb3DQEBBQUAMDAx CzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMwHhcNMDcx MTA4MTIwMDA0WhcNMDgxMTA3MTIwMDA0WjBzMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHTU9ZMTMwMDEXMBUGA1UEAxMOSnVsaWVuIEdhcm5pZXIxKjAoBgkqhkiG 9w0BCQEWG0p1bGllbi5HYXJuaWVyQGRyMTMuY25ycy5mcjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAOc4lrrcqYE2uTWJbAigF9o1EigHlH7hf5oI5ccP2NdqrlZRXjYkQUe+ ADzu3p6zDlSUqCOPINrwgRbphBf9ZD0S4dWrjMC9gVDftu/6hu9/WJwLI7EMKqqjNwho/y9r BWEPbjindvGdU/XxCWaVLowCioPY1I6B1eOupBva4lIT4ovAYyeOOzjNvyVG3Z1inrvPtIEt hOdOrTijRit861i36ueWV4OVYp0kaA2qvKIc7bS0qU4BQcThqFkeOwqERkZ0ngoKgS4M1C3J EvOdEa64f5vZCN5xUvYOYXbqE1iWAzhzhM1YRMYQFKB0GeWe1wRAfjjcs3aoTH6VEDl0iv8C AwEAAaOCAYcwggGDMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DBwBglghkgBhvhCAQ0EYxZhQ2VydGlmaWNhdCBDTlJTLVBsdXMuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMu ZnIvQ05SUy1QbHVzLzAdBgNVHQ4EFgQUQIV2Vi0uQtR+hIf/tV+9DiFgbrQwUwYDVR0jBEww SoAUV310ppKbiFz+5AQp9Ow6ZydU4PihL6QtMCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRD TlJTMQ0wCwYDVQQDEwRDTlJTggEBMCYGA1UdEQQfMB2BG0p1bGllbi5HYXJuaWVyQGRyMTMu Y25ycy5mcjBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtUGx1cy9nZXRkZXIuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQC7PUrOZiABx9U8HWYT wYFHRjPP+12KPci21p6IKakN8CuE7B2iVSItXUwX+gkYMdf7LGlwc27rAfcTp4RWhjJw/AJw 3k/2ZNrGtMYphciPpGgM8iIJCkT3OMpX5zSMmvRvAFkggl8Iik6mZwcdb7cFu2qO5ujJ3A6q HkgJ6w+cxGsEDpYQScHum/WynS8CgrQ7v9y0lLoL9ffsuxMFhwdWQqjKMZhRh0GNZSCY+z6O wCup75ApJEDOX/ddzzdlnrzVooCmr2GuWYNik/nQTzu4r5za6X9+biLC8l1vdaTJBoJ9zgSm i3kYy6xvn8KPwkua2lzua/4MiuFvPeNuZnQdMYICojCCAp4CAQEwNjAwMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzESMBAGA1UEAxMJQ05SUy1QbHVzAgIOdzAJBgUrDgMCGgUAoIIB QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA5MDgwODU1 MDBaMCMGCSqGSIb3DQEJBDEWBBSid4zDaEYBT67+19UaSp/1nXMUWDBFBgkrBgEEAYI3EAQx ODA2MDAxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRIwEAYDVQQDEwlDTlJTLVBsdXMC Ag53MEcGCyqGSIb3DQEJEAILMTigNjAwMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzES MBAGA1UEAxMJQ05SUy1QbHVzAgIOdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQA04y3ZTPTP04e07uaMNwF5+4i+329g+KgAd+lmUvfaGJsOyGjw pCsZQIqeBzZFAfCNtmp8VyU2TCVcF6A5odWabasUltXe8HfLN64njJ/50iUQfDRFZEcZfh9b nYSTsHiuCyua78Iim18gNflXQReHWdreoSkg0MDaq0MTd98tNxZsOFPa4l9e7Xj29F4HHgck pD/0XXmP6/ZtFOxZUojL92H31RS6MlPeLC0EX5RjkLQ4maXlMvjX1MQUpv6uwOG1rkSaTDKW zEcUcKP/gYFHL7LDUZC8GlhLGvuzxrSamS2RRJE+mAzc/U+aOf6O7qeFyje8PM6r57qc0iQQ XCDeAAAAAAAA --------------ms090100030100000501010002--

1 0

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 08 Sep '08

08 Sep '08

The suggested extension has been added to syntax add code; parsing of a syntax with the given extension will result in using the implementation of the substitute syntax if an implementation is missing for the given syntax. This only works for syntaxes added programmatically using syn_add(), e.g. by run-time modules, as there's no provisions for adding syntaxes via configuration. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 06 Sep '08

06 Sep '08

--On Saturday, September 06, 2008 2:26 PM +0000 ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> The problem is in glue_op_search(): it saves a copy of the rewritten DN; >> in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a >> dangling pointer to it is later restored in o_req_[n]dn by >> glue_op_search (lines 446-7 or 463-4). Trying to fix it... > > I've applied a fix that works around this issue without apparently > breaking back-glue (servers/slapd/backglue.c 1.139 -> 1.140). Please > test. I have no more issues after applying these additional fixes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 06 Sep '08

06 Sep '08

julien(a)famille-garnier.com wrote: > It seems to be impossible to search local and remote together : > > a search request against one local attribute work correctly and return result 1 > (ldapsearch "(local=*)") > a search on a remote atttribute works fine and return result 2 (ldapsearch > "(remote=*)") > > Finaly, a search with the local and remote attribute (ldapsearch > "($(local=*)(remote=*))") I assume "$" is a typo, while you meant "&" in the above filter. > only return results as the search on the local > attribute and doesn't take the remote attribute. The respons is the same as > result 1 > > > In slapd.conf : > translucent_local local > translucent_remote remote I've checked the current code, and it appears to work as intended. Can you confirm the fact that the local and remote attributes are contained only in the local and the remote database, respectively? You can easily check by directly searching the remote database. Otherwise, you don't provide enough information about configuration and database contents to reproduce the issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

hyc(a)symas.com wrote: > The serious problem is in thread 5, where rwm_op_cleanup frees a DN that > do_search also tries to free. It looks like rwm_op_cleanup is badly broken > here, it apparently should be checking to make sure ros->ro_dn is != ros->r_dn > before freeing r_dn (and ndn). This issue can be serious since it could also hit in case of abandon, not just in case of shutdown. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

ando(a)sys-net.it wrote: > The problem is in glue_op_search(): it saves a copy of the rewritten DN; > in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a > dangling pointer to it is later restored in o_req_[n]dn by > glue_op_search (lines 446-7 or 463-4). Trying to fix it... I've applied a fix that works around this issue without apparently breaking back-glue (servers/slapd/backglue.c 1.139 -> 1.140). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

ando(a)sys-net.it wrote: > It seems that rwm_op_cleanup() frees the massaged DN but does not > restore the original values, since do_search frees it again. I guess > the dn does get massaged, since r_dn is not null. The problem is in glue_op_search(): it saves a copy of the rewritten DN; in case of CTRL^C, the rewritten DN is deleted by rwm_op_cleanup, and a dangling pointer to it is later restored in o_req_[n]dn by glue_op_search (lines 446-7 or 463-4). Trying to fix it... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

Quanah, I'm not seeing failures like yours, but valgrind is telling me that there is still a double-free in rwm in case of CTRL^C (apart from the listener-related one, which occurs very often): ==12729== Thread 7: ==12729== Invalid free() / delete / delete[] ==12729== at 0x4004FDA: free (vg_replace_malloc.c:233) ==12729== by 0x8240855: ber_memfree_x (memory.c:152) ==12729== by 0x80E5277: slap_sl_free (sl_malloc.c:451) ==12729== by 0x80874AF: do_search (search.c:221) ==12729== by 0x8084347: connection_operation (connection.c:1084) ==12729== by 0x8084834: connection_read_thread (connection.c:1211) ==12729== by 0x820F460: ldap_int_thread_pool_wrapper (tpool.c:663) ==12729== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==12729== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==12729== Address 0x44F7908 is 0 bytes inside a block of size 19 free'd ==12729== at 0x4004FDA: free (vg_replace_malloc.c:233) ==12729== by 0x8240855: ber_memfree_x (memory.c:152) ==12729== by 0x80A5A31: ch_free (ch_malloc.c:139) ==12729== by 0x81E1DC0: rwm_op_cleanup (rwm.c:65) ==12729== by 0x80976CD: slap_cleanup_play (result.c:341) ==12729== by 0x8097DEA: send_ldap_response (result.c:522) ==12729== by 0x809850E: slap_send_ldap_result (result.c:642) ==12729== by 0x812D806: ldap_back_search (search.c:544) ==12729== by 0x80F7E40: glue_sub_search (backglue.c:340) ==12729== by 0x80F83A9: glue_op_search (backglue.c:452) ==12729== by 0x80FAD2F: overlay_op_walk (backover.c:657) ==12729== by 0x80FAF64: over_op_func (backover.c:719) ==12729== by 0x80FAFE8: over_op_search (backover.c:741) ==12729== by 0x8087ADB: fe_op_search (search.c:366) ==12729== by 0x80FADAF: overlay_op_walk (backover.c:667) ==12729== by 0x80FAF64: over_op_func (backover.c:719) ==12729== by 0x80FAFE8: over_op_search (backover.c:741) ==12729== by 0x8087483: do_search (search.c:217) ==12729== by 0x8084347: connection_operation (connection.c:1084) ==12729== by 0x8084834: connection_read_thread (connection.c:1211) ==12729== It seems that rwm_op_cleanup() frees the massaged DN but does not restore the original values, since do_search frees it again. I guess the dn does get massaged, since r_dn is not null. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 06 Sep '08

06 Sep '08

--On Saturday, September 06, 2008 1:28 AM +0000 quanah(a)zimbra.com wrote: This one too: Loaded symbols for ../servers/slapd/overlays/.libs/rwm-2.4-releng.so.2 #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003bf972fa5e in abort () from /lib64/tls/libc.so.6 #2 0x0000003bf97635e1 in __libc_message () from /lib64/tls/libc.so.6 #3 0x0000003bf9768a78 in malloc_consolidate () from /lib64/tls/libc.so.6 #4 0x0000003bf97698a9 in _int_malloc () from /lib64/tls/libc.so.6 #5 0x0000003bf976b3d2 in calloc () from /lib64/tls/libc.so.6 #6 0x0000002a956bc517 in ber_memcalloc_x (n=1, s=560, ctx=0x0) at memory.c:277 #7 0x0000002a9556a5c0 in ldap_create (ldp=0x45808270) at open.c:113 #8 0x0000002a9556a985 in ldap_initialize (ldp=0x458082e8, url=0x7070c0 "ldap://localhost:9011") at open.c:223 #9 0x0000002a974aa3df in ldap_back_prepare_conn (lc=0x7d63d0, op=0x810030, rs=0x45809cc0, sendok=LDAP_BACK_DONTSEND) at bind.c:639 #10 0x0000002a974ad2c2 in ldap_back_retry (lcp=0x45808520, op=0x810030, rs=0x45809cc0, sendok=LDAP_BACK_DONTSEND) at bind.c:1893 #11 0x0000002a974a8668 in ldap_back_search (op=0x810030, rs=0x45809cc0) at search.c:502 #12 0x00000000004ac45d in glue_sub_search (op=0x810030, rs=0x45809cc0, b0=0x45808740, on=0x6c1e70) at backglue.c:340 #13 0x00000000004aca5f in glue_op_search (op=0x810030, rs=0x45809cc0) at backglue.c:452 #14 0x00000000004afacf in overlay_op_walk (op=0x810030, rs=0x45809cc0, which=op_search, oi=0x6c1c90, on=0x6c1e70) at backover.c:657 #15 0x00000000004afd2b in over_op_func (op=0x810030, rs=0x45809cc0, which=op_search) at backover.c:719 #16 0x00000000004afdc1 in over_op_search (op=0x810030, rs=0x45809cc0) at backover.c:741 #17 0x0000000000435ea8 in fe_op_search (op=0x810030, rs=0x45809cc0) at search.c:366 #18 0x00000000004afb63 in overlay_op_walk (op=0x810030, rs=0x45809cc0, which=op_search, oi=0x702480, on=0x0) at backover.c:667 #19 0x00000000004afd2b in over_op_func (op=0x810030, rs=0x45809cc0, which=op_search) at backover.c:719 #20 0x00000000004afdc1 in over_op_search (op=0x810030, rs=0x45809cc0) at backover.c:741 #21 0x0000000000435865 in do_search (op=0x810030, rs=0x45809cc0) at search.c:217 #22 0x0000000000432839 in connection_operation (ctx=0x45809e20, arg_v=0x810030) at connection.c:1084 #23 0x0000000000432d75 in connection_read_thread (ctx=0x45809e20, argv=0x29) at connection.c:1211 #24 0x0000002a95568cd0 in ldap_int_thread_pool_wrapper (xpool=0x6a3500) at tpool.c:663 #25 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #26 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6 (gdb) info threads 18 process 30967 0x0000003bfa00714b in pthread_join () from /lib64/tls/libpthread.so.0 17 process 31162 0x0000003bfa008b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 16 process 31178 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 15 process 31259 0x0000003bfa00af8b in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0 14 process 31262 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 13 process 31313 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 12 process 31397 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 11 process 31402 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 10 process 31403 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 9 process 31408 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 8 process 31409 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 7 process 31423 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 6 process 31485 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 5 process 31486 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 4 process 31497 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 3 process 31498 0x0000003bfa00af8b in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0 2 process 31511 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 * 1 process 31422 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 06 Sep '08

06 Sep '08

--On Saturday, September 06, 2008 1:12 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, September 06, 2008 12:08 AM +0000 hyc(a)symas.com wrote: > >> ando(a)sys-net.it wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>>> [quanah@freelancer tests]$ *** glibc detected *** >>>>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>>>> double-linked list: 0x000000000d28a430 *** >>>> This message comes from glibc malloc. Its data structures are >>>> corrupted. >>>> >>>> I couldn't figure out much from the the valgrind output. >>>> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >>>> if that code isn't rotted - maybe that'll bring out the problem in >>>> another guise. If that code still works, I don't remember. >>> >>> Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running >>> test039 under valgrind and suddenly killing the process: >>> >>> ==9657== Memcheck, a memory error detector. >>> ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. >>> ==9657== Using LibVEX rev 1658, a library for dynamic binary >>> translation. ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by >>> OpenWorks LLP. ==9657== Using valgrind-3.2.1, a dynamic binary >>> instrumentation framework. ==9657== Copyright (C) 2000-2006, and GNU >>> GPL'd, by Julian Seward et al. ==9657== For more details, rerun with: -v >>> ==9657== >>> @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ >>> masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap- >>> devel/servers/slapd slapd starting >>> daemon: shutdown requested and initiated. >>> slapd shutdown: waiting for 8 threads to terminate >>> ==9657== Thread 3: >>> ==9657== Invalid read of size 4 >>> ==9657== at 0x807EF03: slap_listener (daemon.c:1754) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== >>> ==9657== Invalid write of size 4 >>> ==9657== at 0x807EF22: slap_listener (daemon.c:1759) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== >>> ==9657== Invalid read of size 4 >>> ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) >>> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 >>> free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >>> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> daemon: accept(7) failed errno=9 (Bad file descriptor) >>> ==9657== >>> ==9657== Thread 5: >>> ==9657== Invalid free() / delete / delete[] >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >>> ==9657== by 0x80874AF: do_search (search.c:221) >>> ==9657== by 0x8084347: connection_operation (connection.c:1084) >>> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) >>> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >>> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >>> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >>> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >>> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >>> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >>> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >>> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >>> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >>> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >>> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== >>> ==9657== Invalid free() / delete / delete[] >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >>> ==9657== by 0x80874D3: do_search (search.c:224) >>> ==9657== by 0x8084347: connection_operation (connection.c:1084) >>> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >>> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >>> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >>> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >>> ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd >>> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >>> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >>> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >>> ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) >>> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >>> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >>> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >>> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >>> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >>> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >>> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >>> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >>> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >>> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >>> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >>> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >>> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >>> conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" >>> DN="cn=manager,dc=example,dc=com" >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> ==9657== Warning: invalid file descriptor -1 in syscall close() >>> slapd stopped. >>> ==9657== >>> ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) >>> ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. >>> ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes >>> allocated. >>> ==9657== For counts of detected errors, rerun with: -v >>> ==9657== searching for pointers to 15 not-freed blocks. >>> ==9657== checked 774,072 bytes. >>> >>> Apparently, the listener is freed while some thread is still using it. >> >> Since that can only occur during shutdown, I don't think it's really a >> high priority problem. More to the point, it will not cause any heap >> corruption. The serious problem is in thread 5, where rwm_op_cleanup >> frees a DN that do_search also tries to free. It looks like >> rwm_op_cleanup is badly broken here, it apparently should be checking to >> make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). > > With the latest rwm revision, I still get the glibc corruption: > > PID=15912 - Search(500): base="o=Example,c=US" scope=sub > filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). > > [quanah@tribes tests]$ *** glibc detected *** corrupted double-linked > list: 0x0000003bf99316b8 *** > > when I hit control-C during the search. Longer backtrace: Loaded symbols for /lib64/libgcc_s.so.1 #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 #1 0x0000003bf972fa5e in abort () from /lib64/tls/libc.so.6 #2 0x0000003bf97635e1 in __libc_message () from /lib64/tls/libc.so.6 #3 0x0000003bf9768a78 in malloc_consolidate () from /lib64/tls/libc.so.6 #4 0x0000003bf97698a9 in _int_malloc () from /lib64/tls/libc.so.6 #5 0x0000003bf976b682 in malloc () from /lib64/tls/libc.so.6 #6 0x0000002a956bc46d in ber_memalloc_x (s=4060, ctx=0x0) at memory.c:226 #7 0x0000002a956bc5b1 in ber_memrealloc_x (p=0x0, s=4060, ctx=0x0) at memory.c:304 #8 0x0000002a956ba5ef in ber_realloc (ber=0x7ce520, len=1) at io.c:155 #9 0x0000002a956ba49b in ber_write (ber=0x7ce520, buf=0x42001010 "\002ï¿½\177@", len=1, nosos=0) at io.c:114 #10 0x0000002a956b8145 in ber_put_tag (ber=0x7ce520, tag=0, nosos=0) at encode.c:100 #11 0x0000002a956b877e in ber_put_int_or_enum (ber=0x7ce520, num=6, tag=2) at encode.c:284 #12 0x0000002a956b8933 in ber_put_int (ber=0x7ce520, num=6, tag=2) at encode.c:333 #13 0x0000002a956b99f7 in ber_printf (ber=0x7ce520, fmt=0x2a955a1629 "iti") at encode.c:774 #14 0x0000002a95574f68 in do_abandon (ld=0x81f9f0, origid=5, msgid=5, sctrls=0x0, sendabandon=1) at abandon.c:243 #15 0x0000002a95574c49 in ldap_abandon_ext (ld=0x81f9f0, msgid=5, sctrls=0x0, cctrls=0x0) at abandon.c:80 #16 0x0000002a974ac864 in ldap_back_cancel (lc=0x81f5d0, op=0x7bab00, rs=0x42002cc0, msgid=5, sendok=LDAP_BACK_DONTSEND) at bind.c:1607 #17 0x0000002a974a7d02 in ldap_back_search (op=0x7bab00, rs=0x42002cc0) at search.c:287 #18 0x00000000004ac45d in glue_sub_search (op=0x7bab00, rs=0x42002cc0, b0=0x42001740, on=0x6c1e70) at backglue.c:340 #19 0x00000000004aca5f in glue_op_search (op=0x7bab00, rs=0x42002cc0) at backglue.c:452 #20 0x00000000004afacf in overlay_op_walk (op=0x7bab00, rs=0x42002cc0, which=op_search, oi=0x6c1c90, on=0x6c1e70) at backover.c:657 #21 0x00000000004afd2b in over_op_func (op=0x7bab00, rs=0x42002cc0, which=op_search) at backover.c:719 #22 0x00000000004afdc1 in over_op_search (op=0x7bab00, rs=0x42002cc0) at backover.c:741 #23 0x0000000000435ea8 in fe_op_search (op=0x7bab00, rs=0x42002cc0) at search.c:366 #24 0x00000000004afb63 in overlay_op_walk (op=0x7bab00, rs=0x42002cc0, which=op_search, oi=0x702480, on=0x0) at backover.c:667 #25 0x00000000004afd2b in over_op_func (op=0x7bab00, rs=0x42002cc0, which=op_search) at backover.c:719 #26 0x00000000004afdc1 in over_op_search (op=0x7bab00, rs=0x42002cc0) at backover.c:741 #27 0x0000000000435865 in do_search (op=0x7bab00, rs=0x42002cc0) at search.c:217 #28 0x0000000000432839 in connection_operation (ctx=0x42002e20, arg_v=0x7bab00) at connection.c:1084 #29 0x0000000000432d75 in connection_read_thread (ctx=0x42002e20, argv=0x2b) at connection.c:1211 #30 0x0000002a95568cd0 in ldap_int_thread_pool_wrapper (xpool=0x6a3500) at tpool.c:663 #31 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #32 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6 (gdb) info threads 15 process 25502 0x0000003bfa00714b in pthread_join () from /lib64/tls/libpthread.so.0 14 process 25532 0x0000003bfa008b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 13 process 25554 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 12 process 25555 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 11 process 25821 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 10 process 25834 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 9 process 25852 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 8 process 25869 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 7 process 25870 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 6 process 25871 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 5 process 25923 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 4 process 25925 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 3 process 25928 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 2 process 25931 0x0000003bf97be5e2 in poll () from /lib64/tls/libc.so.6 * 1 process 25820 0x0000003bf972e25d in raise () from /lib64/tls/libc.so.6 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 06 Sep '08

06 Sep '08

--On Saturday, September 06, 2008 12:08 AM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>>> [quanah@freelancer tests]$ *** glibc detected *** >>>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>>> double-linked list: 0x000000000d28a430 *** >>> This message comes from glibc malloc. Its data structures are >>> corrupted. >>> >>> I couldn't figure out much from the the valgrind output. >>> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >>> if that code isn't rotted - maybe that'll bring out the problem in >>> another guise. If that code still works, I don't remember. >> >> Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running >> test039 under valgrind and suddenly killing the process: >> >> ==9657== Memcheck, a memory error detector. >> ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. >> ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. >> ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. >> ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation >> framework. ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian >> Seward et al. ==9657== For more details, rerun with: -v >> ==9657== >> @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ >> masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap- >> devel/servers/slapd slapd starting >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 8 threads to terminate >> ==9657== Thread 3: >> ==9657== Invalid read of size 4 >> ==9657== at 0x807EF03: slap_listener (daemon.c:1754) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== >> ==9657== Invalid write of size 4 >> ==9657== at 0x807EF22: slap_listener (daemon.c:1759) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== >> ==9657== Invalid read of size 4 >> ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) >> ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) >> ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> daemon: accept(7) failed errno=9 (Bad file descriptor) >> ==9657== >> ==9657== Thread 5: >> ==9657== Invalid free() / delete / delete[] >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >> ==9657== by 0x80874AF: do_search (search.c:221) >> ==9657== by 0x8084347: connection_operation (connection.c:1084) >> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) >> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== >> ==9657== Invalid free() / delete / delete[] >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) >> ==9657== by 0x80874D3: do_search (search.c:224) >> ==9657== by 0x8084347: connection_operation (connection.c:1084) >> ==9657== by 0x8084834: connection_read_thread (connection.c:1211) >> ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) >> ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) >> ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) >> ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd >> ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) >> ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) >> ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) >> ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) >> ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) >> ==9657== by 0x8097DEA: send_ldap_response (result.c:522) >> ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) >> ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) >> ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) >> ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) >> ==9657== by 0x812C9F7: ldap_back_search (search.c:174) >> ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) >> ==9657== by 0x80F8458: glue_op_search (backglue.c:467) >> ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> ==9657== by 0x8087ADB: fe_op_search (search.c:366) >> ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) >> ==9657== by 0x80FAF18: over_op_func (backover.c:719) >> ==9657== by 0x80FAF9C: over_op_search (backover.c:741) >> conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" >> DN="cn=manager,dc=example,dc=com" >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> ==9657== Warning: invalid file descriptor -1 in syscall close() >> slapd stopped. >> ==9657== >> ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) >> ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. >> ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes >> allocated. >> ==9657== For counts of detected errors, rerun with: -v >> ==9657== searching for pointers to 15 not-freed blocks. >> ==9657== checked 774,072 bytes. >> >> Apparently, the listener is freed while some thread is still using it. > > Since that can only occur during shutdown, I don't think it's really a > high priority problem. More to the point, it will not cause any heap > corruption. The serious problem is in thread 5, where rwm_op_cleanup > frees a DN that do_search also tries to free. It looks like > rwm_op_cleanup is badly broken here, it apparently should be checking to > make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). With the latest rwm revision, I still get the glibc corruption: PID=15912 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). [quanah@tribes tests]$ *** glibc detected *** corrupted double-linked list: 0x0000003bf99316b8 *** when I hit control-C during the search. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by hyc＠symas.com 06 Sep '08

06 Sep '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >>> [quanah@freelancer tests]$ *** glibc detected *** >>> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >>> double-linked list: 0x000000000d28a430 *** >> This message comes from glibc malloc. Its data structures are >> corrupted. >> >> I couldn't figure out much from the the valgrind output. >> But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, >> if that code isn't rotted - maybe that'll bring out the problem in >> another guise. If that code still works, I don't remember. > > Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running > test039 under valgrind and suddenly killing the process: > > ==9657== Memcheck, a memory error detector. > ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. > ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation framework. > ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==9657== For more details, rerun with: -v > ==9657== > @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ > masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap-devel/servers/slapd > slapd starting > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 8 threads to terminate > ==9657== Thread 3: > ==9657== Invalid read of size 4 > ==9657== at 0x807EF03: slap_listener (daemon.c:1754) > ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) > ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== > ==9657== Invalid write of size 4 > ==9657== at 0x807EF22: slap_listener (daemon.c:1759) > ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) > ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== > ==9657== Invalid read of size 4 > ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) > ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) > ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > daemon: accept(7) failed errno=9 (Bad file descriptor) > ==9657== > ==9657== Thread 5: > ==9657== Invalid free() / delete / delete[] > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) > ==9657== by 0x80874AF: do_search (search.c:221) > ==9657== by 0x8084347: connection_operation (connection.c:1084) > ==9657== by 0x8084834: connection_read_thread (connection.c:1211) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) > ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) > ==9657== by 0x8097DEA: send_ldap_response (result.c:522) > ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) > ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) > ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) > ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) > ==9657== by 0x812C9F7: ldap_back_search (search.c:174) > ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) > ==9657== by 0x80F8458: glue_op_search (backglue.c:467) > ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > ==9657== by 0x8087ADB: fe_op_search (search.c:366) > ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > ==9657== > ==9657== Invalid free() / delete / delete[] > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) > ==9657== by 0x80874D3: do_search (search.c:224) > ==9657== by 0x8084347: connection_operation (connection.c:1084) > ==9657== by 0x8084834: connection_read_thread (connection.c:1211) > ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) > ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) > ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) > ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd > ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) > ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) > ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) > ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) > ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) > ==9657== by 0x8097DEA: send_ldap_response (result.c:522) > ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) > ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) > ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) > ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) > ==9657== by 0x812C9F7: ldap_back_search (search.c:174) > ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) > ==9657== by 0x80F8458: glue_op_search (backglue.c:467) > ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > ==9657== by 0x8087ADB: fe_op_search (search.c:366) > ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) > ==9657== by 0x80FAF18: over_op_func (backover.c:719) > ==9657== by 0x80FAF9C: over_op_search (backover.c:741) > conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" > DN="cn=manager,dc=example,dc=com" > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > ==9657== Warning: invalid file descriptor -1 in syscall close() > slapd stopped. > ==9657== > ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) > ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. > ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes > allocated. > ==9657== For counts of detected errors, rerun with: -v > ==9657== searching for pointers to 15 not-freed blocks. > ==9657== checked 774,072 bytes. > > Apparently, the listener is freed while some thread is still using it. Since that can only occur during shutdown, I don't think it's really a high priority problem. More to the point, it will not cause any heap corruption. The serious problem is in thread 5, where rwm_op_cleanup frees a DN that do_search also tries to free. It looks like rwm_op_cleanup is badly broken here, it apparently should be checking to make sure ros->ro_dn is != ros->r_dn before freeing r_dn (and ndn). -- -- 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

Searching for (objectClass=UNDEFINED)...
by Pierangelo Masarati 06 Sep '08

06 Sep '08

... returns success with the text "value does not conform to assertion syntax"; is this the intended behavior, or should the filter error go completely unnoticed, and the text rather be logged, or what? The current behavior seems to be a consequence of servers/slapd/ava.c 1.45 -> 1.46 (by hyc) returning LDAP_SUCCESS instead of rc, without intentionally?) clearing text. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

5 8

Re: (ITS#5687) corrupted double-linked list on shutdown
by ando＠sys-net.it 06 Sep '08

06 Sep '08

h.b.furuseth(a)usit.uio.no wrote: >> [quanah@freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. > > I couldn't figure out much from the the valgrind output. > But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, > if that code isn't rotted - maybe that'll bring out the problem in > another guise. If that code still works, I don't remember. Here's my output after compiling with -DSLAP_NO_SL_MALLOC=1, running test039 under valgrind and suddenly killing the process: ==9657== Memcheck, a memory error detector. ==9657== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==9657== Using LibVEX rev 1658, a library for dynamic binary translation. ==9657== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==9657== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==9657== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==9657== For more details, rerun with: -v ==9657== @(#) $OpenLDAP: slapd 2.X (Sep 6 2008 01:35:19) $ masarati@odino.intra.sys-net.it:/home/masarati/Lavoro/sysnet/Ldap/ldap-devel/servers/slapd slapd starting daemon: shutdown requested and initiated. slapd shutdown: waiting for 8 threads to terminate ==9657== Thread 3: ==9657== Invalid read of size 4 ==9657== at 0x807EF03: slap_listener (daemon.c:1754) ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== ==9657== Invalid write of size 4 ==9657== at 0x807EF22: slap_listener (daemon.c:1759) ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x415D3A4 is 28 bytes inside a block of size 164 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== ==9657== Invalid read of size 4 ==9657== at 0x807EFCD: slap_listener (daemon.c:1781) ==9657== by 0x807F9AC: slap_listener_thread (daemon.c:1997) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x415D3A8 is 32 bytes inside a block of size 164 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x807EDF8: close_listeners (daemon.c:1703) ==9657== by 0x808137F: slapd_daemon_task (daemon.c:2578) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) daemon: accept(7) failed errno=9 (Bad file descriptor) ==9657== ==9657== Thread 5: ==9657== Invalid free() / delete / delete[] ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) ==9657== by 0x80874AF: do_search (search.c:221) ==9657== by 0x8084347: connection_operation (connection.c:1084) ==9657== by 0x8084834: connection_read_thread (connection.c:1211) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x5595D60 is 0 bytes inside a block of size 29 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x81E1D64: rwm_op_cleanup (rwm.c:64) ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) ==9657== by 0x8097DEA: send_ldap_response (result.c:522) ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) ==9657== by 0x812C9F7: ldap_back_search (search.c:174) ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) ==9657== by 0x80F8458: glue_op_search (backglue.c:467) ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) ==9657== by 0x8087ADB: fe_op_search (search.c:366) ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) ==9657== ==9657== Invalid free() / delete / delete[] ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80E522B: slap_sl_free (sl_malloc.c:451) ==9657== by 0x80874D3: do_search (search.c:224) ==9657== by 0x8084347: connection_operation (connection.c:1084) ==9657== by 0x8084834: connection_read_thread (connection.c:1211) ==9657== by 0x820F3D4: ldap_int_thread_pool_wrapper (tpool.c:663) ==9657== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==9657== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==9657== Address 0x5595E60 is 0 bytes inside a block of size 29 free'd ==9657== at 0x4004FDA: free (vg_replace_malloc.c:233) ==9657== by 0x82407C9: ber_memfree_x (memory.c:152) ==9657== by 0x80A59E5: ch_free (ch_malloc.c:139) ==9657== by 0x81E1D90: rwm_op_cleanup (rwm.c:69) ==9657== by 0x80976CD: slap_cleanup_play (result.c:341) ==9657== by 0x8097DEA: send_ldap_response (result.c:522) ==9657== by 0x809850E: slap_send_ldap_result (result.c:642) ==9657== by 0x81855CE: ldap_back_op_result (bind.c:1823) ==9657== by 0x8184C3D: ldap_back_dobind_int (bind.c:1486) ==9657== by 0x8184D41: ldap_back_dobind (bind.c:1520) ==9657== by 0x812C9F7: ldap_back_search (search.c:174) ==9657== by 0x80F7DF4: glue_sub_search (backglue.c:340) ==9657== by 0x80F8458: glue_op_search (backglue.c:467) ==9657== by 0x80FACE3: overlay_op_walk (backover.c:657) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) ==9657== by 0x8087ADB: fe_op_search (search.c:366) ==9657== by 0x80FAD63: overlay_op_walk (backover.c:667) ==9657== by 0x80FAF18: over_op_func (backover.c:719) ==9657== by 0x80FAF9C: over_op_search (backover.c:741) conn=3 op=1 ldap_back_retry: retrying URI="ldap://localhost:9011" DN="cn=manager,dc=example,dc=com" ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() ==9657== Warning: invalid file descriptor -1 in syscall close() slapd stopped. ==9657== ==9657== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 36 from 1) ==9657== malloc/free: in use at exit: 1,127 bytes in 15 blocks. ==9657== malloc/free: 34,414 allocs, 34,403 frees, 12,376,432 bytes allocated. ==9657== For counts of detected errors, rerun with: -v ==9657== searching for pointers to 15 not-freed blocks. ==9657== checked 774,072 bytes. Apparently, the listener is freed while some thread is still using it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5688) slapd returns success with message when an undefined objectClass is used in filter
by ando＠sys-net.it 05 Sep '08

05 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See discussion here: <http://www.openldap.org/lists/openldap-bugs/200809/msg00029.html>. A fix is coming. p.

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Friday, September 05, 2008 8:52 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> [quanah@freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. > > I couldn't figure out much from the the valgrind output. > But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, > if that code isn't rotted - maybe that'll bring out the problem in > another guise. If that code still works, I don't remember. More notes: I get a core file every time I kill test039, even at stages outside the search. I only get the glibc error some of the time. Even testing with the latest and greatest valgrind, I don't see anything in its output file. I've managed to reproduce this behavior on both CentOS5 (64-bit) and RHEL4 (64-bit), which are running different kernels (and I assume glibc versions). backtrace on a non-glibc fault core: Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 11, Segmentation fault. #0 0x00000038dc06ca17 in malloc_consolidate () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc06ca17 in malloc_consolidate () from /lib64/libc.so.6 #1 0x00000038dc06e607 in _int_free () from /lib64/libc.so.6 #2 0x00000038dc071fac in free () from /lib64/libc.so.6 #3 0x00002ae61bf34732 in ber_memfree_x (p=0x7302670, ctx=0x0) at memory.c:152 #4 0x000000000049d882 in slap_sl_mem_destroy (key=0x49da46, data=0x7302630) at sl_malloc.c:41 #5 0x00002ae61bce35c2 in ldap_pvt_thread_pool_context_reset (vctx=0x46da1dd0) at tpool.c:943 #6 0x00002ae61bce2a8a in ldap_int_thread_pool_wrapper (xpool=0x688e610) at tpool.c:677 #7 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by hyc＠symas.com 05 Sep '08

05 Sep '08

h.b.furuseth(a)usit.uio.no wrote: >> [quanah@freelancer tests]$ *** glibc detected *** >> /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted >> double-linked list: 0x000000000d28a430 *** > > This message comes from glibc malloc. Its data structures are > corrupted. Right. But ordinarily, valgrind intercepts all mallocs and as such, any corruption should have been detected first by valgrind. The fact that valgrind didn't complain implies either a bug in valgrind or a bug in glibc. -- -- 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#5687) corrupted double-linked list on shutdown
by h.b.furuseth＠usit.uio.no 05 Sep '08

05 Sep '08

> [quanah@freelancer tests]$ *** glibc detected *** > /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted > double-linked list: 0x000000000d28a430 *** This message comes from glibc malloc. Its data structures are corrupted. I couldn't figure out much from the the valgrind output. But you'll get more frequent mallocs with CPPFLAGS=-DSLAP_NO_SL_MALLOC, if that code isn't rotted - maybe that'll bring out the problem in another guise. If that code still works, I don't remember. -- Hallvard

1 0

Re: (ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Friday, September 05, 2008 7:03 PM +0000 quanah(a)zimbra.com wrote: With valgrind: [quanah@freelancer tests]$ *** glibc detected *** /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd: corrupted double-linked list: 0x000000000d28a430 *** ======= Backtrace: ========= /lib64/libc.so.6[0x38dc06cbb7] /lib64/libc.so.6[0x38dc06ee92] /lib64/libc.so.6(__libc_calloc+0x96)[0x38dc070376] /lib64/ld-linux-x86-64.so.2[0x38dbc09c85] /lib64/ld-linux-x86-64.so.2[0x38dbc05abc] /lib64/ld-linux-x86-64.so.2[0x38dbc07cac] /lib64/ld-linux-x86-64.so.2[0x38dbc1088f] /lib64/ld-linux-x86-64.so.2[0x38dbc0cc36] /lib64/ld-linux-x86-64.so.2[0x38dbc1036c] /lib64/libc.so.6[0x38dc101320] /lib64/ld-linux-x86-64.so.2[0x38dbc0cc36] /lib64/libc.so.6(__libc_dlopen_mode+0x47)[0x38dc101487] /lib64/libpthread.so.0[0x38dcc0e40c] /lib64/libpthread.so.0[0x38dcc0e520] /lib64/libpthread.so.0(__pthread_unwind+0x40)[0x38dcc0c430] /lib64/libpthread.so.0[0x38dcc07335] /home/quanah/q/openldap-2.4.12/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2(ldap_pvt_thread_join+0x0)[0x2b537fec7e4a] /home/quanah/q/openldap-2.4.12/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2[0x2b537fec6b9c] /lib64/libpthread.so.0[0x38dcc061b5] /lib64/libc.so.6(clone+0x6d)[0x38dc0cd36d] ======= Memory map: ======== 00400000-00530000 r-xp 00000000 fd:00 32115271 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd 00730000-00739000 rw-p 00130000 fd:00 32115271 /home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd 00739000-0077d000 rw-p 00739000 00:00 0 0ce47000-0de31000 rw-p 0ce47000 00:00 0 40940000-40941000 ---p 40940000 00:00 0 40941000-41141000 rwxp 40941000 00:00 0 41141000-41142000 ---p 41141000 00:00 0 41142000-41942000 rwxp 41142000 00:00 0 41942000-41943000 ---p 41942000 00:00 0 41943000-42143000 rwxp 41943000 00:00 0 42143000-42144000 ---p 42143000 00:00 0 42144000-42944000 rwxp 42144000 00:00 0 42944000-42945000 ---p 42944000 00:00 0 42945000-43145000 rwxp 42945000 00:00 0 43145000-43146000 ---p 43145000 00:00 0 43146000-43946000 rwxp 43146000 00:00 0 43946000-43947000 ---p 43946000 00:00 0 43947000-44147000 rwxp 43947000 00:00 0 44147000-44148000 ---p 44147000 00:00 0 44148000-44948000 rwxp 44148000 00:00 0 44948000-44949000 ---p 44948000 00:00 0 44949000-45149000 rwxp 44949000 00:00 0 45149000-4514a000 ---p 45149000 00:00 0 4514a000-4594a000 rwxp 4514a000 00:00 0 4594a000-4594b000 ---p 4594a000 00:00 0 4594b000-4614b000 rwxp 4594b000 00:00 0 4614b000-4614c000 ---p 4614b000 00:00 0 4614c000-4694c000 rwxp 4614c000 00:00 0 4694c000-4694d000 ---p 4694c000 00:00 0 4694d000-4714d000 rwxp 4694d000 00:00 0 4714d000-4714e000 ---p 4714d000 00:00 0 4714e000-4794e000 rwxp 4714e000 00:00 0 4794e000-4794f000 ---p 4794e000 00:00 0 4794f000-4814f000 rwxp 4794f000 00:00 0 4814f000-48150000 ---p 4814f000 00:00 0 48150000-48950000 rwxp 48150000 00:00 0 48950000-48951000 ---p 48950000 00:00 0 48951000-49151000 rwxp 48951000 00:00 0 38dbc00000-38dbc1a000 r-xp 00000000 fd:00 12026130 /lib64/ld-2.5.so 38dbe19000-38dbe1a000 r--p 00019000 fd:00 12026130 /lib64/ld-2.5.so 38dbe1a000-38dbe1b000 rw-p 0001a000 fd:00 12026130 /lib64/ld-2.5.so 38dc000000-38dc144000 r-xp 00000000 fd:00 12026131 /lib64/libc-2.5.so 38dc144000-38dc344000 ---p 00144000 fd:00 12026131 /lib64/libc-2.5.so 38dc344000-38dc348000 r--p 00144000 fd:00 12026131 /lib64/libc-2.5.so 38dc348000-38dc349000 rw-p 00148000 fd:00 12026131 /lib64/libc-2.5.so 38dc349000-38dc34e000 rw-p 38dc349000 00:00 0 38dc400000-38dc402000 r-xp 00000000 fd:00 12026132 /lib64/libdl-2.5.so 38dc402000-38dc602000 ---p 00002000 fd:00 12026132 /lib64/libdl-2.5.so 38dc602000-38dc603000 r--p 00002000 fd:00 12026132 /lib64/libdl-2.5.so 38dc603000-38dc604000 rw-p 00003000 fd:00 12026132 /lib64/libdl-2.5.so 38dcc00000-38dcc15000 r-xp 00000000 fd:00 12026136 Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 6, Aborted. #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 #2 0x00000038dc0674cb in __libc_message () from /lib64/libc.so.6 #3 0x00000038dc06cbb7 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000038dc06ee92 in _int_malloc () from /lib64/libc.so.6 #5 0x00000038dc070376 in calloc () from /lib64/libc.so.6 #6 0x00000038dbc09c85 in _dl_new_object () from /lib64/ld-linux-x86-64.so.2 #7 0x00000038dbc05abc in _dl_map_object_from_fd () from /lib64/ld-linux-x86-64.so.2 #8 0x00000038dbc07cac in _dl_map_object () from /lib64/ld-linux-x86-64.so.2 #9 0x00000038dbc1088f in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #10 0x00000038dbc0cc36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #11 0x00000038dbc1036c in _dl_open () from /lib64/ld-linux-x86-64.so.2 #12 0x00000038dc101320 in do_dlopen () from /lib64/libc.so.6 #13 0x00000038dbc0cc36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #14 0x00000038dc101487 in __libc_dlopen_mode () from /lib64/libc.so.6 #15 0x00000038dcc0e40c in pthread_cancel_init () from /lib64/libpthread.so.0 #16 0x00000038dcc0e520 in _Unwind_ForcedUnwind () from /lib64/libpthread.so.0 #17 0x00000038dcc0c430 in __pthread_unwind () from /lib64/libpthread.so.0 #18 0x00000038dcc07335 in pthread_exit () from /lib64/libpthread.so.0 #19 0x00002b537fec7e4a in ldap_pvt_thread_exit (retval=0x0) at thr_posix.c:186 #20 0x00002b537fec6b9c in ldap_int_thread_pool_wrapper (xpool=0xce75610) at tpool.c:691 #21 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #22 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #23 0x0000000000000000 in ?? () -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5686) OpenLDAP build broken for solaris 64bit
by h.b.furuseth＠usit.uio.no 05 Sep '08

05 Sep '08

quanah(a)zimbra.com writes: > Sounds like a broken release of libtool to me. i.e., I don't see > anything here that's an openldap specific issue. I'd advise examining > your tool chain. Hm? libtool is built from build/ltmain.sh + build/config.* bundled with OpenLDAP. And it's quite old. If that's failing, it needs an upgrade in OpenLDAP. I looked at it once but couldn't test a fresh libtool + autotools on more than one or two hosts. And the current installation uses some patches form the standar dlibtool distribution which I don't know what do. I don't remember what came of it. Anyway, it might be a fix to try libtoolize --copy --force aclocal autoconf with later versions of autotools (autoconf, automake, libtool). -- Hallvard

1 0

Re: (ITS#5686) OpenLDAP build broken for solaris 64bit
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Friday, September 05, 2008 3:37 PM +0000 cwf-ml(a)arcor.de wrote: > Full_Name: Christoph Weber-Fahr > Version: openldap-2.4.11 > OS: Solaris 9 (SunOS ldapsun 5.9 Generic_122300-06 sun4u sparc > SUNW,Sun-Blade-100) URL: > Submission from: (NULL) (145.253.3.244) > > > Machine has gcc (3.4.6) and gnu binutils from sunfreeware installed (plus > a few other things) Sounds like a broken release of libtool to me. i.e., I don't see anything here that's an openldap specific issue. I'd advise examining your tool chain. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5687) corrupted double-linked list on shutdown
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 9/3/2008 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) While running make test, I killed test039, and on shutdown got: PID=10403 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=James*)" attrs=cn (more...). make[2]: *** [hdb-mod] Interrupt make[1]: *** [test] Interrupt make: *** [test] Interrupt [quanah@tribes openldap-2.4.12]$ *** glibc detected *** corrupted double-linked list: 0x0000003bf99316b8 *** So it looks like there's a cleanup issue on shutdown.

1 0

Re: (ITS#5685) slapd segfault
by quanah＠zimbra.com 05 Sep '08

05 Sep '08

--On Friday, September 05, 2008 9:03 AM +0000 Claude.lecommandeur(a)epfl.ch wrote: > Full_Name: Claude Lecommandeur > Version: 2.2.13 > OS: Redhat AS4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.178.1.102) Slurpd was deprecated with OpenLDAP 2.3, and removed from OpenLDAP 2.4, the current stable release. I advise upgrading to a current supported release. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5686) OpenLDAP build broken for solaris 64bit
by cwf-ml＠arcor.de 05 Sep '08

05 Sep '08

added info: here's what test Nr 50 shows: >>>>> ./scripts/test049-sync-config completed OK. >>>>> Starting test050-syncrepl-multimaster ... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... 8346 Abort - core dumped 8342 Abort - core dumped 8338 Abort - core dumped Using ldapadd to populate consumer... ldapadd failed for consumer database (255)! ./scripts/test050-syncrepl-multimaster: kill: no such process ./scripts/test050-syncrepl-multimaster: kill: no such process ./scripts/test050-syncrepl-multimaster: kill: no such process >>>>> ./scripts/test050-syncrepl-multimaster failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/usr/local/src/openldap-2.4.11/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/local/src/openldap-2.4.11/tests' make: *** [test] Error 2

1 0

(ITS#5686) OpenLDAP build broken for solaris 64bit
by cwf-ml＠arcor.de 05 Sep '08

05 Sep '08

Full_Name: Christoph Weber-Fahr Version: openldap-2.4.11 OS: Solaris 9 (SunOS ldapsun 5.9 Generic_122300-06 sun4u sparc SUNW,Sun-Blade-100) URL: Submission from: (NULL) (145.253.3.244) Machine has gcc (3.4.6) and gnu binutils from sunfreeware installed (plus a few other things) I built Openssl and BerkeleyDB in 64bit mode. I then built openldap with the following commands: LD_LIBRARY_PATH='/usr/local/lib/sparcv9:/usr/local/lib' export LD_LIBRARY_PATH sh configure \ --prefix="/usr/local" \ --disable-ipv6 \ --without-threads \ --with-tls=openssl \ --without-cyrus-sasl \ CC=/usr/local/bin/gcc \ CPP=/usr/local/bin/cpp \ LDFLAGS="-m64 -ldl" \ CFLAGS="-m64 -I/usr/local/include -I/usr/local/ssl/include/openssl" make depend make make install All commands finish. But: - make test fails in test50 (core dump) - after installation each installed executable (including slapd) is larger than 8GB in size. None of them is executable on my machine - I get an immediate "Killed" from Solaris, presumably because the virtual memory is less than 8GB. The same executables in the build directory look just fine, slapd e.g. is ~2.8M ldapsun# [openldap-2.4.11] ll /usr/local/bin/lda* lrwxrwxrwx 1 root other 10 Sep 5 16:46 /usr/local/bin/ldapadd -> ldapmodify* -rwxr-xr-x 1 root other 8591909768 Sep 5 16:46 /usr/local/bin/ldapcompare* -rwxr-xr-x 1 root other 8591911360 Sep 5 16:46 /usr/local/bin/ldapdelete* -rwxr-xr-x 1 root other 8591912304 Sep 5 16:46 /usr/local/bin/ldapexop* -rwxr-xr-x 1 root other 8591959528 Sep 5 16:46 /usr/local/bin/ldapmodify* -rwxr-xr-x 1 root other 8591909816 Sep 5 16:46 /usr/local/bin/ldapmodrdn* -rwxr-xr-x 1 root other 8591908712 Sep 5 16:46 /usr/local/bin/ldappasswd* -rwxr-xr-x 1 root other 8591987184 Sep 5 16:46 /usr/local/bin/ldapsearch* -rwxr-xr-x 1 root other 8591901960 Sep 5 16:46 /usr/local/bin/ldapwhoami* ldapsun# [openldap-2.4.11] ls -l clients/tools/lda* | /usr/xpg4/bin/grep -E -v '(\.o$|\.c$)' -rwxr-xr-x 1 root other 512280 Sep 5 16:40 clients/tools/ldapcompare -rwxr-xr-x 1 root other 513120 Sep 5 16:40 clients/tools/ldapdelete -rwxr-xr-x 1 root other 513600 Sep 5 16:40 clients/tools/ldapexop -rwxr-xr-x 1 root other 538960 Sep 5 16:40 clients/tools/ldapmodify -rwxr-xr-x 1 root other 512424 Sep 5 16:40 clients/tools/ldapmodrdn -rwxr-xr-x 1 root other 511568 Sep 5 16:40 clients/tools/ldappasswd -rwxr-xr-x 1 root other 553352 Sep 5 16:40 clients/tools/ldapsearch -rwxr-xr-x 1 root other 508240 Sep 5 16:40 clients/tools/ldapwhoami ldapsun# [openldap-2.4.11] ll /usr/local/libexec/slapd -rwxr-xr-x 1 root other 8596439592 Sep 5 16:46 /usr/local/libexec/slapd* ldapsun# [openldap-2.4.11] ll servers/slapd/slapd -rwxr-xr-x 1 root other 2896576 Sep 5 16:44 servers/slapd/slapd* Let me know if you need more info on this

1 0

Re: (ITS#5659) patch for collect overlay
by brett.maxfield＠gmail.com 05 Sep '08

05 Sep '08

New patch provided, in ftp incoming/brett-maxfield-080906.patch which fixes a problem when virtual attributes of a child entry are written to. Previous patch does not deal with this consequence, and updates the parent entry instead (bad) New patch returns UnwillingToPerform with a meaningful text error, for virtual attributes on child entries, which is a better option.

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by michael＠stroeder.com 05 Sep '08

05 Sep '08

mgwin(a)escp-eap.net wrote: > Replication of our ldap database often stops working, with pending changes > stacking up and not getting processed by slurpd. /var/lib/ldap/replog (as > configured in slapd.conf by the "replog" directive) fills up with entries, and > slurpd doesn't pick up on them. That's pretty much the reason why syncrepl was invented/implemented in OpenLDAP 2.2 and slurpd is deprecated and abandoned from 2.4. http://www.openldap.org/doc/admin24/replication.html Likely everybody here will simply recommend to migrate to syncrepl. Ciao, Michael.

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ali.pouya＠free.fr 05 Sep '08

05 Sep '08

Pierangelo Masarati wrote : > Well, going back to your initial posting, I think you are somehow > correct. ... So I will use the simple configuration (only one syncrepl directive) for my production site. ..... > I set up a test system with > your configuration, and loaded it very heavily, while running the server > that's supposed to screw up under valgrind. I haven't seen any issue > yet, though. Neither me : When I run slapd with valgrind I cannot reproduce the problem ! Also if I run slap with detailed log I cannot reproduce it. Both cases slow down slapd ! Isn't this a problem of simultaneous (concurrent) access to the contextCSN memory zone ? I will be on vacation for two weeks. Thanks for your help. Best Regards Ali

1 0

(ITS#5685) slapd segfault
by Claude.lecommandeur＠epfl.ch 05 Sep '08

05 Sep '08

Full_Name: Claude Lecommandeur Version: 2.2.13 OS: Redhat AS4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.178.1.102) Hi, slapd segfault on search with a very long filter. /var/log/nessages says : Sep 5 10:50:44 cognac5-mgr kernel: slapd[22263]: segfault at 0000002a978e2000 rip 0000002a96290746 rsp 00000000407ff290 error 6 gdb says : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082136928 (LWP 22263)] 0x0000002a96290746 in _IO_default_xsputn_internal () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000002a96290746 in _IO_default_xsputn_internal () from /lib64/tls/libc.so.6 #1 0x0000002a9626d06b in vfprintf () from /lib64/tls/libc.so.6 #2 0x0000002a9628c794 in vsnprintf () from /lib64/tls/libc.so.6 #3 0x0000002a962726b1 in snprintf () from /lib64/tls/libc.so.6 #4 0x000000552aadbd2e in filter2bv_x (op=0x2a99fc76a0, f=Variable "f" is not available. ) at ../../../servers/slapd/filter.c:852 #5 0x000000552aadbce2 in filter2bv_x (op=0x2a99fc76a0, f=Variable "f" is not available. ) at ../../../servers/slapd/filter.c:846 #6 0x000000552aad99e2 in do_search (op=0x2a99fc76a0, rs=0x40800d70) at ../../../servers/slapd/search.c:158 #7 0x000000552aad91b6 in connection_operation (ctx=0x40800e20, arg_v=0x2a99fc76a0) at ../../../servers/slapd/connection.c:1042 #8 0x000000552ab7f44b in ldap_int_thread_pool_wrapper (xpool=Variable "xpool" is not available. ) at ../../../libraries/libldap_r/tpool.c:467 #9 0x0000002a95f0e137 in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000002a962f3883 in clone () from /lib64/tls/libc.so.6 I am on holliday next week but will be happy to answer questions when I returns. Claude.

1 0

Re: (ITS#5545) Inconsistency in multi-master setup
by ghenry＠suretecsystems.com 04 Sep '08

04 Sep '08

ST(a)itsc.cuhk.edu.hk wrote: > Oops, I tested on both nodes, which is not supposed to do so in > mirrormode, right? Sorry for the trouble caused. > > Thanks. > > Not at the same time, no. The point is to have one node available to the clients at one time and the other in hot standby, whereby your network infrastructure redirects clients if one node goes down etc. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

(ITS#5684) slapd crashes when adding entries do cn=config with a too large index
by rhafer＠suse.de 04 Sep '08

04 Sep '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.240.108) slapd crashes when trying to add an indexed entry to cn=config with an index larger than the number of sibling entries. E.g. when you have to entries below cn=schema,cn=config (with index {0} an {1}) and try to add cn={3}myschema,cn=schema,... slapd dumps core. I am currently testing a fix that just adjusts the index of the new entry to match the number of sibilings. (Another option would be to error out).

1 0

(ITS#5683) Don't leak syntax oid macro in case of duplicate attribute
by ando＠sys-net.it 04 Sep '08

04 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p.

1 0

Re: (ITS#5682) Undef objectClass soc_cname not NUL-terminated
by ando＠sys-net.it 04 Sep '08

04 Sep '08

ando(a)sys-net.it wrote: > The soc_cname of undefined objectClasses generated by oc_bvfind_undef() is not > NUL-terminated. A recent commit, where a string-based function operated on it > unvealed the issue. Fixing... For the records: spotted by valgrind. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5682) Undef objectClass soc_cname not NUL-terminated
by ando＠sys-net.it 04 Sep '08

04 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando The soc_cname of undefined objectClasses generated by oc_bvfind_undef() is not NUL-terminated. A recent commit, where a string-based function operated on it unvealed the issue. Fixing... p.

1 0

Re: (ITS#5680) pcache not returning cached entries
by hyc＠symas.com 04 Sep '08

04 Sep '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >>>>> The backend server is a Novell eDirectory and the proxy don't have >>>>> information about the complete schema. >>>> I suspect the remote server is returning an objectClass that is unknown >>>> to the proxy; for example, ndsLoginProperties. So, not ours :) >>> I could reproduce the issue by caching an entry with an objectClass not >>> known to the proxy :). So the "right" solution consists in fixing the >>> proxy's schema. Of course, OpenLDAP could inform the proxy >>> administrator with some intelligible message or, even better, try to >>> repair itself (e.g. by checking the remote server's subschemaSubentry). >>> >> Probably not a good idea to do that automagically. Perhaps with a config >> switch. > > Right. I'll fix it. Actually... I think the original patch was fine. I meant, checking the remote server's subschema should be optional... ;) > >> Also, not a good idea to import miscellaneous foreign schema globally; >> we should implement per-database schema instead. > > I think per-database subschema has been on the todolist since ever or so :) And now we have another reason to do it. -- -- 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#5680) pcache not returning cached entries
by ando＠sys-net.it 04 Sep '08

04 Sep '08

Howard Chu wrote: >> Right. I'll fix it. > > Actually... I think the original patch was fine. I meant, checking the > remote server's subschema should be optional... ;) Too late :) well, I don't like too much the idea of having yet another fine-tune parameter in config, but this change could impact users that need to proxy well-configured systems and, say, cache entries with huge member lists or so... so better make diversion from original behavior optional, if the original behavior is safe in sane setups. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5681) canonicalize undef objectClass names?
by ando＠sys-net.it 04 Sep '08

04 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Currently, slapd canonicalizes undef (or proxied) attribute names by making them uppercased. It should do the same with undef objectClass names. A patch is coming. p.

1 0

Re: (ITS#5680) pcache not returning cached entries
by ando＠sys-net.it 04 Sep '08

04 Sep '08

hyc(a)symas.com wrote: >>>> The backend server is a Novell eDirectory and the proxy don't have >>>> information about the complete schema. >>> I suspect the remote server is returning an objectClass that is unknown >>> to the proxy; for example, ndsLoginProperties. So, not ours :) >> I could reproduce the issue by caching an entry with an objectClass not >> known to the proxy :). So the "right" solution consists in fixing the >> proxy's schema. Of course, OpenLDAP could inform the proxy >> administrator with some intelligible message or, even better, try to >> repair itself (e.g. by checking the remote server's subschemaSubentry). >> > Probably not a good idea to do that automagically. Perhaps with a config > switch. Right. I'll fix it. > Also, not a good idea to import miscellaneous foreign schema globally; > we should implement per-database schema instead. I think per-database subschema has been on the todolist since ever or so :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5680) pcache not returning cached entries
by hyc＠symas.com 04 Sep '08

04 Sep '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> quanah(a)zimbra.com wrote: >> >>> test_filter returned LDAP_INVALID_SYNTAX. >> I think the culprit of the issue is here ^^^ >> >> > | dn: cn=blank,o=Example >> > | queryId: c975e84a-0e16-102d-8355-4be7c415200f >> > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d >> > | objectClass: inetOrgPerson >> > | objectClass: organizationalPerson >> > | objectClass: person >> > | objectClass: ndsLoginProperties >> > | objectClass: top >> > >>> The backend server is a Novell eDirectory and the proxy don't have >>> information about the complete schema. >> I suspect the remote server is returning an objectClass that is unknown >> to the proxy; for example, ndsLoginProperties. So, not ours :) > > I could reproduce the issue by caching an entry with an objectClass not > known to the proxy :). So the "right" solution consists in fixing the > proxy's schema. Of course, OpenLDAP could inform the proxy > administrator with some intelligible message or, even better, try to > repair itself (e.g. by checking the remote server's subschemaSubentry). > Probably not a good idea to do that automagically. Perhaps with a config switch. Also, not a good idea to import miscellaneous foreign schema globally; we should implement per-database schema instead. -- -- 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#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

Probably, a more consistent behavior would be to refuse caching queries containing entries that do not pass normalization. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> test_filter returned LDAP_INVALID_SYNTAX. > > I think the culprit of the issue is here ^^^ > > > | dn: cn=blank,o=Example > > | queryId: c975e84a-0e16-102d-8355-4be7c415200f > > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d > > | objectClass: inetOrgPerson > > | objectClass: organizationalPerson > > | objectClass: person > > | objectClass: ndsLoginProperties > > | objectClass: top > > >> The backend server is a Novell eDirectory and the proxy don't have >> information about the complete schema. > > I suspect the remote server is returning an objectClass that is unknown > to the proxy; for example, ndsLoginProperties. So, not ours :) I could reproduce the issue by caching an entry with an objectClass not known to the proxy :). So the "right" solution consists in fixing the proxy's schema. Of course, OpenLDAP could inform the proxy administrator with some intelligible message or, even better, try to repair itself (e.g. by checking the remote server's subschemaSubentry). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

quanah(a)zimbra.com wrote: > test_filter returned LDAP_INVALID_SYNTAX. I think the culprit of the issue is here ^^^ > | dn: cn=blank,o=Example > | queryId: c975e84a-0e16-102d-8355-4be7c415200f > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d > | objectClass: inetOrgPerson > | objectClass: organizationalPerson > | objectClass: person > | objectClass: ndsLoginProperties > | objectClass: top > > The backend server is a Novell eDirectory and the proxy don't have > information about the complete schema. I suspect the remote server is returning an objectClass that is unknown to the proxy; for example, ndsLoginProperties. So, not ours :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs