- openldap-bugs - openldap.org

(ITS#5151) certificateListValidate rejects valid lists
by hyc＠OpenLDAP.org 23 Sep '07

23 Sep '07

Full_Name: Howard Chu Version: HEAD/re24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc I ran into a couple problems; the check for timestamps doesn't take into account that Time is a CHOICE of UTCTime and GeneralizedTime. Also the check for the revocation list doesn't verify that it's a SEQUENCE OF SEQUENCE, so it mistakenly skips over closing signatureAlgorithm if the revocation list is absent. Will be fixed in HEAD shortly.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by hyc＠symas.com 23 Sep '07

23 Sep '07

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails >> to parse it because it is an integer with length equal to 9, which is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means from > 0 up to 2^31-1... I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self-consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. I just got tripped trying to import an LDIF with a cert with 16 byte SerialNumber. I've patched this to just use the same hexadecimal format that OpenSSL uses when the number is larger than ber_int_t. We really don't want the format to change just because someone has a BigNum library available; it needs to stay consistent. Normalizing to a string format like this still seems pretty gross, but I guess that's the best we can do given dumb clients that aren't aware of schema. -- -- 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#5114) pcache cache results for searches that hit size/timelimit
by ando＠sys-net.it 23 Sep '07

23 Sep '07

Ralf Haferkamp 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. I added tests for sizelimit that were consistent with my changes; however, I'm now short of time to work on this, so feel free to back out those test changes if you believe the code is working correctly, while we design test improvements that are consistent with all fixes. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

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

22 Sep '07

hyc(a)symas.com wrote: > Ralf Haferkamp wrote: >> On Freitag, 21. September 2007, hyc(a)symas.com wrote: >>> 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? I see, you're only locking individual queries. That's certainly inadequate, you'll probably have to lock the entire cache as a whole. Remember that an entry that you're adding may actually satisfy multiple queries. -- -- 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#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

Re: (ITS#5149) config.status aborts with error
by hyc＠symas.com 20 Sep '07

20 Sep '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.186.237) > > > Hi config.status aborts with error, thus portable.h and other files are not > generated by configure You need to use "cvs upd -d " to get the back-sock directory. No bug here, this ITS will be closed. > config.status:842: creating servers/slapd/back-sock/Makefile > config.status:902: error: cannot find input file: > servers/slapd/back-sock/Makefile.in > .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.- > > -Dieter > > > -- -- 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#5149) config.status aborts with error
by dieter＠dkluenter.de 20 Sep '07

20 Sep '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.186.237) Hi config.status aborts with error, thus portable.h and other files are not generated by configure config.log .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- config.status:842: creating Makefile config.status:842: creating doc/Makefile config.status:842: creating doc/man/Makefile config.status:842: creating doc/man/man1/Makefile config.status:842: creating doc/man/man3/Makefile config.status:842: creating doc/man/man5/Makefile config.status:842: creating doc/man/man8/Makefile config.status:842: creating clients/Makefile config.status:842: creating clients/tools/Makefile config.status:842: creating include/Makefile config.status:842: creating libraries/Makefile config.status:842: creating libraries/liblber/Makefile config.status:842: creating libraries/libldap/Makefile config.status:842: creating libraries/libldap_r/Makefile config.status:842: creating libraries/liblunicode/Makefile config.status:842: creating libraries/liblutil/Makefile config.status:842: creating libraries/librewrite/Makefile config.status:842: creating servers/Makefile config.status:842: creating servers/slapd/Makefile config.status:842: creating servers/slapd/back-bdb/Makefile config.status:842: creating servers/slapd/back-dnssrv/Makefile config.status:842: creating servers/slapd/back-hdb/Makefile config.status:842: creating servers/slapd/back-ldap/Makefile config.status:842: creating servers/slapd/back-ldif/Makefile config.status:842: creating servers/slapd/back-meta/Makefile config.status:842: creating servers/slapd/back-monitor/Makefile config.status:842: creating servers/slapd/back-null/Makefile config.status:842: creating servers/slapd/back-passwd/Makefile config.status:842: creating servers/slapd/back-perl/Makefile config.status:842: creating servers/slapd/back-relay/Makefile config.status:842: creating servers/slapd/back-shell/Makefile config.status:842: creating servers/slapd/back-sock/Makefile config.status:902: error: cannot find input file: servers/slapd/back-sock/Makefile.in .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--.-.- -Dieter

1 0

(ITS#5148) Segmentation Fault
by Russell.Mosemann＠cune.edu 20 Sep '07

20 Sep '07

quanah(a)zimbra.com said: > OpenLDAP 2.3 does not support BDB 4.6. Thank you. That answers my question. This ticket may be closed. -- Russell Mosemann, Ph.D. Associate Professor of Computer Science

1 0

Re: 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: > ------=_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 Don't send HTML email to the ITS. You didn't specify which version of BDB 4.6 you're using, but I suspect your answer is here: http://www.openldap.org/lists/openldap-software/200708/msg00344.html -- -- 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: Solaris 10 test000 root dse bus error (ITS#5140)
by quanah＠zimbra.com 20 Sep '07

20 Sep '07

--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

1 0

Re: (ITS#5148) Segmentation Fault
by hyc＠symas.com 20 Sep '07

20 Sep '07

Russell.Mosemann(a)cune.edu wrote: > Full_Name: Russell Mosemann > Version: 2.3.38 > OS: Linux 2.6.19.1 > URL: > Submission from: (NULL) (192.160.64.49) > > > Debian 3.1 > bdb 4.6.19 > OpenLDAP 2.3.38 > configure --disable-ipv6 --without-cyrus-sasl --without-tls --enable-crypt \ > --enable-wrappers --enable-hdb > gcc version 4.2.1 (Debian 4.2.1-3) > > slapcat and slapadd function without errors when loading or exporting the > database. The following segmentation fault happens on the first query to slapd. This is expected. http://www.openldap.org/lists/openldap-software/200708/msg00344.html BerkeleyDB 4.6.19 is not compatible with OpenLDAP 2.3. Use OpenLDAP 2.4 if you want to use BDB 4.6.19, or use BDB 4.6.3 or older if you want to stay on OpenLDAP 2.3. 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#5148) Segmentation Fault
by quanah＠zimbra.com 20 Sep '07

20 Sep '07

--On Thursday, September 20, 2007 3:44 PM +0000 Russell.Mosemann(a)cune.edu wrote: > Full_Name: Russell Mosemann > Version: 2.3.38 > OS: Linux 2.6.19.1 > URL: > Submission from: (NULL) (192.160.64.49) > > > Debian 3.1 > bdb 4.6.19 > OpenLDAP 2.3.38 OpenLDAP 2.3 does not support BDB 4.6. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

20 Sep '07

------=_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 slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=include{3}" config_build_entry: "cn=include{4}" config_build_entry: "cn=include{5}" config_build_entry: "cn=include{6}" config_build_entry: "cn=include{7}" config_build_entry: "cn=include{8}" config_build_entry: "cn=include{9}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}dyngroup" config_build_entry: "cn={9}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) On 9/20/07, Gavin Henry <openldap-its(a)openldap.org> wrote: > > > Full_Name: james hartley > > Version: 2.3.27 > > OS: Solaris 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (204.140.46.100) > > > > > > built with gcc 3.4.6 using the following configure command. > > > > $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 > > > > compile looks good... However I get the following errors during make > test... > > I could not find anything in the archives that pointed to a > solution. Only > > others asking the same question for earlier versions of solaris ,, > specifically > > solaris 8. > > > > Can anyone give me a good lead in how to proceed. BTW I have run tests > before > I > > installed the software and after I installed the software... After the > first > > test I installed the software anyway. > > > > Thanks for any help. > > > > cd tests; make test > > make[1]: Entering directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make[2]: Entering directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > Initiating LDAP tests for BDB... > > Cleaning up test run directory leftover from previous run. > > 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... > > 11851 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_bind: Can't contact LDAP server (-1) > >>>>>> Test failed > >>>>>> ./scripts/test000-rootdse failed (exit 1) > > make[2]: *** [bdb-yes] Error 1 > > make[2]: Leaving directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make[1]: *** [test] Error 2 > > make[1]: Leaving directory > > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37 > /tests' > > make: *** [test] Error 2 > > > > After running make test, look at the files in the "testrun" folder. That > will > tell you the reasons why it failed. > ------=_Part_30794_27537250.1190303647870 Content-Type: text/html; 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 slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=include{3}" config_build_entry: "cn=include{4}" config_build_entry: "cn=include{5}" config_build_entry: "cn=include{6}" config_build_entry: "cn=include{7}" config_build_entry: "cn=include{8}" config_build_entry: "cn=include{9}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}corba" config_build_entry: "cn={3}java" config_build_entry: "cn={4}inetorgperson" config_build_entry: "cn={5}misc" config_build_entry: "cn={6}nis" config_build_entry: "cn={7}openldap" config_build_entry: "cn={8}dyngroup" config_build_entry: "cn={9}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcDatabase={2}monitor" backend_startup_one: starting "o=OpenLDAP Project,l=Internet" bdb_db_open: o=OpenLDAP Project,l=Internet bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix o=OpenLDAP Project,l=Internet. bdb_db_open: dbenv_open(./testrun/db.1.a) <div>On 9/20/07, Gavin Henry <<a href="mailto:openldap-its@openldap.org"> openldap-its(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Full_Name: james hartley > Version: 2.3.27 > OS: Solaris 10 > URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (<a href="http://204.140.46.100">204.140.46.100</a>) > > > built with gcc 3.4.6 using the following configure command. > > $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 > > compile looks good... However I get the following errors during make test... > I could not find anything in the archives that pointed to a solution.  Only > others asking the same question for earlier versions of solaris ,, specifically > solaris 8. > > Can anyone give me a good lead in how to proceed. BTW I have run tests before I > installed the software and after I installed the software... After the first > test I installed the software anyway. > > Thanks for any help. > > cd tests; make test > make[1]: Entering directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.3.37/tests' > make[2]: Entering directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' > Initiating LDAP tests for BDB... > Cleaning up test run directory leftover from previous run. > 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... > 11851 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_bind: Can't contact LDAP server (-1) >>>>>> Test failed >>>>>> ./scripts/test000-rootdse failed (exit 1) > make[2]: *** [bdb-yes] Error 1 > make[2]: Leaving directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap- 2.3.37/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory > `/export/home/hartleyj/sunv420ldapconstruction_latest/openldap-2.3.37/tests' > make: *** [test] Error 2 > After running make test, look at the files in the "testrun" folder. That will tell you the reasons why it failed. </blockquote></div> ------=_Part_30794_27537250.1190303647870--

1 0

(ITS#5148) Segmentation Fault
by Russell.Mosemann＠cune.edu 20 Sep '07

20 Sep '07

Full_Name: Russell Mosemann Version: 2.3.38 OS: Linux 2.6.19.1 URL: Submission from: (NULL) (192.160.64.49) Debian 3.1 bdb 4.6.19 OpenLDAP 2.3.38 configure --disable-ipv6 --without-cyrus-sasl --without-tls --enable-crypt \ --enable-wrappers --enable-hdb gcc version 4.2.1 (Debian 4.2.1-3) slapcat and slapadd function without errors when loading or exporting the database. The following segmentation fault happens on the first query to slapd. gdb slapd (gdb) run -d 255 ... >>> dnPrettyNormal: <qmailgid=306,ou=accounts,o=cune> => ldap_bv2dn(qmailgid=306,ou=accounts,o=cune,0) <= ldap_bv2dn(qmailgid=306,ou=accounts,o=cune)=0 => ldap_dn2bv(272) <= ldap_dn2bv(qmailGID=306,ou=accounts,o=cune)=0 => ldap_dn2bv(272) <= ldap_dn2bv(qmailGID=306,ou=accounts,o=cune)=0 <<< dnPrettyNormal: <qmailGID=306,ou=accounts,o=cune>, <qmailGID=306,ou=accounts ,o=cune> do_bind: version=3 dn="qmailGID=306,ou=accounts,o=cune" method=128 ==> hdb_bind: dn: qmailGID=306,ou=accounts,o=cune bdb_dn2entry("qmailGID=306,ou=accounts,o=cune") Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1561621616 (LWP 27395)] 0xb7f0a471 in __lock_get_internal () from /usr/lib/libdb-4.6.so (gdb) bt full #0 0xb7f0a471 in __lock_get_internal () from /usr/lib/libdb-4.6.so No symbol table info available. #1 0xb7f0afaf in __lock_get () from /usr/lib/libdb-4.6.so No symbol table info available. #2 0xb7f3caf5 in __db_lget () from /usr/lib/libdb-4.6.so No symbol table info available. #3 0xb7eafc67 in __bam_get_root () from /usr/lib/libdb-4.6.so No symbol table info available. #4 0xb7eb003e in __bam_search () from /usr/lib/libdb-4.6.so No symbol table info available. #5 0xb7ea0b0a in __bamc_init () from /usr/lib/libdb-4.6.so No symbol table info available. #6 0xb7ea1b9e in __bamc_init () from /usr/lib/libdb-4.6.so No symbol table info available. #7 0xb7f2eb9d in __dbc_get () from /usr/lib/libdb-4.6.so No symbol table info available. #8 0xb7f37d6b in __dbc_get_pp () from /usr/lib/libdb-4.6.so No symbol table info available. #9 0x080f2332 in hdb_id2entry (be=0x8230d58, tid=0x0, locker=7, id=136227432, e=0xa2eb8018) at id2entry.c:125 bdb = <value optimized out> db = (DB *) 0x0 key = {data = 0xa2eb7f74, size = 4, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 4} data = {data = 0x0, size = 0, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 8} cursor = (DBC *) 0xa333cabc bv = {bv_len = 136515576, bv_val = 0x1 <Address 0x1 out of bounds>} rc = -1208315332 nid = 2517172224 #10 0x080ea2ba in hdb_cache_find_id (op=0x81ecc80, tid=0x0, id=2454, eip=0xa2eb8058, islocked=1, locker=7, lock=0xa2eb80a4) at cache.c:760 bdb = (struct bdb_info *) 0x8230e60 ep = (Entry *) 0x0 rc = 0 load = 1 ei = {bei_parent = 0x0, bei_id = 2454, bei_lockpad = 0 '\0', bei_state = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = { __next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0} #11 0x080ed857 in hdb_dn2entry (op=0x81ecc80, tid=0x0, dn=0x81ecc9c, e=0xa2eb80b8, matched=1, locker=7, lock=0xa2eb80a4) at dn2entry.c:68 ei = (EntryInfo *) 0x81ed428 rc = 0 ---Type <return> to continue, or q <return> to quit--- rc2 = <value optimized out> #12 0x080e821f in hdb_bind (op=0x81ecc80, rs=0xa2eb81c4) at bind.c:68 e = <value optimized out> a = <value optimized out> ei = <value optimized out> password = (AttributeDescription *) 0x81c88d8 locker = 7 lock = {off = 134060, ndx = 905, gen = 13, mode = DB_LOCK_WRITE} __PRETTY_FUNCTION__ = "hdb_bind" #13 0x08078cf9 in fe_op_bind (op=0x81ecc80, rs=0xa2eb81c4) at bind.c:405 mech = {bv_len = 6, bv_val = 0x813b828 "SIMPLE"} bd = (BackendDB *) 0x818cee0 #14 0x08079ab1 in do_bind (op=0x81ecc80, rs=0xa2eb81c4) at bind.c:200 ber = (BerElement *) 0x81ebd70 version = 3 method = 128 mech = {bv_len = 0, bv_val = 0x0} dn = {bv_len = 31, bv_val = 0x81ecc42 "qmailgid=306,ou=accounts,o=cune"} tag = <value optimized out> be = (Backend *) 0x0 #15 0x0805de3d in connection_operation (ctx=0xa2eb8248, arg_v=0x81ecc80) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 96 opidx = SLAP_OP_BIND conn = (Connection *) 0xa32b9f80 memctx = (void *) 0x81ece78 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #16 0x08110662 in ldap_int_thread_pool_wrapper (xpool=0x81c9c28) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x81ec650 ltc_key = {{ltk_key = 0x80a2830, ltk_data = 0x81ece78, ltk_free = 0x80a23a0 <slap_sl_mem_destroy>}, {ltk_key = 0x81eaa68, ltk_data = 0x7, ltk_free = 0x80e8be0 <bdb_locker_id_free>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>} tid = 2733345680 i = 680 hash = <value optimized out> #17 0xb7e212d3 in start_thread () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #18 0xb7da72fe in clone () from /lib/libc.so.6 No symbol table info available.

1 0

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

20 Sep '07

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. 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 # -- Ralf

1 0

Re: (ITS#5113) pcache returns incomplete results
by rhafer＠suse.de 20 Sep '07

20 Sep '07

Should be fixed in HEAD now. -- Ralf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs