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
---------------------------------------
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
---------------------------------------
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).
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.
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).
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
---------------------------------------
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/
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/