openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 22 Sep '07

22 Sep '07

Ralf Haferkamp wrote: > On Freitag, 21. September 2007, hyc(a)symas.com wrote: >> rhafer(a)suse.de wrote: >>> Please note that test020 currently fails in HEAD sometime. I think this >>> depends on the order in which the results for queries that hit the >>> sizelimit are returned. >> It seems to be failing for me more often than not. Why is it >> non-deterministic? > It seems that the order in which the entries are inserted into the cache is > non-deterministic. Because of that the order in which they are returned from > cache varies as well. The final test that compares the ldapsearch results > with proxycache.out relies on the order. > > I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log > it seems that sometimes the entries from Query 9 get inserted into the cache > before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology > Division, ...") and sometimes after. Depending on that the test either fails > or succeeds. > OK, I see that as well. In fact setting a breakpoint on the Deadlock result, I see 3 threads still trying to add entries to the cache when the deadlock occurs. This appears to be a consequence of letting the client continue on before the pcache overlay has finished its work. But, I thought you were locking the cache so that requests would not run while query processing was incomplete? -- -- Howard Chu Chief Architect, 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#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com 22 Sep '07

22 Sep '07

hyc(a)symas.com wrote: > There's no reason to break the core code with misfeatures like this. If you > need this behavior, write an overlay that intercepts the relevant searches and > replaces the empty attribute list with "*" and "+". Scratch that, the contrib/slapd-modules/allop overlay already does this. This ITS will be closed. -- -- Howard Chu Chief Architect, 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#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by hyc＠symas.com 22 Sep '07

22 Sep '07

mspeder(a)syrtis.net wrote: > Full_Name: Matthieu Speder > Version: Latest HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch > Submission from: (NULL) (82.224.96.182) > > > This patch adds a new global option in configuration > (forceopattrs/olcForceOpAttrs { on | off }). Thanks for the patch. Still, the behavior you're introducing is a violation of the protocol spec. The fact that other vendors don't care to implement conformant servers doesn't really have any bearing on this; clients that expect this behavior are broken and should be fixed. > When answering a search query to rootDSE with an empty attribute query, > forceopattrs forces slapd to return all operational attributes. By default > forceopattrs is off and slapd only returns operational attributes when query > contains a plus (+), see RFC 4533. > > Unfortunately the default behavior is different from other directories (both AD > & Sun) and confuses some client applications which expect the operational > attributes with a blank query. This new config option fixes the issue if > required by client app. > > This patch does NOT change slapd default behavior. > > The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and > the required additions to docs (man & guide). There's no reason to break the core code with misfeatures like this. If you need this behavior, write an overlay that intercepts the relevant searches and replaces the empty attribute list with "*" and "+". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5150) Patch to add a new config option to force the return of operational attributes in rootDSE
by mspeder＠syrtis.net 22 Sep '07

22 Sep '07

Full_Name: Matthieu Speder Version: Latest HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Matthieu-Speder-070922.patch Submission from: (NULL) (82.224.96.182) This patch adds a new global option in configuration (forceopattrs/olcForceOpAttrs { on | off }). When answering a search query to rootDSE with an empty attribute query, forceopattrs forces slapd to return all operational attributes. By default forceopattrs is off and slapd only returns operational attributes when query contains a plus (+), see RFC 4533. Unfortunately the default behavior is different from other directories (both AD & Sun) and confuses some client applications which expect the operational attributes with a blank query. This new config option fixes the issue if required by client app. This patch does NOT change slapd default behavior. The patch contains both minor changes to result.c, proto-slap.h, bconfig.c and the required additions to docs (man & guide).

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 21 Sep '07

21 Sep '07

On Freitag, 21. September 2007, hyc(a)symas.com wrote: > rhafer(a)suse.de wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > It seems to be failing for me more often than not. Why is it > non-deterministic? It seems that the order in which the entries are inserted into the cache is non-deterministic. Because of that the order in which they are returned from cache varies as well. The final test that compares the ldapsearch results with proxycache.out relies on the order. I get a lot of DB_LOCK_DEADLOCK in slapd.2.log and if I don't missread the log it seems that sometimes the entries from Query 9 get inserted into the cache before the entry from Query 5 ("cn=Bjorn Jensen,ou=Information Technology Division, ...") and sometimes after. Depending on that the test either fails or succeeds. -- Ralf

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com 21 Sep '07

21 Sep '07

rhafer(a)suse.de wrote: > Please note that test020 currently fails in HEAD sometime. I think this > depends on the order in which the results for queries that hit the > sizelimit are returned. It seems to be failing for me more often than not. Why is it non-deterministic? > > Testout put is: > ------------------ > ... > ... > Successfully verified answerability > Filtering ldapsearch results... > Filtering original ldif... > Comparing filter output... > Comparison failed > ------------------ > > # diff testrun/ldif.flt testrun/ldapsearch.flt > 233,235c233,235 > < dn: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc > < =com > < mail: bjorn(a)mailgw.example.com > --- >> dn: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example, >> dc=com >> mail: bjensen(a)mailgw.example.com > > # > -- -- Howard Chu Chief Architect, 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#5102) back-perl build issues
by hyc＠symas.com 20 Sep '07

20 Sep '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another thing that has nagged me ever since we unified the slap tools into >> slapd - should have renamed slapadd.c -> tooladd.c etc... > > Personally, not. Only, slap* makes them quite personal, while tool* > sounds quite generic. It's like calling them db*: could be any type of > db (no pun with Berkeley intended :). Fair enough. I think my main issue is with slapcommon.[ch], which is only related to the tools, not common to slapd as a whole. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by hyc＠symas.com 20 Sep '07

