[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP in large environment
-----BEGIN PGP SIGNED MESSAGE-----
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.
Why?
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
would
| like to offer any opinions please let me know.
|
| SLAPD.CONF
| 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
|
| DB_CONFIG:
| 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.
| set_flags DB_LOG_AUTOREMOVE
| # 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
iD8DBQFBuAL8rJK6UGDSBKcRAuINAJ0b7bfXgjE209ArUCIgQqqp4+CTKACglMA2
YYSUfQ9GioMfOynVBpPDYck=
=pT5d
-----END PGP SIGNATURE-----