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

Re: OpenLDAP in large environment

Hash: SHA1

David.Brown@csm.com.au wrote:

Arghh, can you please try and reply/quote correctly? I'm not going to
waste bandwidth now to include your original statement I'm replying to,
but is there a reason you migrated an enterprise service from an
enterprise distribution to a community distribtion just to get an update
OpenLDAP package?

I've got a 2.2.18 package that builds on RHEL2.1, 3, Fedora Core 1 and
Fedora Core 2 (haven't got a Fedora Core 3 box to test on ...), that
also does handle some of these issues ...

| 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).
| Did you have to do any management of the BDB backend using the BDB tools??

You should evaluate whether it is useful to run database recovery at
every startup or not. For a large implementation for a client with a
cluster running RHEL AS 2.1 on shared storage, we decided that being
guaranteed of the slapd instance coming up was more important than a
temporary performance degradation ... so we ran database recovery during
the start() function in the init script.

| 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).

And, usually in this case, the package bundles it's own version of the
utilities as well, probably named slapd_db_*. Use those instead.

| Might have to move away from rpms.


OK, yes, RH's packages might suck, but that doesn't mean that you should
build from source. Rather, learn to use rpm ...

| Here is a copy of our slapd.conf and
| DB_CONFIG just for your info. If you can see any glaring stuff ups or
| like to offer any opinions please let me know.
| allow bind_v2
| threads 64
| schemacheck off
| idletimeout 30
| database        bdb
| cachesize       20000
| idlcachesize    20000
| sizelimit       250000
| #checkpoint      1024   5

You'll want to uncomment this again ^^^^, especially on Red Hat/Fedora.

| #dirtyread
| index   uid             eq
| index   uidNumber       eq
| index   gidNumber       eq
| index   memberUid       eq
| index   ou              eq
| index   cn              pres,eq,sub
| index   sn              pres,eq,sub
| index   objectclass     pres,eq
| index   member                  eq
| index   mailAlternateAddress    eq
| index   mailLifeLongAddress     eq
| index   mailDefaultAddress      eq
| index   mailHost                eq
| index   mail                    eq
| index   employeeNumber          eq
| index   relayAllow              eq
| index   relayDomain             eq
| index   default                 sub
| loglevel 0
| lastmod on
| set_lk_detect DB_LOCK_DEFAULT
| set_lg_max 10485760
| set_cachesize   0       52428800        0
| 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

- -- Buchan Milne Senior Support Technician Obsidian Systems http://www.obsidian.co.za B.Eng RHCE (803004789010797) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org