- openldap-bugs - openldap.org

Re: (ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by jsynacek＠redhat.com 27 Apr '15

27 Apr '15

Howard Chu <hyc(a)symas.com> writes: > Jan Synacek wrote: >> Howard Chu <hyc(a)symas.com> writes: >> >>> jsynacek(a)redhat.com wrote: >>>> Full_Name: Jan Synacek >>>> Version: master >>>> OS: GNU/Linux >>>> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… >>>> Submission from: (NULL) (213.175.37.10) >>>> >>>> >>>> When using the perl backend, slaptest doesn't convert perlModuleConfig lines >>>> from slapd.conf to slapd.d. >>>> >>>> A simple reproducer can be found at >>>> https://jsynacek.fedorapeople.org/openldap/back-perl.sh >>>> >>>> >>> Thanks, added to git master >> >> I misunderstood the semantics of perlModuleConfig when given multiple >> arguments, so the patch isn't quite correct. I'm sorry for the >> confusion. The fix can be found at: >> >> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150424-More-for-ITS-8… >> >> Please note that I'm not aware of any internal functions that I can use >> to flatten a list of strings. If there are some, or if there is a better >> way to fix the issue, please advice, I'll simplify the patch. >> > Hi Jan, there's no need to muck with the list of strings, just use > c->line instead of c->argv. Thank you for your advice! I've simplified the patch (url stays the same). Cheers, -- Jan Synacek Software Engineer, Red Hat

1 0

(ITS#8114) [WIP] WiredTiger Backend for OpenLDAP
by hamano＠osstech.co.jp 27 Apr '15

27 Apr '15

Full_Name: HAMANO Tsukasa Version: master OS: Linux URL: https://www.osstech.co.jp/download/hamano/openldap/0001-OpenLDAP-WiredTiger… Submission from: (NULL) (183.77.250.155) The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by HAMANO Tsukasa <hamano(a)osstech.co.jp>. I have not assigned rights and/or interest in this work to any party. Copyright 2015 HAMANO Tsukasa <hamano(a)osstech.co.jp> Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by hyc＠symas.com 25 Apr '15

25 Apr '15

Pavel Kraynyukhov wrote: > Hello Howard, > Please accept my apologies, the issue was not related to LMDB. There > have been a data race in my code that was only triggered by fast writes. > Sorry for late answer, - your e-mail landed into the spam-folder, and I > just found it. > > With best regards, > Pavel. OK, thanks for the reply, closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by pk＠dbic.pro 25 Apr '15

25 Apr '15

--90e6ba3fd5fbb4dffe05148bbe0e Content-Type: text/plain; charset=UTF-8 Hello Howard, Please accept my apologies, the issue was not related to LMDB. There have been a data race in my code that was only triggered by fast writes. Sorry for late answer, - your e-mail landed into the spam-folder, and I just found it. With best regards, Pavel. 2015-04-16 8:04 GMT+06:00 Howard Chu <hyc(a)symas.com>: > pk(a)dbic.pro wrote: > >> Full_Name: Pavel Kraynyukhov >> Version: only LMDB from git and lmdb-0.9.14 >> OS: Gentoo Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (37.99.47.171) >> >> >> Hello there, I have ran into an issue with LMDB, which I can reproduce at >> will, >> but it seems a specific one. The git commit is >> 3368d1f5e243225cba4d730fba19ff600798ebe3 >> And this commit and my issue seems to be related. >> >> 1. I use MDB_NOTLS flag on environment open. >> 2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is >> stuck >> after several transactions (writer thread backtrace): >> > > P.S. tested against system provided lmdb version 0.9.14 and result is the >> same. >> So this maybe not related to latest commit in git. >> > > If you're having this problem in 0.9.14 then it is certainly not related > to 3368d1f5e243225cba4d730fba19ff600798ebe3. > > You confirm that the issue does not occur in 0.9.13? Can you upload a test > case demonstrating the problem? > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --90e6ba3fd5fbb4dffe05148bbe0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div><div>Hello Howard,<br></div>Please accept m= y apologies, the issue was not related to LMDB. There have been a data race= in my code that was only triggered by fast writes.<br></div>Sorry for late= answer, - your e-mail landed into the spam-folder, and I just found it.<br= ><br></div>With best regards,<br></div>Pavel.<br><div><div><div><div><div c= lass=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-04-16 8:04 GMT+06:= 00 Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span>:<br><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= ><a href=3D"mailto:pk@dbic.pro" target=3D"_blank">pk(a)dbic.pro</a> wrote:<br= > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Pavel Kraynyukhov<br> Version: only LMDB from git and lmdb-0.9.14<br> OS: Gentoo Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (37.99.47.171)<br> <br> <br> Hello there, I have ran into an issue with LMDB, which I can reproduce at w= ill,<br> but it seems a specific one. The git commit is<br> 3368d1f5e243225cba4d730fba19ff600798ebe3<br> And this commit and my issue seems to be related.<br> <br> 1. I use MDB_NOTLS flag on environment open.<br> 2. if=C2=A0 I use MDB_NOSYNC flag for LMDB environment, the writer thread i= s stuck<br> after several transactions (writer thread backtrace):<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> P.S. tested against system provided lmdb version 0.9.14 and result is the s= ame.<br> So this maybe not related to latest commit in git.<br> </blockquote> <br> If you're having this problem in 0.9.14 then it is certainly not relate= d to 3368d1f5e243225cba4d730fba19ff600798ebe3.<br> <br> You confirm that the issue does not occur in 0.9.13? Can you upload a test = case demonstrating the problem?<span class=3D"HOEnZb"><font color=3D"#88888= 8"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br><br></div></div></div></div></div></di= v> --90e6ba3fd5fbb4dffe05148bbe0e--

1 0

Re: (ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by hyc＠symas.com 24 Apr '15

24 Apr '15

Jan Synacek wrote: > Howard Chu <hyc(a)symas.com> writes: > >> jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: master >>> OS: GNU/Linux >>> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… >>> Submission from: (NULL) (213.175.37.10) >>> >>> >>> When using the perl backend, slaptest doesn't convert perlModuleConfig lines >>> from slapd.conf to slapd.d. >>> >>> A simple reproducer can be found at >>> https://jsynacek.fedorapeople.org/openldap/back-perl.sh >>> >>> >> Thanks, added to git master > > I misunderstood the semantics of perlModuleConfig when given multiple > arguments, so the patch isn't quite correct. I'm sorry for the > confusion. The fix can be found at: > > URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150424-More-for-ITS-8… > > Please note that I'm not aware of any internal functions that I can use > to flatten a list of strings. If there are some, or if there is a better > way to fix the issue, please advice, I'll simplify the patch. > Hi Jan, there's no need to muck with the list of strings, just use c->line instead of c->argv. -- -- 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#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by jsynacek＠redhat.com 24 Apr '15

24 Apr '15

--=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Howard Chu <hyc(a)symas.com> writes: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: master >> OS: GNU/Linux >> URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-p= erl-correctly-convert-perlModuleConfig.patch >> Submission from: (NULL) (213.175.37.10) >> >> >> When using the perl backend, slaptest doesn't convert perlModuleConfig l= ines >> from slapd.conf to slapd.d. >> >> A simple reproducer can be found at >> https://jsynacek.fedorapeople.org/openldap/back-perl.sh >> >> > Thanks, added to git master I misunderstood the semantics of perlModuleConfig when given multiple arguments, so the patch isn't quite correct. I'm sorry for the confusion. The fix can be found at: URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150424-More-for-= ITS-8105.patch Please note that I'm not aware of any internal functions that I can use to flatten a list of strings. If there are some, or if there is a better way to fix the issue, please advice, I'll simplify the patch. =2D-=20 Jan Synacek Software Engineer, Red Hat --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVOi7AAAoJEL3BmMJQOtjBv5cP/12AYektB3N6XsD2HzdBTE8V A0Uc0GuyZ639D0SiqOOFLEIMipgK+O+Qk3viQWnfrlDWvnw1bgDtsKcUAQvgK17N ZxxT5uEFeE+e9AHaWxURNXyFIU3BYY/jxy6evZAuhtOb88Ihigqef/dw3Pcn/4Mr WISwVq82hCCUcz5VDt0Yg9ULsb2xf8GTPd8FD+HI3LwGxF9HNF/bpETAn2b3O/xL hlSy963ZwHYZDsnsOMZdhcWsSQY72Z7vHtTJSauqy8o7iCWv86SB4CFf4Z7iDtDk 4jR/UZe2EwKfHalY1XsU8d0Ijx5HIuN+ffbxnalULfpN7BoqvHK3nph4vJ/JXkUe R1hSk9i1PXrbYMJ8PjvAR/4/CP3rYw9oDdLPi2uhBFegjG9wugi/SVxMs6r/oD0Q ylspwsQF2jiml04OkRy6RvzntB5Y70sekqgjHDQw2uDQwwyQ0sB6kS5IFjNxo5Yh SRC4dTcVLHZ3KYmPcmsLlV8kaZUkiBaT4lipukVwvNXGSm6FjAamsCPCEO9ujutq r0A1/PzA4wj81SCrCDfFmR8/xeQ+XFG2R9rTENFNgJRSJxQSxBIjUPRdugggrh0Z SDELt6oln9OeOaHVKGpePh524zJ7AGMFnEY3C05sUfzFIJ83gBmOFcHDjKVly2/3 qWpOvoEUEJqKm4mO8Zvy =kff0 -----END PGP SIGNATURE----- --=-=-=--

1 0

Re: (ITS#8108) possible bug in slapcat(8)
by igor.shmukler＠gmail.com 23 Apr '15

23 Apr '15

--001a11c1e532dd12d70514602d88 Content-Type: text/plain; charset=UTF-8 Thank you, Howard. You are the best. On Thursday, April 23, 2015, Howard Chu <hyc(a)symas.com> wrote: > igor.shmukler(a)gmail.com wrote: > >> Full_Name: Igor Shmukler >> Version: 2.4 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.146.103.114) >> >> >> I make a use of olcHidden. When set to true, olcHidden breaks slapcat. >> $ sudo slapcat -n 0 >> 5530b282 olcRootPW: value #0: <olcRootPW> can only be set when rootdn >> is under suffix >> 5530b282 config error processing olcDatabase={2}hdb,cn=config: >> <olcRootPW> can only be set when rootdn is under suffix >> slapcat: bad configuration file! >> >> >> Thanks for the report, fixed now in git master. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11c1e532dd12d70514602d88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, Howard. You are the best.<div><br><br>On Thursday, April 23, 201= 5, Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"><a>igor.shmukler(a)gmail.com</a>=C2=A0= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Igor Shmukler<br> Version: 2.4<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (82.146.103.114)<br> <br> <br> I make a use of olcHidden. When set to true, olcHidden breaks slapcat.<br> $ sudo slapcat -n 0<br> 5530b282 olcRootPW: value #0: <olcRootPW> can only be set when rootdn= <br> is under suffix<br> 5530b282 config error processing olcDatabase=3D{2}hdb,cn=3Dconfig:<br> <olcRootPW> can only be set when rootdn is under suffix<br> slapcat: bad configuration file!<br> <br> <br> </blockquote> Thanks for the report, fixed now in git master.<br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </blockquote></div> --001a11c1e532dd12d70514602d88--

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by hyc＠symas.com 23 Apr '15

23 Apr '15

zach(a)puppetlabs.com wrote: > Full_Name: Zach Leslie > Version: 2.4.40-1 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.69.65.15) > > > I have a custom schema that contains a handful of attributeTypes and a few > objectClasses. If I add a new attributeType to the existing schema, and then > attempt to reorder that type, slapd crashes. Starting the service again, slapd > seems to behave normally, and the schema looks intact as it did prior to the > attempted order modification. Did you get a stack trace from the crash? -- -- 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#8111) Re-ordering schema attributeTypes crashes slapd
by hyc＠symas.com 23 Apr '15

23 Apr '15

zach(a)puppetlabs.com wrote: > Below is the attempted ldif modification. > > > dn: cn={5}puppet,cn=schema,cn=config > changetype: modify > replace: olcAttributeTypes For completeness' sake, so we can reproduce this, what was the original content of this schema? -- -- 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#8108) possible bug in slapcat(8)
by hyc＠symas.com 23 Apr '15

23 Apr '15

igor.shmukler(a)gmail.com wrote: > Full_Name: Igor Shmukler > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.146.103.114) > > > I make a use of olcHidden. When set to true, olcHidden breaks slapcat. > $ sudo slapcat -n 0 > 5530b282 olcRootPW: value #0: <olcRootPW> can only be set when rootdn > is under suffix > 5530b282 config error processing olcDatabase={2}hdb,cn=config: > <olcRootPW> can only be set when rootdn is under suffix > slapcat: bad configuration file! > > Thanks for the report, fixed now in git master. -- -- 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#8109) SEGFAULT mdb_cursor_del mdb_cursor_get(MDB_PREV)
by hyc＠symas.com 23 Apr '15

23 Apr '15

rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: LMDB mdb.master > OS: linux > URL: https://gist.github.com/rouzier/2d268a2f24e82e00f498 > Submission from: (NULL) (70.81.32.80) > > > When iterating with a cursor using MDB_PREV and deleting entries using > mdb_cursor_del. > It will crash when calling mdb_cursor_get after the last entry was deleted. > I am using the latest version of LMDB in git. Thanks for the report, fixed now in git. -- -- 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#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by ryan＠nardis.ca 23 Apr '15

23 Apr '15

Got it. ftp://ftp.openldap.org/incoming/20150422_rtandy_ITS-8107-don-t-shadow-rc.pa…

1 0

Re: (ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by ryan＠nardis.ca 23 Apr '15

23 Apr '15

On Sat, Apr 18, 2015 at 10:47:57PM +0000, ryan(a)nardis.ca wrote: >Adding a new group containing a nonexistent member, or or a nonexistent >member to an existing group, triggers the following AddressSanitizer >splat. No error when adding a valid member, or with memberof disabled. That part turned out to be my fault, actually: > #0 0xebdb1e in lutil_strncopy /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317:2 > #1 0xd10adb in mdb_dn2id /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2id.c:360:9 The nonexistent entry I was trying to add was outside the db suffix. Therefore nrlen in mdb_dn2id was wrong (in my specific case, negative) and things got worse from there. Testing with a nonexistent entry under the correct suffix, there are no complaints from AddressSanitizer. The buggy behaviour is still present, however: the member value is added despite returning a 'constraint violation' result.

1 0

(ITS#8113) Missing man page information for ldap_str2dn
by quanah＠openldap.org 23 Apr '15

23 Apr '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) According to a code comment, ldap_explode_rdn is deprecated, and the replacement is ldap_str2dn However, there is no man page info for ldap_str2dn

1 0

Re: (ITS#8112) man pages suggest using deprecated fuctions
by quanah＠zimbra.com 23 Apr '15

23 Apr '15

--On Wednesday, April 22, 2015 11:33 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > ldap_get_dn(3) states that when using the ldap_explode_rdn function, > ldap_value_free can be used to free the results. However, > ldap_value_free is deprecated. According to *some* of the code, ldap_explode_rdn is actually deprecated: ldap_explode_rdn LDAP_P(( /* deprecated, ldap_str2rdn */ However, it is not wrapped in an ifdef for deprecated, nor is it listed as such in the manpage. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8112) man pages suggest using deprecated fuctions
by quanah＠openldap.org 23 Apr '15

23 Apr '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) ldap_get_dn(3) states that when using the ldap_explode_rdn function, ldap_value_free can be used to free the results. However, ldap_value_free is deprecated. Making things worse, it is suggested that the replacement for ldap_value_free is ldap_value_free_len. ldap_value_free_len expects a bval array, whereas ldap_explode_rdn returns a char* array. Finally, if you look at the actual OpenLDAP library code, what is done there is: vv = ldap_explode_rdn( values[ n ], 0 ); LDAP_VFREE( vv ); where: #define LDAP_VFREE(v) (ber_memvfree_x((void **)(v),NULL)) so NEITHER ldap_value_free NOR ldap_value_free_len are even used when using the ldap_explode_rdn function.

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 23 Apr '15

23 Apr '15

I should have noted that this is in a mutli master replication setup where all databases are being replicated, including cn=3Dconfig. --=20 Zach Leslie :: Puppet Labs

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 22 Apr '15

22 Apr '15

Below is the attempted ldif modification. dn: cn={5}puppet,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.4.1.34380.556 NAME ('github' 'githubUsername') DESC 'github' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatc h SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.558 NAME ('pronoun' 'preferredPronou n') DESC 'prefered gender pronoun' EQUALITY caseIgnoreMatch SUBSTR case IgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {3}( 1.3.6.1.4.1.34380.560 NAME 'skills' DESC 'skills, lang uages, specialties' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {4}( 1.3.6.1.4.1.34380.562 NAME 'onCall' DESC 'whether they are oncall or not that week' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.14 66.115.121.1.7 ) olcAttributeTypes: {5}( 1.3.6.1.4.1.34380.563 NAME 'googleGroups' DESC 'email groups they are in' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {6}( 1.3.6.1.4.1.34380.566 NAME 'projects' DESC 'ownership of projects' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {7}( 1.3.6.1.4.1.34380.569 NAME 'interestingFact' DESC 'int eresting fact from first all hands' EQUALITY caseIgnoreMatch SUBSTR caseI gnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {8}( 1.3.6.1.4.1.34380.570 NAME ('twitterHandle' 'twitter') DESC 'twitter handle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {9}( 1.3.6.1.4.1.34380.571 NAME ('ircNickname' 'irc') DESC 'irc nickname' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {10}( 1.3.6.1.4.1.34380.572 NAME 'shirtSize' DESC 'shirtsiz e' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3 .6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {11}( 1.3.6.1.4.1.34380.573 NAME 'dietaryRestrictions' DE SC 'carnivore, omnivore, veg, vegan, glutenfree, soyfree, air free' EQUALIT Y caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.146 6.115.121.1.15 ) olcAttributeTypes: {12}( 1.3.6.1.4.1.34380.567 NAME 'steamAccount' DESC 'ste amaccount for games' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrings Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {13}( 1.3.6.1.4.1.34380.801 NAME 'bribeMeWith' DESC 'thin gs I like' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SY NTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {14}( 1.3.6.1.4.1.34380.802 NAME 'languages' DESC 'what d o you speak' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {15}( 1.3.6.1.4.1.34380.574 NAME 'x-kvm-access' DESC 'kvm access level' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.34380.557 NAME ('forge' 'forgeUsername') DESC 'forge' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - -- Zach Leslie :: Puppet Labs

1 0

(ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 22 Apr '15

22 Apr '15

Full_Name: Zach Leslie Version: 2.4.40-1 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.69.65.15) I have a custom schema that contains a handful of attributeTypes and a few objectClasses. If I add a new attributeType to the existing schema, and then attempt to reorder that type, slapd crashes. Starting the service again, slapd seems to behave normally, and the schema looks intact as it did prior to the attempted order modification.

1 0

Re: (ITS#8008) proxyauth with saslmech EXTERNAL not working
by mathieu.baeumler＠gmail.com 22 Apr '15

22 Apr '15

Hello, just in case someone is still looking on this, I stumbled on the same issue when upgrading openldap from an old version (2.4.2x) to 2.4.40. Used first a debian package, then compiled it myself, same behaviour. However, I managed to make it work by setting explicitly the "override" flag in the chain-idassert-bind parameters ( I'm not sure it's the right way to fix this "issue"): chain-idassert-authzFrom "dn:*" chain-idassert-bind bindmethod=sasl saslmech="EXTERNAL" mode=self flags=override,proxy-authz-critical starttls=critical tls_cacert=/etc/ldap/ssl/CA.pem tls_key=/etc/ldap/ssl/private/key.pem tls_cert=/etc/ldap/ssl/proxy.pem tls_reqcert=demand For those who like the cn=config syntax better: olcDbIDAssertBind: mode=self flags=flags=prescriptive,override,proxy-authz-critical bindmethod=sasl timeout=0 network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0 starttls=critical tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem" tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem" tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand Note: Previous to that, the flags were NOT set explicitly, so the following default values were used: olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=sasl timeout=0 network-timeout=0 saslmech=EXTERNAL keepalive=0:0:0 starttls=critical tls_cert="/opt/SNet/etc/ldap/ssl/proxy.pem" tls_key="/opt/SNet/etc/ldap/ssl/private/key.pem" tls_cacert="/opt/SNet/etc/ldap/ssl/CA.pem" tls_reqcert=demand

1 0

Re: (ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com 21 Apr '15

21 Apr '15

On Tue, Apr 21, 2015 at 12:58 PM, Howard Chu <hyc(a)symas.com> wrote: > > ahochhaus(a)samegoal.com wrote: >> >> Full_Name: Andy >> Version: 2.4.30 >> OS: Debian Linux (Jessie) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (67.188.115.159) >> >> >> Hello, >> >> When connecting over TLS to an LDAP server with high packet loss, my calls to >> ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit >> on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. >> >> I see the following stack trace on the deadlocked process. >> >> @ 0x7f2ff0c0f8d0 (unknown) >> @ 0x7f2ff0c0eac0 __libc_read >> @ 0x5cdc68 sb_debug_read >> @ 0x5c26f5 tlso_bio_read >> @ 0x451b64 BIO_read >> @ 0x49bf86 ssl3_read_n >> @ 0x49d52b ssl3_get_record >> @ 0x49caea ssl3_read_bytes >> @ 0x496f61 ssl3_get_message >> @ 0x496944 ssl3_get_finished >> @ 0x5e4aab ssl3_connect >> @ 0x5e164b ssl23_connect >> @ 0x5c1b3c tlso_session_connect >> @ 0x5b6773 ldap_int_tls_start >> @ 0x5b3a77 ldap_int_open_connection >> @ 0x5a730e ldap_new_connection >> @ 0x5b3365 ldap_open_defconn >> @ 0x5a68e3 ldap_send_initial_request >> @ 0x5a4c1e ldap_sasl_bind >> @ 0x5a4d99 ldap_sasl_bind_s >> >> Inspecting the source, I see that SSL_connect() is called from >> tlso_session_connect(). Does openldap attempt to pass timeout information to >> openssl? >> >> Sorry for the vague bug report. The issue is non-deterministic so it is hard to >> provide too much information. Please let me know what I can do to be more >> helpful. >> >> I was able to find an old posting (from 2006) reporting a similar issue. I'm >> uncertain if the root cause is the same or not though. >> >> http://www.openldap.org/lists/openldap-software/200601/msg00440.html > > > There is no API for setting a timeout in the TLS library. > > http://www.openldap.org/lists/openldap-software/200707/msg00346.html Thanks for the pointer. Feel free to close this issue. -Andy

1 0

Re: (ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by hyc＠symas.com 21 Apr '15

21 Apr '15

ahochhaus(a)samegoal.com wrote: > Full_Name: Andy > Version: 2.4.30 > OS: Debian Linux (Jessie) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.188.115.159) > > > Hello, > > When connecting over TLS to an LDAP server with high packet loss, my calls to > ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit > on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. > > I see the following stack trace on the deadlocked process. > > @ 0x7f2ff0c0f8d0 (unknown) > @ 0x7f2ff0c0eac0 __libc_read > @ 0x5cdc68 sb_debug_read > @ 0x5c26f5 tlso_bio_read > @ 0x451b64 BIO_read > @ 0x49bf86 ssl3_read_n > @ 0x49d52b ssl3_get_record > @ 0x49caea ssl3_read_bytes > @ 0x496f61 ssl3_get_message > @ 0x496944 ssl3_get_finished > @ 0x5e4aab ssl3_connect > @ 0x5e164b ssl23_connect > @ 0x5c1b3c tlso_session_connect > @ 0x5b6773 ldap_int_tls_start > @ 0x5b3a77 ldap_int_open_connection > @ 0x5a730e ldap_new_connection > @ 0x5b3365 ldap_open_defconn > @ 0x5a68e3 ldap_send_initial_request > @ 0x5a4c1e ldap_sasl_bind > @ 0x5a4d99 ldap_sasl_bind_s > > Inspecting the source, I see that SSL_connect() is called from > tlso_session_connect(). Does openldap attempt to pass timeout information to > openssl? > > Sorry for the vague bug report. The issue is non-deterministic so it is hard to > provide too much information. Please let me know what I can do to be more > helpful. > > I was able to find an old posting (from 2006) reporting a similar issue. I'm > uncertain if the root cause is the same or not though. > > http://www.openldap.org/lists/openldap-software/200601/msg00440.html There is no API for setting a timeout in the TLS library. http://www.openldap.org/lists/openldap-software/200707/msg00346.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com 21 Apr '15

21 Apr '15

Full_Name: Andy Version: 2.4.30 OS: Debian Linux (Jessie) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.188.115.159) Hello, When connecting over TLS to an LDAP server with high packet loss, my calls to ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. I see the following stack trace on the deadlocked process. @ 0x7f2ff0c0f8d0 (unknown) @ 0x7f2ff0c0eac0 __libc_read @ 0x5cdc68 sb_debug_read @ 0x5c26f5 tlso_bio_read @ 0x451b64 BIO_read @ 0x49bf86 ssl3_read_n @ 0x49d52b ssl3_get_record @ 0x49caea ssl3_read_bytes @ 0x496f61 ssl3_get_message @ 0x496944 ssl3_get_finished @ 0x5e4aab ssl3_connect @ 0x5e164b ssl23_connect @ 0x5c1b3c tlso_session_connect @ 0x5b6773 ldap_int_tls_start @ 0x5b3a77 ldap_int_open_connection @ 0x5a730e ldap_new_connection @ 0x5b3365 ldap_open_defconn @ 0x5a68e3 ldap_send_initial_request @ 0x5a4c1e ldap_sasl_bind @ 0x5a4d99 ldap_sasl_bind_s Inspecting the source, I see that SSL_connect() is called from tlso_session_connect(). Does openldap attempt to pass timeout information to openssl? Sorry for the vague bug report. The issue is non-deterministic so it is hard to provide too much information. Please let me know what I can do to be more helpful. I was able to find an old posting (from 2006) reporting a similar issue. I'm uncertain if the root cause is the same or not though. http://www.openldap.org/lists/openldap-software/200601/msg00440.html Thanks, -Andy

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 20 Apr '15

20 Apr '15

Good day Michael. I built the branch OPENLDAP_REL_ENG_2_4 revision d281bd3, unfortunately connection 0 still shows up twice. The source code of my test case is here: https://github.com/HouzuoGuo/ldap-conn0 Would you mind to try it out in your test environment? Thanks. Regards, Howard On 10/04/15 15:44, Michael Ströder wrote: > hguo(a)suse.com wrote: >> Is your build identical to the 2.4.40 on OBS in terms of patches/source >> code revision? > > No. It's RE24 with all changes to be released as 2.4.41. > >> What distribution did you use for testing? > > openSUSE Tumbleweed x86_64. > > Ciao, Michael. > .

1 0

Re: (ITS#8095) Patch
by rouzier＠gmail.com 19 Apr '15

19 Apr '15

--047d7bfcf1deec63470514165cd2 Content-Type: text/plain; charset=UTF-8 My Testing does show it is not worth it for the data size in the db. Also there is a race condition using sendfile on linux that could happen. It is avoidable but it would require changes to the protocol to avoid it which I am not willing to do. So dismiss my patch with extreme prejudice On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <hyc(a)symas.com> wrote: > rouzier(a)gmail.com wrote: > >> Full_Name: James Rouzier >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch >> Submission from: (NULL) (192.222.129.11) >> >> >> I am working on a proof of concept of a simple key value store service >> using >> lmdb as the back end. >> I am using sendfile to avoid an extra copy. >> I accomplished this by creating function to extract get the mmap ptr from >> the >> env so I can calculate the offset of data. >> > > I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment > that invites all manner of undetectable/unpreventable corruptions. > > Have you actually measured the performance difference between using > sendfile() here and plain write() or send()? The kernel doesn't physically > copy the written data from user space to kernel space, it just maps in a > particular page. Since LMDB data is already mmap'd, the kernel has very > little work to do since the relevant pages are already present in the > kernel's page tables. > > Ultimately sending data over TCP involves byte-by-byte iteration anyway, > since TCP checksums must be computed on all outgoing data. Doesn't seem to > me like sendfile can be a very significant optimization here. > >> >> I figured that function might be useful to the bigger community. >> >> If it does not fit in the bigger vision of lmdb it is fine not to include >> it. >> >> >> I, James Rouzier, hereby place the following modifications to OpenLDAP >> Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or >> without attribution and/or other notice. >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7bfcf1deec63470514165cd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">My Testing doe= s show it is not worth it for the data size in the db.<br><br><div>Also the= re is a race condition using sendfile on linux that could happen.<br>It is = avoidable but it would require changes to=C2=A0the protocol to avoid it whi= ch I am not willing to do.<br><br>So dismiss my patch with extreme prejudic= e<br><br><br></div></div><div><div><div class=3D"gmail_extra"><br><div clas= s=3D"gmail_quote">On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <span dir=3D= "ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com<= /a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:r= ouzier(a)gmail.com" target=3D"_blank">rouzier(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: James Rouzier<br> Version:<br> OS:<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch"= target=3D"_blank">ftp://ftp.openldap.org/incoming/james-rouzier-150331.pat= ch</a><br> Submission from: (NULL) (192.222.129.11)<br> <br> <br> I am working on a proof of concept of a simple key value store service usin= g<br> lmdb as the back end.<br> I am using sendfile to avoid an extra copy.<br> I accomplished this by creating function to extract get the mmap ptr from t= he<br> env so I can calculate the offset of data.<br> </blockquote> <br> I'm quite reluctant to return the mmap pointer. In a WRITEMAP environme= nt that invites all manner of undetectable/unpreventable corruptions.<br> <br> Have you actually measured the performance difference between using sendfil= e() here and plain write() or send()? The kernel doesn't physically cop= y the written data from user space to kernel space, it just maps in a parti= cular page. Since LMDB data is already mmap'd, the kernel has very litt= le work to do since the relevant pages are already present in the kernel&#3= 9;s page tables.<br> <br> Ultimately sending data over TCP involves byte-by-byte iteration anyway, si= nce TCP checksums must be computed on all outgoing data. Doesn't seem t= o me like sendfile can be a very significant optimization here.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> I figured that function might be useful to the bigger community.<br> <br> If it does not fit in the bigger vision of lmdb it is fine not to include i= t.<br> <br> <br> I, James Rouzier, hereby place the following modifications to OpenLDAP Soft= ware<br> (and only these modifications) into the public domain. Hence, these<br> modifications may be freely used and/or redistributed for any purpose with = or<br> without attribution and/or other notice.<br> <br> <br> <br><span><font color=3D"#888888"> </font></span></blockquote><span><font color=3D"#888888"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> </div></div></div><br></div> --047d7bfcf1deec63470514165cd2--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs