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. > 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 needed? > 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 stay. > 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... Greetings Torsten
Attachment:
signature.asc
Description: Digital signature