openldap-bugs January 2014

openldap-bugs@openldap.org

23 participants
89 discussions

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by michael＠stroeder.com 10 Jan '14

10 Jan '14

harald.winkelmann(a)bertschinnovation.com wrote: > Debian Wheezy > openldap_2.4.31 Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? Ciao, Michael.

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by harald.winkelmann＠bertschinnovation.com 10 Jan '14

10 Jan '14

--_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, is anybody working on this issue? I've the same problem. I tried the following patch and it works for me. Why isn't it applied here. https://bugs.archlinux.org/task/38137?getfile=3D11329 Debian Wheezy openldap_2.4.31 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_bdb moduleload memberof.la overlay memberof ####################################################################### # Specific Backend Directives for @BACKEND@: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb With friendly regards Harald Winkelmann Software Development DAM Group GmbH Planckstra=DFe 7 88677 Markdorf --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hello,<o:p></o:p> <o:p> </o:p> is anybody working on this issu= e?<o:p></o:p> I’ve the same problem.<o:= p></o:p> I tried the following patch and= it works for me. Why isn’t it applied here.<o:p></o:p> <a href=3D"https://bugs.archlin= ux.org/task/38137?getfile=3D11329">https://bugs.archlinux.org/task/38137?ge= tfile=3D11329</a><o:p></o:p> <o:p> </o:p> Debian Wheezy<o:p></o:p>= openldap_2.4.31<o:p></o:p></spa= n> <o:p> </o:p> # Schema and objectClass defini= tions<o:p></o:p> include    =      /etc/ldap/schema/core.schema<o:p></o:p> include    =      /etc/ldap/schema/cosine.schema<o:p></o:p></= p> include       &nb= sp; /etc/ldap/schema/nis.schema<o:p></o:p> include       &nb= sp; /etc/ldap/schema/inetorgperson.schema<o:p></o:p> <o:p> </o:p> pidfile    =      /var/run/slapd/slapd.pid<o:p></o:p> argsfile   &nbsp= ;    /var/run/slapd/slapd.args<o:p></o:p> loglevel   &nbsp= ;    none<o:p></o:p> <o:p> </o:p> modulepath   &nb= sp;  /usr/lib/ldap<o:p></o:p> moduleload   &nb= sp;  back_bdb<o:p></o:p> moduleload   &nb= sp;  memberof.la<o:p></o:p> overlay memberof<o:p></o:p></sp= an> <o:p> </o:p> ###############################= ########################################<o:p></o:p> # Specific Backend Directives f= or @BACKEND@:<o:p></o:p> # Backend specific directives a= pply to this backend until another<o:p></o:p> # 'backend' directive occurs<o:= p></o:p> backend    =      bdb<o:p></o:p> <o:p> </o:p> <o:p> </o:p> With friendly regards<o:p></o:p></= span> Harald Winkelmann<o:p></o:p></span= > Software Development<o:p></o:p></s= pan> <o:p> </o:p> DAM Group GmbH<o:p></o:p= > Planckstra=DFe 7<o:p></o:p> 88677 Markdorf<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_--

1 0

