[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Bdb defaults - WAS: problem importing entries.

On Tue, 15 Jun 2004, Michael L Torrie wrote:

> servers.  OpenLDAP, however, has alwas caused me problems.  The most
> common problem I see is index corruption, or just plain segfaults, both
> of which are really hard to reproduce for the developers since they seem
> to be triggered by problems in my database (usually the standard
> recovery and reindex commands send it on its way again).  We've now
> taken to stopping LDAP every night, dumping it out with slapcat (for
> backup purposes), running slapindex, and restarting it.  This seems to
> prevent some of the indexing problems we've seen, and keep OpenLDAP a
> bit more stable.

To present an alternative experience, we are running OpenLDAP
2.1.25 + BDB + back-bdb on three RedHat Linux 9.0 boxes
(one master, one replica, one test box). I configured OpenLDAP after
reading the OL Admin Guide and FAQ, recommended portions of the
SleepyCat docs, and archived OL listserv posts about back-bdb and
RedHat Linux. With the exception of a leaky RedHat library <insert
sound of grinding teeth here> that makes it necessary for me to
restart slapd occasionally to keep its memory footprint down,
OpenLDAP has been fast and rock stable. No indexing problems, no
seg faults, etc.  It just sits there working and makes everyone
here happy.

> I know that the OL developers can't be expected to provide settings for
> all, or even many configurations.  But it seems to me that most OpenLDAP
> users work with several thousand or less users, so providing example
> settings to work with with that kind of load might be appropriate.

Unless "example settings" come from another OL implementation that
is nearly identical to my own WRT hardware, LUAs, number of entries,
indices, attributes, etc. etc.  aren't I going to have to read the
docs and do my own configurating anyway? Would I risk my employer's
account authentication infrastructure (to take just one possible
LDAP application) on "example settings" that have been provided
without regard for our needs or limitations?

I'm rather grateful that the OpenLDAP developers have not made
any assumptions about what constitutes the group of "most OpenLDAP

Kirk Turner-Rustin
Libraries and Information Services
Ohio Wesleyan University