[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:
Quanah,
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.
SLAPD.CONF
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
DB_CONFIG:
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.
set_flags DB_LOG_AUTOREMOVE
# 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
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html