>On Fri, Apr 15, 2005 at 12:09:19PM +0900, Christian Balzer wrote:
>> Changes are generated by ldifsort.pl/ldifdiff.pl and then applied with
>> ldapmodify for a low impact and smooth operation, using ldbm as
>> backend.
>
>The previous version of slapd *also* had corruption issues, and this is the
>driving reason for putting slapd 2.2 in sarge.
>
I read that and I'm all for using current versions of software when
getting near to a Debian release.
Alas it's hard to contrast one year of trouble free operation with
the current state of affairs. A fix that breaks all the users which
until now had a perfectly working setup is, well, not a fix.
Or to put it quite blunt, people encountering DB corruption with
the previous version most likely did NOT run production systems with it.
Me and others on the other hand...
>Which LDAP backend are you using for this directory?
>
See above, LDBM (whatever actual DB that defaults to these days).
I loathe BDB for the times it takes for massive adds/modifies.
Even with slapadd, which takes about 2 minutes to load the entire DB
using ldbm as backend, but about 50 minutes with BDB.
Regards,
Christian Balzer
--
Christian Balzer Network/Systems Engineer NOC
<email address hidden> Global OnLine Japan/Fusion Network Services http://www.gol.com/
Message-Id: <email address hidden>
Date: Fri, 15 Apr 2005 13:30:33 +0900
From: Christian Balzer <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Subject: Re: Bug#304735: slapd 2.2.23 database corruption
Steve Langasek wrote:
>On Fri, Apr 15, 2005 at 12:09:19PM +0900, Christian Balzer wrote:
>> Changes are generated by ldifsort. pl/ldifdiff. pl and then applied with
>> ldapmodify for a low impact and smooth operation, using ldbm as
>> backend.
>
>The previous version of slapd *also* had corruption issues, and this is the
>driving reason for putting slapd 2.2 in sarge.
>
I read that and I'm all for using current versions of software when
getting near to a Debian release.
Alas it's hard to contrast one year of trouble free operation with
the current state of affairs. A fix that breaks all the users which
until now had a perfectly working setup is, well, not a fix.
Or to put it quite blunt, people encountering DB corruption with
the previous version most likely did NOT run production systems with it.
Me and others on the other hand...
>Which LDAP backend are you using for this directory?
>
See above, LDBM (whatever actual DB that defaults to these days).
I loathe BDB for the times it takes for massive adds/modifies.
Even with slapadd, which takes about 2 minutes to load the entire DB
using ldbm as backend, but about 50 minutes with BDB.
Regards,
Christian Balzer www.gol. com/
--
Christian Balzer Network/Systems Engineer NOC
<email address hidden> Global OnLine Japan/Fusion Network Services
http://