20 Sep '07

james.hartley(a)gmail.com wrote: > ---------- Forwarded message ---------- > From: James Hartley <james.hartley(a)gmail.com> > Date: Sep 20, 2007 11:38 AM > Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) > To: Quanah Gibson-Mount <quanah(a)zimbra.com> > > ok I used the 2.4 beta wth the same result on tests. here is the configure > command and the output of make test. Not sure if I should back up to > Berkeley 4.5 and openldap2.3.38... Since that will require rebuilding the > DB then SASL then LDAP... do you know someone that might have build and > tested openldap for solaris 10 that I can confer with directly. Yes, I've run 2.4.5 with BDB 4.6 on Solaris 10 without any difficulties. Since you're seeing a bus error the only way to diagnose this is by using a debugger to get a stack trace. > P.S. I have some scripts that you might be interested in the maintain > usr/local and help construct packages for solaris... The OpenLDAP Project doesn't maintain packages for any platform. Feel free to post your tips and scripts in the FAQ-o-Matic. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by ghenry＠OpenLDAP.org 20 Sep '07

20 Sep '07

Again, no HTML, please... Did you run: configure make depend make make test It looks like "make depend" was missing. Can we move this to -software(a)openldap.org rather than an ITS, as this appears to be a user build issue rather than an actual bug. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Fwd: Solaris 10 test000 root dse bus error (ITS#5140)
by james.hartley＠gmail.com 20 Sep '07

20 Sep '07

------=_Part_32258_11773747.1190318929506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: James Hartley <james.hartley(a)gmail.com> Date: Sep 20, 2007 11:38 AM Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) To: Quanah Gibson-Mount <quanah(a)zimbra.com> ok I used the 2.4 beta wth the same result on tests. here is the configure command and the output of make test. Not sure if I should back up to Berkeley 4.5 and openldap2.3.38... Since that will require rebuilding the DB then SASL then LDAP... do you know someone that might have build and tested openldap for solaris 10 that I can confer with directly. here is the output env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta /tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' Initiating LDAP tests for BDB... ./run: ./schema: does not exist Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 24854 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta /tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta /tests' make: *** [test] Error 2 --(hartleyj@sunv420)-(~/sunv420ldapconstruction_latest/openldap- 2.4.5beta )-- P.S. I have some scripts that you might be interested in the maintain usr/local and help construct packages for solaris... On 9/20/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > --On Thursday, September 20, 2007 3:54 PM +0000 james.hartley(a)gmail.com > wrote: > > > ------=_Part_30794_27537250.1190303647870 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > Humm no real help here!! no obvious errors. here is the last few lines > > of the slapd.1.conf file. in tests. > > > > Do you have any other Ideas > > Use a supported version of BDB. OpenLDAP 2.3 series works with BDB 4.2, > 4.4, and 4.5. OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. > Since you built 2.3 against 4.6, you are trying to do something that is > not > supported. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > ------=_Part_32258_11773747.1190318929506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: James Hartley <<a href="mailto:james.hartley@gmail.com">james.hartley(a)gmail.com</a>> Date: Sep 20, 2007 11:38 AM Subject: Re: Solaris 10 test000 root dse bus error (ITS#5140) To: Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>> ok I used the 2.4 beta wth the same result on tests.   here is the configure command and the output of make test.   Not sure if I should back up to Berkeley 4.5 and openldap2.3.38...  Since that will require rebuilding the DB then SASL then LDAP... do you know someone that might have build and tested openldap for solaris 10 that I can confer with directly. here is the output env LD_LIBRARY_PATH="/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.6/lib:/usr/lib/sasl2" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.6/lib -L/usr/lib/sasl2 -R/usr/local/lib -R/usr/local/ssl/lib -R/usr/local/BerkeleyDB.4.6/lib -R/usr/lib/sasl2" CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.6/include -I/usr/local/include/sasl" ./configure --enable-bdb --enable-crypt --with-tls --with-cyrus-sasl make[1]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' make[2]: Entering directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta /tests' Initiating LDAP tests for BDB... ./run: ./schema: does not exist Running ./scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... 24854 Bus Error - core dumped Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: kill: no such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> ./scripts/test000-rootdse failed (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.4.5beta/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.4.5beta/tests' make: *** [test] Error 2 --(hartleyj@sunv420)-(~/sunv420ldapconstruction_latest/openldap- 2.4.5beta)-- P.S.  I have some scripts that you might be interested in the maintain usr/local and help construct packages for solaris... <div>On 9/20/07, Quanah Gibson-Mount <<a href="mailto:quanah@zimbra.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">quanah(a)zimbra.com</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --On Thursday, September 20, 2007 3:54 PM +0000 <a href="mailto:james.hartley@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">james.hartley(a)gmail.com</a> wrote: > ------=_Part_30794_27537250.1190303647870 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Humm no real help here!!  no obvious errors.  here is the last few lines > of the slapd.1.conf file. in tests. > > Do you have any other Ideas Use a supported version of BDB.  OpenLDAP 2.3 series works with BDB 4.2, 4.4, and 4.5.  OpenLDAP 2.4 series works with BDB 4.2, 4.4, 4.5, and 4.6. Since you built 2.3 against 4.6, you are trying to do something that is not supported. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote></div></div> ------=_Part_32258_11773747.1190318929506--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs