November 2007 - openldap-bugs

by ando＠sys-net.it

ando(a)sys-net.it wrote: > Current 2.3 release is 2.3.32; please do not report bugs for older > releases, as chances are they're already fixed. I meant: current is 2.3.39, while you reported a bug for 2.3.32. 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 ---------------------------------------

15 years, 10 months

1
0
0 / 0

ITS#5241

by ando＠sys-net.it

Current 2.3 release is 2.3.32; please do not report bugs for older releases, as chances are they're already fixed. 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 ---------------------------------------

15 years, 10 months

1
0
0 / 0

(ITS#5243) Documentation for syncrepl sizelimit

by Ulrich.Windl＠rz.uni-regensburg.de

Full_Name: Ulrich Windl Version: 2.3.32 OS: SLES10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.156.178) I'm unsure about the concept, but documentation is unclear anyway: For a syncreply configuration using RefreshAndPersist, the initial sync is incomplete if the whole database cannot be transferred in one attempt. When restarting the consomer, the same entries that had been transferred before are transferred again, and the consumer will never complete synchronization. Is it concept or a bug that upon initial sync the whole database must be transferred in one search result? If it's so, almost any sizelimit below "unlimited" is dangerous (that is the number of database entries effectively must be the sizelimit).

15 years, 10 months

1
0
0 / 0

(ITS#5242) slapd.conf: limits vs. sizelimit

by Ulrich.Windl＠rz.uni-regensburg.de

Full_Name: Ulrich Windl Version: 2.3.32 OS: SLES10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.156.178) The man page for slapd.conf leaves the impression that a "size=unlimited" within a "limits" statement allows any size to be transferred. However it seems that one may only lower the "sizelimit" (default 500) using "limits". The man page doesn't say so.

15 years, 10 months

1
0
0 / 0

(ITS#5241) slapd crashes with "loglevel 0"

by Ulrich.Windl＠rz.uni-regensburg.de

Full_Name: Ulrich Windl Version: 2.3.32 OS: SLES10 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.199.156.178) The version of OpenLDAP shipped with SUSE Linux Enterprise Server 10 (SLES10) SP1, openldap2-2.3.32-0.23 crashes with a segmentation fault if "loglevel 0" is used. For other log levels things seem to work. The problem has been seen on x86_64 (segfaults are logged in syslog).

15 years, 10 months

1
0
0 / 0

ITS#5240

by ando＠sys-net.it

A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; init.c not yet). I don't know if it was intended, or if the merging is just in progress. 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 ---------------------------------------

15 years, 10 months

1
0
0 / 0

Re: (ITS#5221) cache? of parent failes for hdb

by hyc＠symas.com

Dan Oscarsson wrote: > ons 2007-11-21 klockan 23:53 -0800 skrev Howard Chu: > >>> I did a quick look at the code for bdb_cache_modrdn to see what have >>> been changed. Cannot say if it looks correct but I have one question >>> for the part: >> Thanks for checking, you're right. Now fixed in rev 1.161. > > I have now tested with latest out of CVS with the BerkeleyDB needed for > that. All my tests worked OK. > I have also updated the modrdn code in cache.c from your new code, in > the 2.3.38 version, and then tested. All tests is ok there too. > > I have now changed som data and run the tests again without any problem > in 2.3.38. So it looks good so far. As you said you plan to release > 2.4.7 soon, I will run my patched 2.3.38 util then, and then switch to > 2.4.7. I will run my old commercial ldap server and the openldap server > in parallell for a while to verify that no new problem is found. Thanks for the followup. Just a note - you don't need to use a particular version of BerkeleyDB with the CVS code; the same BDB 4.2.52 will keep working. But of course there are performance improvements in BDB 4.6... -- -- 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/

15 years, 10 months

1
0
0 / 0

(ITS#5240) Build fails: incompatible type for argument 1 of 'ch_free'

by michael＠stroeder.com

Full_Name: Michael Ströder Version: RE24 OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.19.96) RE24 was synced right now. /bin/sh ../../..//libtool --tag=disable-static --mode=compile cc -g -O4 -march=pentium4 -I../../../include -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/opt/db-4.5/include -I/usr/include -I/opt/heimdal/include -DBDB_MONITOR_IDX -DSLAPD_IMPORT -c init.c mkdir .libs cc -g -O4 -march=pentium4 -I../../../include -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/opt/db-4.5/include -I/usr/include -I/opt/heimdal/include -DBDB_MONITOR_IDX -DSLAPD_IMPORT -c init.c -fPIC -DPIC -o .libs/init.o init.c: In function 'hdb_db_open': init.c:457: error: incompatible types in assignment init.c: In function 'hdb_db_close': init.c:549: error: incompatible type for argument 1 of 'ch_free' make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/usr/src/openldap-OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-hdb' make[2]: *** [back-hdb] Error 2 make[2]: Leaving directory `/usr/src/openldap-OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/openldap-OPENLDAP_REL_ENG_2_4/openldap/servers' make: *** [all-common] Error 1

15 years, 10 months

1
0
0 / 0

Re: (ITS#5221) cache? of parent failes for hdb

by hyc＠symas.com

hyc(a)symas.com wrote: > I think that's enough to confirm the problems. I won't be able to work on the > fix for a few hours; will update here when I have something ready. You can test back-bdb/cache.c rev 1.160. I think you'll need to apply the diff between 1.157 - 1.160 to whatever source version you're currently using. (Or just use the CVS HEAD source.) -- -- 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/

15 years, 10 months

1
0
0 / 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4

by rhafer＠suse.de

Ok, the fix has been ported to RE24 and the testcase is enabled again. -- Ralf

15 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2007