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

Re: OpenLDAP in large environment

--On Thursday, December 09, 2004 11:53 AM +0930 David.Brown@csm.com.au wrote:


Thanks for the RAM suggestion. I have already been through the pages you
mentioned on your site and have shamelessly borrowed some of the
configuration options mentioned :o)

Did you have any problems with regards to interoperability with client
programs and OpenLDAP 2.2.19?? (Courier-Imap seemed to be causing some
issues although that software has been a problem child of late anyways so
it might just be a courier problem).

There are a variety of client programs that quite frankly have not kept up with the times as far as the LDAP protocol is concerned, and only understand V2 binds & username/password to connect, which in Stanford's environment, at least, presents a significant problem given our security requirements (no passwords being in the directory DB being one).

I've not used courier IMAP (we use Cyrus-IMAPD and sendmail for our mail systems, with a look towards postfix in the near future to replace sendmail).

Did you have to do any management of the BDB backend using the BDB tools??
The most painful part of OpenLDAP 2.2 (having moved from 2.0) is having to
manage the BDB side of things as well as the LDAP side of things. I have
also found that openldap rpms bundle and complie its own BDB software into
the ldap package and do not use the system librabries for bdb. In OpenLDAP
2.2.19 the BDB is 4.3 whereas the latest rpm version available is only bdb
4.2 so system utility files such as db_stat do not work (as they are 4.2
versions and the database is 4.3).

Other than doing the initial proper configuration of BDB, no, I don't really have to do anything with the BDB side of things. I'll note that BDB 4.3.21 is not a release I'd recommend using, and there is no issue using BDB 4.2 with OpenLDAP 2.2.19. If you are wanting to use packages that others create, rather than do the compiling, etc, yourself, then I suggest going with a product like CDS from Symas corporation (http://www.symas.com) where you can get support along with it. I routinely build Stanford's OpenLDAP distribution (and the underlying software pieces), keeping them up to date, and applying patches that aren't necessarily in the releases, but this does consume a fair chunk of time for tracking everything as well as testing the new compiles, etc.

Might have to move away from rpms. Here is a copy of our slapd.conf and
DB_CONFIG just for your info. If you can see any glaring stuff ups or
would like to offer any opinions please let me know.

allow bind_v2

threads 64

I doubt that you want 64 threads. The more threads you have, the worse your performance will get after a certain point. I've so far not seen any need to go past the default under linux (16), and on Solaris the max I use is 20.

schemacheck off

It is generally a good idea to enforce schema checking.

idletimeout 30

database        bdb
cachesize       20000
idlcachesize    20000

This depends in part entirely on what you think the active set of entries in your cache will be. Probably reasonable for a start.

sizelimit       250000
# checkpoint      1024   5

Checkpointing is a plus, I suggest enabling it. ;)

loglevel 0

I run with loglevel 256. I found that on linux, using asynchronous syslog, there was no noticeable difference between loglevel 256 and loglevel 0. See "man syslog.conf", and the "-" symbol.

lastmod on


set_lk_detect DB_LOCK_DEFAULT

I've never used the above setting, so can't comment there.

set_lg_max 10485760
set_cachesize   0       52428800        0

a 50MB cache is probably small for a database the size of which you are talking, but your indices don't look very complex. I would suggest getting an idea of how long slapadd takes at various DB Cache sizes. If you get to a point where it doesn't make a difference, you've found the size of your current DB. You then want to allocate over that for growth. ;)

set_lg_regionmax 262144
set_lg_bsize 2097152
set_lg_dir /var/lib/ldap
# Automatically remove log files that are no longer needed.
# Just use these settings when doing slapadd...
# set_flags DB_TXN_NOSYNC
# set_flags DB_TXN_NOT_DURABLE

This is probably getting off topic for the list though, so if you want to follow up directly, that is fine.


Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html