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

Re: [RFC] OpenLDAP automatic upgrade

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

> website on building OpenLDAP:
> http://www.stanford.edu/services/directory/openldap/configuration/
> specifically in this case:
> http://www.stanford.edu/services/directory/openldap/configuration/bdb-build-42.html

Thanks, I was pointed to that site by another developer already. I just
did not like applying patches without really knowing what they are
needed for. 

> 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

> As for BDB 4.3:
> You cannot use BDB 4.3 to load databases past a few million entries into
> OpenLDAP.  The way BDB handles logs changed enormously between BDB 4.2 and
> BDB 4.3, and its log management is not stable, often running out of
> space.  In addition, numerous users have written the OpenLDAP list
> complaining of issues they've hit using BDB 4.3 with OpenLDAP 2.2.  The
> solution was for them to move back to BDB 4.2.52+patches.  This became
> such a problem that with the OpenLDAP 2.2.24 release (done today), the
> README file was updated to say:
>     SLAPD:
>         BDB backend requires (latest) Sleepycat Berkeley DB 4.2

Good to know. I'll revert the Debian package to 4.2.

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

> 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

> I also advise reading:
> http://www.stanford.edu/services/directory/openldap/configuration/bdb-config-42.html
> http://www.openldap.org/faq/data/cache/1075.html

Done, thanks. Nothing really new there though.

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

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

> Okay.  2.2.24 was released.  You might examine the changes file to see if
> you want to use it, or pull in patches that it incorporated.

Have to check... Would be a good time to switch back to bdb 4.2 together
with switching to 2.2.24 of OpenLDAP.

> > That's for sure but I want to be able to do automatic upgrades for the
> > simple cases. And at least help the admin by dumping the directory
> > before starting the upgrade and taking care of the old database files in
> > case he decides to downgrade again later :)
> I don't think there is a simple case. ;)

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



Attachment: signature.asc
Description: Digital signature

Reply to: