Re: ITS#5241
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
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
(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
(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
(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
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
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
(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