Torsten Landschoff <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>). 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 -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]