(ITS#7782) [PATCH] contrib/slapd-modules/**/Makefile: LDAP_BUILD=$(LDAP_SRC) by default
by fumiyas＠osstech.co.jp 10 Jan '14

10 Jan '14

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/0001-contrib-slapd-modules-Makefile-LDAP_BU… Submission from: (NULL) (240b:10:2640:bf0:2268:9dff:fec7:5444) The uploaded patch modifies contrib/slapd-modules/**/Makefile to set LDAP_BUILD to $(LDAP_SRC) by default instead of "../../.." (it's the same value of LDAP_SRC). This is bit useful in some minor situation. e.g., without this patch: make LDAP_SRC=/path/to/openldap-source-dir LDAP_BUILD=/path/to/openldap-source-dir with this patch: make LDAP_SRC=/path/to/openldap-source-dir

1 0

(ITS#7781) constraint_attribute <attr> <size|count> cannot take 0
by fumiyas＠osstech.co.jp 09 Jan '14

09 Jan '14

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/0001-constraint_attribute-attr-size-count-c… Submission from: (NULL) (240b:10:2640:bf0:2268:9dff:fec7:5444) The uploaded patch modifies slapo-constraint for constraint_attribute <attr> <size|count> can take 0. This patch depends on a patch attached in ITS#7780. http://www.openldap.org/its/index.cgi?findid=7780

1 0

(ITS#7780) constraint_attribute <attr> <size|count> 0 cause segfault
by fumiyas＠osstech.co.jp 09 Jan '14

09 Jan '14

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/0001-Fix-segfault-by-constraint_attribute-a… Submission from: (NULL) (240b:10:2640:bf0:2268:9dff:fec7:5444) If slapd.conf has the following config, slapd segfault at startup. overlay constraint constraint_attribute memberUid size 0 # or constraint_attribute memberUid count 0

1 0

Re: (ITS#7771) liblmdb cursor issues
by h.b.furuseth＠usit.uio.no 09 Jan '14

09 Jan '14

Another problem when an xcursor's mc_pg[0] refers to a sub-page but has not been kept updated: The comparison 'mc_pg[i] == mp' below fails and mc_ki[i] does not get modified: if (m3->mc_pg[i] == mp && m3->mc_ki[i] >= mc->mc_ki[i]) { m3->mc_ki[i]++; } Then it's too late to fixup the sub-page pointer later, the xcursor refers to the wrong node in the sub-page. The above code is from mdb_cursor_put(), but there are other similar cases elsewhere. -- Hallvard

1 0

Re: (ITS#7777) Filtering on modifyTimestamp is slower with index
by openldap-technical＠OpenLDAP.org 09 Jan '14

09 Jan '14

This is a cryptographically signed message in MIME format. --------------ms030505010104020400000608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The ITS is not for support requests. You should post things like this on = the openldap-technical mailing list. raphael.ouazana(a)linagora.com wrote: > I have a case where using modifyTimestamp index is far slower than with= no > index. > [..] > '(&(modifyTimestamp>=3D20131023163804Z)(modifyTimestamp<=3D201311231638= 04Z))' You might wanna read this old thread: http://www.openldap.org/lists/openldap-technical/201204/msg00116.html Try to use this filter instead: (&(modifyTimestamp>=3D20131023163804Z)(!(modifyTimestamp>=3D2013112316380= 4Z))) Ciao, Michael. --------------ms030505010104020400000608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5MTUyNjEwWjAj BgkqhkiG9w0BCQQxFgQUhK88KTaaE97cUDowyV4g0ADaD78wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAsCtltB7mwSwYu91VjcKwVRXjP+SKJBXo e2uODXEsak3cHvHzRqvMSGAuj5LYyiLB6zCqJ2ra8MY/JtSI5+o1OHHrNO8kWwlgjaPzwyQo YTMeU9zVFXYiij247Ku1jepUT7WAxxiIjwNLJVt4OjpTmsDeOLG3z9f36bEIZLeaA9Dl5jUv 9m5oAqCZFnDNqVISv9MYAZGU8bB8EkxDb1ArSKt3ANFHL8e2ULYOnwExKgoqMyMPhpoepDhc AlPLktZvyq5Sxp4Y35J6Pw0NgJxExOC+iv03w6bSiAUNbSRBrMPXi2Tew7iCA4+Q87DeY5Nh X2fCUrJoStCDcoTm4Qi4OQAAAAAAAA== --------------ms030505010104020400000608--

1 0

Re: (ITS#7779) Index and derived attribute bug
by yann.cezard＠univ-pau.fr 09 Jan '14

09 Jan '14

Sorry, it's a duplicate (#7778) due to a reload in web browser...

1 0

(ITS#7779) Index and derived attribute bug
by yann.cezard＠univ-pau.fr 09 Jan '14

09 Jan '14

Full_Name: Yann Cezard Version: 2.4.38 OS: Debian GNU/Linux Wheezy / amd64 URL: ftp://ftp.openldap.org/incoming/Yann-Cezard-130109.tgz Submission from: (NULL) (2001:660:6701:14:225:64ff:fe92:685b) Hello, I hit a bug with the latest version of OpenLDAP (2.4.38) that was not present, at least in 2.4.17 (made a test on an older server that we were using before I discovered this). This happens on both lmdb and bdb backend (as we were using BDB before upgrading to 2.4.38, I tested with both on 2.4.38 to ensure that the problem was not LMDB related). The problem shows up when you delete the last attribute of en entry, which is derived from another attribute, which has an index on it (not easy to explain...). As an example (complete LDIF files - config/schema + data - provided on the incoming FTP), considering an attribute that is derived from the 'mail' attribute (which is defined in core.schema, and used in InetOrgPerson) : attributetype ( 1.3.6.1.4.1.7135.1.2.1.34 NAME 'supannAutreMail' DESC 'adresses mail non institutionnelles' SUP mail ) and an associated objectClass that use it (called supannPerson in the next example). Now place an index on mail : olcDbIndex: mail pres,eq,sub Now with an entry like this : dn: uid=test,ou=users,dc=example,dc=com uid: test sn: Test cn: Test objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: supannPerson structuralObjectClass: inetOrgPerson entryUUID: 2699b5b4-0d7c-1033-9546-613643720ad1 creatorsName: cn=root,dc=example,dc=com createTimestamp: 20140109131736Z mail: test(a)example.com supannAutreMail: root(a)example.com supannAutreMail: user.test(a)example.com If you make a search with '(mail=*)', the entry matches : ############# $ ldapsearch -x -h ldap-test -b ou=users,dc=example,dc=com -D cn=root,dc=example,dc=com -w test -s one '(mail=*)' dn # extended LDIF # # LDAPv3 # base <ou=users,dc=example,dc=com> with scope oneLevel # filter: (mail=*) # requesting: dn # # test, users, example.com dn: uid=test,ou=users,dc=example,dc=com # search result search: 2 result: 0 Success ############## That's pretty normal. Now, remove both the supannAutreMail attributes from the entry. Run the same ldapsearch : ############## $ ldapsearch -x -h ldap-test -b ou=users,dc=example,dc=com -D cn=root,dc=example,dc=com -w test -s one '(mail=*)' dn # extended LDIF # # LDAPv3 # base <ou=users,dc=example,dc=com> with scope oneLevel # filter: (mail=*) # requesting: dn # # search result search: 2 result: 0 Success # numResponses: 1 ############## The entry doesn't match anymore... But still it has a mail attribute : ############## $ ldapsearch -x -h ldap-test -b ou=users,dc=example,dc=com -D cn=root,dc=example,dc=com -w test -s one '(uid=test)' mail # extended LDIF # # LDAPv3 # base <ou=users,dc=example,dc=com> with scope oneLevel # filter: (uid=test) # requesting: mail # # test, users, example.com dn: uid=test,ou=users,dc=example,dc=com mail: test(a)example.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ############## The only ways to make the '(mail=*)' filter matches again the modified entry, is to modify the mail attribute, or to run slapindex. If you remove the index on the mail attribute, then there is no such problem. It only happens when deleting all/the last derived attributes (supannAutreMail here) from the entry. Sounds to me like a bug, isn't it ? Regards.

1 0

(ITS#7778) Index and derived attribute bug
by yann.cezard＠univ-pau.fr 09 Jan '14

09 Jan '14

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2014