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
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Reply to: