openldap-bugs September 2009

openldap-bugs@openldap.org

32 participants
109 discussions

(ITS#6299) Support for RFC 4529 in slapo-allowed
by michael＠stroeder.com 22 Sep '09

22 Sep '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.118.158) If the client wants to request via slapo-allowed which attributes are readable/writeable before adding another object class then object classes not yet part of the entry could be used if the client adds the object class name prefixed with @. This is an extension to the semantics but should not cause any problem with existing clients.

1 0

Re: (ITS#6296) Strong bind doesn't work in slapd-ldap when used by slapd-relay or slapo-translucent
by mrubas＠kerio.com 18 Sep '09

18 Sep '09

This is a multi-part message in MIME format. --------------070504020207040208060908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit So far, it seems to be working. Good job, thanks. It was not easy to get fresh binary because I had to manage compilation with MSVC but that's another issue (ssl3_send_alert() in ITS#1955 & ITS#1954). Thanks again, M. masarati(a)aero.polimi.it wrote: >> I have to use slapd-ldap in "strong bind" mode which means that user >> binds using its own credentials and no identity assertion is performed. >> If slapd-ldap is the only module that is processing request then >> everything works fine. If slapd-ldap is processing an request forwarded >> from slapd-relay (with slapo-rwm) or request to database with >> slapo-translucent then the authentication problem occurs. >> > The solution was a little less intrusive than the one you proposed, but > your analysis was just fine and definitely effective in pointing me to the > core of the issue. It should now be fixed in HEAD, please test. > > servers/slapd/back-ldap/bind.c > new revision: 1.255; previous revision: 1.254 > > Thanks, p. > --------------070504020207040208060908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> So far, it seems to be working. Good job, thanks. It was not easy to get fresh binary because I had to manage compilation with MSVC but that's another issue (ssl3_send_alert() in ITS#1955 & ITS#1954). Thanks again, M. <a class="moz-txt-link-abbreviated" href="mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a> wrote: <blockquote cite="mid:38264.93.149.38.238.1253215000.squirrel@www.aero.polimi.it" type="cite"> <blockquote type="cite"> <pre wrap="">I have to use slapd-ldap in "strong bind" mode which means that user binds using its own credentials and no identity assertion is performed. If slapd-ldap is the only module that is processing request then everything works fine. If slapd-ldap is processing an request forwarded from slapd-relay (with slapo-rwm) or request to database with slapo-translucent then the authentication problem occurs. </pre> </blockquote> <pre wrap="">The solution was a little less intrusive than the one you proposed, but your analysis was just fine and definitely effective in pointing me to the core of the issue. It should now be fixed in HEAD, please test. servers/slapd/back-ldap/bind.c new revision: 1.255; previous revision: 1.254 Thanks, p. </pre> </blockquote> </body> </html> --------------070504020207040208060908--

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 18 Sep '09

18 Sep '09

--00151743f754b6ee3f0473da2c09 Content-Type: text/plain; charset=ISO-8859-1 Aster recompiling OpenLDAP with changes to servers/slapd/back-bdb/idl.h > > #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* moved from 64k to 128K */ #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* moved from 128k to 256k */ I'm unable to reproduce the issue.... it looks like problem solved... time ldapsearch -h localhost -x -b ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w passwd objectClass=originatorPrefixID # extended LDIF # # LDAPv3 # base <ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr> with scope subtree # filter: objectClass=originatorPrefixID # requesting: ALL # <----------------snip--------------------> # 000010, 078120.100.10000.100, 385, bestMatchPrefixList, sipDirektor, ot.hr dn: originatorPrefixID=000010,carrierPrefixID=078120.100.10000.100,bestMatchPr efix=385,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 000010 priority: 100 originator: T-COM/HT originatorPrefixID: 000010 objectClass: top objectClass: originatorPrefixID # search result search: 2 result: 0 Success # numResponses: 84256 # numEntries: 84255 real 0m22.500s user 0m1.635s sys 0m1.671s [tculjaga@l01lnp1 lib]$ [tculjaga@l01lnp1 lib]$ What can we expect as the DB grows? Does it mean i will have to increase the values again? What is the limit and drawback? Tihomir. On Fri, Sep 18, 2009 at 10:10 AM, Tihomir Culjaga <tculjaga(a)gmail.com>wrote: > I'm gonna try this: > > > In the file 'servers/slapd/back-bdb/idl.h': > > #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ > > #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* modified from 64k > to 128K */ > #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* modified from 128k > to 256k */ > > > > i have a question for the line in the file 'include/ldap_pvt_thread.h': > > define LDAP_PVT_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) > > > ehat is sizeof(void *) when i run 64bit OS? > > > > > > On Fri, Sep 18, 2009 at 8:49 AM, Howard Chu <hyc(a)symas.com> wrote: > >> tculjaga(a)gmail.com wrote: >> >>> Full_Name: Tihomir Culjaga >>> Version: 2.4.18 >>> OS: CentOS 5.3 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (93.136.5.55) >>> >> >> commands to perform whole-tree ldapsearch >>> >> >> Note to developers: this description is a red herring. The actual search >> that demonstrates the problem was posted later, here: >> >> http://www.openldap.org/lists/openldap-technical/200909/msg00129.html >> >> ldapsearch -h localhost -x -b >>> ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr >>> -w >>> passwd >>> >>> >>> >>> DB information >>> >>> 3437278 entries >>> >>> du -c -h /var/lib/ldap/*.bdb >>> 204K /var/lib/ldap/bestMatchPrefix.bdb >>> 982M /var/lib/ldap/dn2id.bdb >>> 2.4G /var/lib/ldap/id2entry.bdb >>> 1.9M /var/lib/ldap/objectClass.bdb >>> 1.3M /var/lib/ldap/originatorPrefixID.bdb >>> 48M /var/lib/ldap/uniqueID.bdb >>> 3.4G total >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --00151743f754b6ee3f0473da2c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aster recompiling OpenLDAP with changes to servers/slapd/back-bdb/idl.h<blo= ckquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204,= 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"></blockquote> #def= ine BDB_IDL_LOGN=A0=A0=A0 16=A0=A0=A0=A0=A0 /* DB_SIZE is 2^16, UM_SIZE is = 2^17 */ #define BDB_IDL_DB_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN= +1)) /* moved from 64k to 128K */ #define BDB_IDL_UM_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+2))= /* moved from 128k to 256k */ I'm unable to reproduce the i= ssue.... it looks like problem solved... time ldapsearch=A0 -h l= ocalhost -x -b ou=3DbestMatchPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr=A0= -D cn=3Dadmin,dc=3Dot,dc=3Dhr -w passwd objectClass=3DoriginatorPrefixID<b= r> # extended LDIF # # LDAPv3 # base <ou=3DbestMatchPrefixList,ou= =3DsipDirektor,dc=3Dot,dc=3Dhr> with scope subtree # filter: objectCl= ass=3DoriginatorPrefixID # requesting: ALL # <-------------= ---snip--------------------> # 000010, 078120.100.10000.100, 385, bestMatchPrefixList, sipDirektor, = <a href=3D"http://ot.hr">ot.hr</a> dn: originatorPrefixID=3D000010,carri= erPrefixID=3D078120.100.10000.100,bestMatchPr =A0efix=3D385,ou=3DbestMat= chPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr originatorPrefix: 000010 priority: 100 originator: T-COM/HT origin= atorPrefixID: 000010 objectClass: top objectClass: originatorPrefixID= # search result search: 2 result: 0 Success # numRespo= nses: 84256 # numEntries: 84255 real=A0=A0=A0 0m22.500s user=A0=A0=A0 0m1.635= s sys=A0=A0=A0=A0 0m1.671s [tculjaga@l01lnp1 lib]$ [tculjaga@l01l= np1 lib]$ What can we expect as the DB grows? Does it mean i wi= ll have to increase the values again? What is the limit and drawback? Tihomir. <div= class=3D"gmail_quote">On Fri, Sep 18, 2009 at 10:10 AM, Tihomir Culjaga <s= pan dir=3D"ltr"><<a href=3D"mailto:tculjaga@gmail.com">tculjaga(a)gmail.co= m</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm gonna try= this: In the file 'servers/slapd/back-bdb/idl.h': <b= r> #define BDB_IDL_LOGN=A0=A0=A0 16=A0=A0=A0=A0=A0 /* DB_SIZE is 2^16, UM_SIZE= is 2^17 */ #define BDB_IDL_DB_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<&l= t;(BDB_IDL_LOGN+1)) /* modified from 64k to 128K */ #define BDB_IDL_UM_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+2))= /* modified from 128k to 256k */ i have a question for the = line in the file 'include/ldap_pvt_thread.h': define LDAP_PV= T_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) ehat is sizeof(void *) when i run 64bit OS?<div><div></div><div cla= ss=3D"h5"> <div class=3D"gmail_quote">On Fri, Sep 18, 20= 09 at 8:49 AM, Howard Chu <<a href=3D"mailto:hyc@symas= .com" target=3D"_blank">hyc(a)symas.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href=3D"mailto= :tculjaga@gmail.com" target=3D"_blank">tculjaga(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Tihomir Culjaga Version: 2.4.18 OS: CentOS 5.3 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (93.136.5.55) </blockquote> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> commands to perform whole-tree ldapsearch </blockquote> Note to developers: this description is a red herring. The actual search th= at demonstrates the problem was posted later, here: <a href=3D"http://www.openldap.org/lists/openldap-technical/200909/msg00129= .html" target=3D"_blank">http://www.openldap.org/lists/openldap-technical/2= 00909/msg00129.html</a> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> =A0 =A0ldapsearch =A0-h localhost -x -b ou=3DbestMatchPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr -D cn=3Dadmin,dc= =3Dot,dc=3Dhr -w passwd DB information 3437278 entries du -c -h /var/lib/ldap/*.bdb =A0 204K /var/lib/ldap/bestMatchPrefix.bdb =A0 982M /var/lib/ldap/dn2id.bdb =A0 2.4G /var/lib/ldap/id2entry.bdb =A0 1.9M /var/lib/ldap/objectClass.bdb =A0 1.3M /var/lib/ldap/originatorPrefixID.bdb =A0 48M =A0/var/lib/ldap/uniqueID.bdb =A0 3.4G total </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </div></div></blockquote></div> --00151743f754b6ee3f0473da2c09--

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 18 Sep '09

18 Sep '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > > Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay > > This should not happen, since your search is performed with exactly the > same parameters used for the original one, and the scope is 1 (onelevel). > > I wonder what happens there. Could you walk through the failing request > with a debugger, and print some values? I'd like to see, from within > bdb_search(), line 780 of back-bdb/search.c of re23, the value of > > op->o_request->oq_search > > base > > *ei->ei_parent > > p. > Hello, I have switched to slapd 2.4.18 (last release) and the problem still pesist. I have made the requested debug session. The relevant log file could be found here: http://purgatory.spnet.net/~karavelov/log The gdb session is here: http://purgatory.spnet.net/~karavelov/debug The configuration file is here: http://purgatory.spnet.net/~karavelov/slapd.conf.clean I have tried without pcacheValidate and pcachePosition options without any difference. Thanks in advance Luben

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 18 Sep '09

18 Sep '09

--000325558fd60e8a6a0473d5abd4 Content-Type: text/plain; charset=ISO-8859-1 I'm gonna try this: In the file 'servers/slapd/back-bdb/idl.h': #define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */ #define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* modified from 64k to 128K */ #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* modified from 128k to 256k */ i have a question for the line in the file 'include/ldap_pvt_thread.h': define LDAP_PVT_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) ehat is sizeof(void *) when i run 64bit OS? On Fri, Sep 18, 2009 at 8:49 AM, Howard Chu <hyc(a)symas.com> wrote: > tculjaga(a)gmail.com wrote: > >> Full_Name: Tihomir Culjaga >> Version: 2.4.18 >> OS: CentOS 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (93.136.5.55) >> > > commands to perform whole-tree ldapsearch >> > > Note to developers: this description is a red herring. The actual search > that demonstrates the problem was posted later, here: > > http://www.openldap.org/lists/openldap-technical/200909/msg00129.html > > ldapsearch -h localhost -x -b >> ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr >> -w >> passwd >> >> >> >> DB information >> >> 3437278 entries >> >> du -c -h /var/lib/ldap/*.bdb >> 204K /var/lib/ldap/bestMatchPrefix.bdb >> 982M /var/lib/ldap/dn2id.bdb >> 2.4G /var/lib/ldap/id2entry.bdb >> 1.9M /var/lib/ldap/objectClass.bdb >> 1.3M /var/lib/ldap/originatorPrefixID.bdb >> 48M /var/lib/ldap/uniqueID.bdb >> 3.4G total >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000325558fd60e8a6a0473d5abd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm gonna try this: In the file 'servers/slapd/back-bdb/= idl.h': #define BDB_IDL_LOGN=A0=A0=A0 16=A0=A0=A0=A0=A0 /* DB_SI= ZE is 2^16, UM_SIZE is 2^17 */ #define BDB_IDL_DB_SIZE=A0=A0=A0=A0= =A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+1)) /* modified from 64k to 128K */<br= > #define BDB_IDL_UM_SIZE=A0=A0=A0=A0=A0=A0=A0=A0 (1<<(BDB_IDL_LOGN+2))= /* modified from 128k to 256k */ i have a question for the = line in the file 'include/ldap_pvt_thread.h': define LDAP_PV= T_THREAD_STACK_SIZE ( 1 * 1024 * 1024 * sizeof(void *) ) ehat is sizeof(void *) when i run 64bit OS? <div= class=3D"gmail_quote">On Fri, Sep 18, 2009 at 8:49 AM, Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>>= wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href=3D"mailto= :tculjaga@gmail.com" target=3D"_blank">tculjaga(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Tihomir Culjaga Version: 2.4.18 OS: CentOS 5.3 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (93.136.5.55) </blockquote> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> commands to perform whole-tree ldapsearch </blockquote> Note to developers: this description is a red herring. The actual search th= at demonstrates the problem was posted later, here: <a href=3D"http://www.openldap.org/lists/openldap-technical/200909/msg00129= .html" target=3D"_blank">http://www.openldap.org/lists/openldap-technical/2= 00909/msg00129.html</a> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> =A0 =A0ldapsearch =A0-h localhost -x -b ou=3DbestMatchPrefixList,ou=3DsipDirektor,dc=3Dot,dc=3Dhr -D cn=3Dadmin,dc= =3Dot,dc=3Dhr -w passwd DB information 3437278 entries du -c -h /var/lib/ldap/*.bdb =A0 204K /var/lib/ldap/bestMatchPrefix.bdb =A0 982M /var/lib/ldap/dn2id.bdb =A0 2.4G /var/lib/ldap/id2entry.bdb =A0 1.9M /var/lib/ldap/objectClass.bdb =A0 1.3M /var/lib/ldap/originatorPrefixID.bdb =A0 48M =A0/var/lib/ldap/uniqueID.bdb =A0 3.4G total </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --000325558fd60e8a6a0473d5abd4--

1 0

Re: (ITS#6298) ldapsearch hangs after ldapadd
by hyc＠symas.com 17 Sep '09

17 Sep '09

tculjaga(a)gmail.com wrote: > Full_Name: Tihomir Culjaga > Version: 2.4.18 > OS: CentOS 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.136.5.55) > commands to perform whole-tree ldapsearch Note to developers: this description is a red herring. The actual search that demonstrates the problem was posted later, here: http://www.openldap.org/lists/openldap-technical/200909/msg00129.html > ldapsearch -h localhost -x -b > ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w > passwd > > > > DB information > > 3437278 entries > > du -c -h /var/lib/ldap/*.bdb > 204K /var/lib/ldap/bestMatchPrefix.bdb > 982M /var/lib/ldap/dn2id.bdb > 2.4G /var/lib/ldap/id2entry.bdb > 1.9M /var/lib/ldap/objectClass.bdb > 1.3M /var/lib/ldap/originatorPrefixID.bdb > 48M /var/lib/ldap/uniqueID.bdb > 3.4G total -- -- 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#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 17 Sep '09

17 Sep '09

--0015175cf9f62a63290473d460e8 Content-Type: text/plain; charset=ISO-8859-1 please find the relevant logs/config/ldifs on ftp://sulaco.optinet.hr bug/bugreport Tihomir. --0015175cf9f62a63290473d460e8 Content-Type: text/html; charset=ISO-8859-1 please find the relevant logs/config/ldifs on <a href="ftp://sulaco.optinet.hr">ftp://sulaco.optinet.hr </a> bug/bugreport Tihomir. --0015175cf9f62a63290473d460e8--

1 0

(ITS#6298) ldapsearch hangs after ldapadd
by tculjaga＠gmail.com 17 Sep '09

17 Sep '09

Full_Name: Tihomir Culjaga Version: 2.4.18 OS: CentOS 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.136.5.55) Hi, i have an issue with ldapsearch. I have a ldif file that i use to recreate the database using slapadd. When this is done, i perform a ldapsearch of an entire tree (~ 100k entries) and this is done in an acceptable time 40 - 60 seconds. After that, i add some more entries (4 of them to be precise) using ldapadd and perform the same whole-tree search. The search works (ldapsearch returning entries) until it reaches the last entry present in the initial ldif file. It hangs here for a while (1 - 10 minutes) and after that returns the remaining 4 entries i've previously added using ldapadd. When doing the 1st ldapsearch, slapd process takes about 30% of total memory. Later, when performing the search again, and when it hangs, slapd process takes 97% of the total system memory. The increased meory usage is noticed when the hang apairs. During this time i see the CPU usage reaching 90% as well. When it finishes, i try to stop & start ldap and i get "FAILED" on stop! /etc/init.d/ldap stop Stopping slapd: [FAILED] sudo /etc/init.d/ldap start Checking configuration files for slapd: bdb_db_open: database "dc=ot,dc=hr": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=ot,dc=hr": recovery skipped in read-only mode. Run manual recovery if errors are encountered. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable config file testing succeeded [ OK ] Starting slapd: [ OK ] [root@l01lnp1 ~]# My enviorment is: /usr/local/sbin/slapd -V @(#) $OpenLDAP: slapd 2.4.18 (Sep 17 2009 10:00:09) $ With Backend BDB db_stat -V Berkeley DB 4.7.25: (May 15, 2008) <= patched with all 4 patches from oracle uname -a Linux l01lnp1 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux cat /etc/issue CentOS release 5.3 (Final) Kernel \r on an \m The machine HW CPU: 2 x Xeon at 3.0 GHz (bogomips: 6000.22) - dualcore RAM: 10 GB HDD: 60 GB SCSI my slapd.conf threads 4 sizelimit unlimited timelimit 3600 database bdb cachesize 7000000 dncachesize 0 idlcachesize 21000000 cachefree 10000 my DB_CONFIG set_cachesize 5 0 1 set_lg_regionmax 262144 set_lg_bsize 2097152 my custom schema sipdirector.schema my ldif file used to recreate the DB all.ldif my ldif file used to load remaining 4 entries test.ldif commands to recreate the DB from ldif file slapadd -f /usr/local/etc/openldap/slapd.conf -l /home/tculjaga/all.ldif commands to add entries with ldapadd ldapadd -h localhost -x -D cn=admin,dc=ot,dc=hr -w passwd -f /home/tculjaga/test.ldif -c commands to perform whole-tree ldapsearch ldapsearch -h localhost -x -b ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w passwd DB information 3437278 entries du -c -h /var/lib/ldap/*.bdb 204K /var/lib/ldap/bestMatchPrefix.bdb 982M /var/lib/ldap/dn2id.bdb 2.4G /var/lib/ldap/id2entry.bdb 1.9M /var/lib/ldap/objectClass.bdb 1.3M /var/lib/ldap/originatorPrefixID.bdb 48M /var/lib/ldap/uniqueID.bdb 3.4G total I have strace logs when i perormed th esearch strace.tar.gz please let me know how can i transfer you the logs and config files. Tihomir.

1 0

Re: (ITS#6296) Strong bind doesn't work in slapd-ldap when used by slapd-relay or slapo-translucent
by masarati＠aero.polimi.it 17 Sep '09

17 Sep '09

> I have to use slapd-ldap in "strong bind" mode which means that user > binds using its own credentials and no identity assertion is performed. > If slapd-ldap is the only module that is processing request then > everything works fine. If slapd-ldap is processing an request forwarded > from slapd-relay (with slapo-rwm) or request to database with > slapo-translucent then the authentication problem occurs. The solution was a little less intrusive than the one you proposed, but your analysis was just fine and definitely effective in pointing me to the core of the issue. It should now be fixed in HEAD, please test. servers/slapd/back-ldap/bind.c new revision: 1.255; previous revision: 1.254 Thanks, p.

1 0

Re: (ITS#6200) slapd crashes under load w/ syncrepl
by imf＠u.washington.edu 17 Sep '09

17 Sep '09

We build with, % CPPFLAGS="-I/usr/local/krb5/include -I/usr/local/include/sasl" \ CFLAGS="-g" ./configure ... % make The 'CFLAGS' environmental will make sure the '-g' is injected into all generated makefiles. You can add -D_GNU_SOURCE there as well. We experienced the problems you described with <2.4.17. 2.4.17 fixed many of the segfault causes. We didn't repeat our stress test with multimaster and 2.4.17+ though, since we determined that deltasync was good enough for our purposes. It may very well be that 2.4.17+ would crash in multimaster mode with our stress test. The traceback you provided looks very similar to what we were seeing. If I have time I could run a test with 2.4.18 and multimaster and see what the results are... --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344 On Thu, 17 Sep 2009, Joacim Breiler wrote: > We are trying out the 2.4.18 release with a syncrepl Multi-Master setup and > are experiencing similar problems as mentioned above. > > It will shut down with a segfault after heavy processing/updating of about > 3000-17000 entries. We can reproduce this in about 10-20 minutes of heavy > load. However, in this short execution time we can't find any signs of memory > leakage. > > Unfortunatly I can't get any good tracebacks from gdb. I've tried compiling > openldap with: > export CPPFLAGS="-D_GNU_SOURCE -g". And also --enable-debug with /configure. > Any pointers? > > This is the traceback I get, but I guess it isn't very helpful without the > complete debugging information: > > (gdb) where > #0 0x00007fc7e24fb8eb in syncprov_op_mod (op=0x7fc7aedb37d0, rs=<value > optimized out>) at syncprov.c:1970 > #1 0x000000000049531a in overlay_op_walk () > #2 0x0000000000495e7a in ?? () > #3 0x000000000044a2e2 in fe_op_modify () > #4 0x000000000044ac67 in do_modify () > #5 0x00000000004321bf in ?? () > #6 0x0000000000432e6c in ?? () > #7 0x00000000004dd960 in ?? () > #8 0x00007fc7e2e9b3ea in start_thread () from /lib/libpthread.so.0 > #9 0x00007fc7e29f3cbd in clone () from /lib/libc.so.6 > #10 0x0000000000000000 in ?? () > (gdb) > > Could these problems be related? And is there something we can do to help > resolve it? > > Regards, > Joacim Breiler > > > > Configuration: > > dn: olcDatabase={1}hdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {1}hdb > olcDbDirectory: /srv/ldap > olcSuffix: dc=hgo,dc=se > olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=hgo, > dc=se" write by anonymous auth by self write by * none > olcLastMod: TRUE > olcRootDN: cn=admin,dc=hgo,dc=se > olcRootPW: xxxxxxxx > olcSizeLimit: -1 > olcSyncrepl: {0}rid=004 provider=ldap://diablo binddn="cn=admin,dc=hgo,dc=se > " bindmethod=simple credentials="xxxxxxx" searchbase="dc=hgo,dc=se" ty > pe=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncrepl: {1}rid=003 provider=ldap://mephisto binddn="cn=admin,dc=hgo,dc= > se" bindmethod=simple credentials="xxxxxxx" searchbase="dc=hgo,dc=se" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcMirrorMode: TRUE > olcDbCheckpoint: 2048 5 > olcDbIDLcacheSize: 90000 > olcDbIndex: objectClass,entryCSN,entryUUID,cn eq > olcDbCacheSize: 10000 > olcDbConfig: {0}set_cachesize 1 0 0 > olcDbConfig: {1}set_lk_max_objects 32000 > olcDbConfig: {2}set_lk_max_locks 32000 > olcDbConfig: {3}set_lk_max_lockers 1500 > olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE > olcDbConfig: {5}set_lg_bsize 104857600 > olcDbConfig: {6}set_lg_dir /srv/ldap > > >

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2009