[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] OpenLDAP automatic upgrade

Torsten Landschoff <torsten@debian.org> writes:

> Hi Quanah, 
> On Wed, Mar 16, 2005 at 05:59:03PM -0800, Quanah Gibson-Mount wrote:
>> The patches for BDB 4.2.52 are freely available from Sleepycat.  They are
>> required to be in place if you want a stable BDB 4.2.52 distribution.  I
>> would be very surprised if the package maintainer hadn't already included
>> the patches in their build.  I also post links to the patches from my

> Make we wonder why Sleepycat does not release 4.2.53 with those patches
> included. 

I've wondered that myself. ;)

>> You can ignore the custom patch about transactions, as that is not an
>> official sleepycat patch, but one written by Howard Chu, one of the
>> primary OpenLDAP developers.

> What is that patch for anyway? Seems like it allows slapd to open a
> transaction and never commit it from first sight. Why would that be
> needed?

It fixes a case where BDB log files never get closed because of
uncommitted transactions, IIRC.  I have a link to the entire discussion
about it from my web page if you want to read all about it. ;)  It
basically implements in BDB 4.2 the one useful feature of BDB 4.3 as far
as OpenLDAP is concerned.

>> > Surely. For simple installations it might work without that though and
>> > not every slapd package is installed to run the Stanford directory
>> > server. :)
>> I doubt that it will work for even simple installations.  The very syntax
>> of many of the ACL declarations were changed.  I had to go through and
>> update every single ACL in my ACL file for it to work right. ;)

> There are some problems I found during upgrading an example
> installation which are automatically fixed. Those are mostly just for
> the Debian default installation though. That's what I am trying to do:
> Make it work for people who just did apt-get install slapd and never
> cared much about that LDAP directory. 

Okay.  I've never used the debian default package myself, so maybe that is
that simple. :)

>> The two flags I am thinking of for BDB 4.2 are:
>> # Just use these settings when doing slapadd...
>> #set_flags DB_TXN_NOSYNC
>> #set_flags DB_TXN_NOT_DURABLE
>> They turn off checks that aren't necessary when performing a slapadd.

> Is there a way to enforce this without editing DB_CONFIG? I'd rather set
> an environment variable or something like that. Writing that into
> DB_CONFIG in the maintainer scripts always poses the risk that it'll
> stay.

Well.... This will be available in OpenLDAP 2.3 via the "-q" option to
slapadd.  I have my own backported patch to OpenLDAP 2.2 that enables the
"-q" option.

>> If you really want to have this conversation, I suggest talking to Howard
>> Chu (Howard Chu <hyc@highlandsun.com>).  He's the author of back-bdb and
>> back-hdb (The OL development team tends to refer to back-hdb as Howard's
>> DB. :P).

> ) Perhaps I should do that but I know what the answer might be: Go
> ahead and implement it ;-) Which is what I'd answer from his point of
> view as well. And currently I don't care that much. If it is slow, so be
> it. Important is that it is working. I'll take some of the information
> you linked to into the README.Debian of slapd in the hopes that it is
> read by some people.

I asked Howard about this actually... Another developer is examining doing
this at this time.  It would be in OpenLDAP 2.3 at the earliest, however
(and I'm guessing 2.4, since I haven't seen any commits over it).

>> >> 4) If someone is using ldbm as their backend database, I'd throw a warning
>> >> noting that bdb/hdb are the preferred backends of OpenLDAP.  ldbm is rife
>> >> with issues such as not catching data inconsistencies, leading to poor
>> >> directory performance and potential data loss.
>> > Where is the difference to bdb? ;-)
>> [...]
>> As an individual who dealt with an ldbm based directory, I can attest to
>> the superiority of back-bdb.

> That was supposed to be a joke about the stability of bdb. Looking at
> the reports I was getting about bdb problems it seems like bdb has some
> issues. From the feedback I get I guess that most are fixed in bdb.

Did you use bdb here a few times when you meant to use ldbm? ;)  Anyhow,
with OpenLDAP 2.2 + BDB 4.2.52+patches, my BDB database has been rock
solid.  Issues I have had arose from bugs in OL not BDB. ;)

> Oh yes there is. I know quite some directory servers on our university
> campus running Debian slapd as shipped with no special config. Just
> putting 500 users into it and using it as NIS replacement. That's
> something even OpenLDAP 2.0 was doing quite well...

I'll take your word for it. :)


Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Reply to: