Moving From Debian 2.4.31/hdb to LTB 2.4.39/mdb

[Andy Dorman <adorman@ironicdesign.com>]

Hi.  We have been using OpenLDAP for about 11 years now and have an MMR 
set up with 2 masters and 18 delta-syncrepl clients/slaves, all but 3 
slaves are currently using back_hdb. Our beta test server and two load 
balancers are using back_mdb.  The db is not too big with about 50,000 
entries, 9 indexes (7 eq & 2 sub) and the slapdump ldif is about 41 MB.

All our servers are Debian "testing" with a few packages from unstable 
and even experimental so we have the latest security and feature fixes 
for the work we do (email security filtering).  Unfortunately, even the 
"bleeding edge" debian releases are waaaay behind in OpenLDAP.

Last year we lost our system admin that set all this up, and I have been 
on a very steep learning curve since then. At this time I believe we 
need to move to a current version of OpenLDAP via ltb-project and switch 
to mdb, but I have run into a couple of questions we need to resolve first.

FWIW, I would dearly like to help out the Debian community and compile & 
maintain an up-to-date version of OpenLDAP for them, but I need at least 
a couple more years of experience before it is even marginally safe to 
have other companies depending on my expertise with debian packaging.

Anyway, after reading the OpenLDAP & ltb-project docs I have a couple of 
questions for anyone already using the ltb-project debian release, 
slapd.d & mdb.  I hope the answers will help make our and others' 
transition go more smoothly.

So here we go....

Question #1. I see that slapd.conf is deprecated and we should move to a 
slapd.d config db.

However, the slapd.conf file (with git & cfengine) meets 3 key 
requirements for our service's configuration management: (1) audit 
trail, (2) peer review & staff notification, (3) automatic, staggered 
release to all servers so our users experience 0 downtime.

I do not yet see an "easy" way to meet the first two requirements using 
slapd.d.

To satisfy #3 I hope we can just update our master server slapd.d and 
config changes will be replicated to the slaves.  Someone please correct 
me if I am wrong about that.

To meet the requirement for an audit trail & staff review & 
notification, in the absence of someone's experience and/or knowledge 
from this group, we currently plan to use our ticket-tracking system 
(Request Tracker).  Within an RT queue dedicated to our db systems we 
will document, review & manage slapd.d changes prior to actually making 
a change in the master which will then (I hope) propagate through 
delta-syncrepl.

How does anyone else that is using slapd.d with an MMR setup with 
multiple client/slaves take care of their needs for an audit trail, peer 
review/staff notification, and release to all those servers?

Question #2.  This may be a simple one....When reading the latest 
OpenLDAP docs at http://www.openldap.org/doc/admin24/slapdconf2.html I 
noticed that there are no references to back_mdb in the configuration 
documentation...Specifically, "Table 5.2: Database Backends" and "Table 
6.2: Database Backends" do not show an "mdb" option.  Is this an 
oversight or is mdb going away already or am I completely confused?  I 
suspect the answer is #3  ;-)

Basically I need to know what to use in the "backend" & "database" 
directives (slapd.conf) or "olcBackend" attribute (slapd.d) if we want 
the mdb backend?

Thank you for your insights and any information you can share.

--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com, ComeHome.net

CONFIDENTIALITY NOTICE: This message is for the named person's use only. 
It may contain confidential, proprietary or legally privileged 
information. No confidentiality or privilege is waived or lost by any 
erroneous transmission. If you receive this message in error, please 
immediately destroy it and notify the sender. You must not, directly or 
indirectly, use, disclose, distribute, or copy any part of this message 
if you are not the intended recipient.