[Date Prev][Date Next]
OpenLDAP 2.1 (?) on RedHat Enterprise summary
This summer I'll be replacing our perfectly stable servers running openldap
2.0.27 (rebuilt with ldbm backend, berkeley db 4.1.25NC) on redhat
7.3+progeny to redhat enterprise. 2.0.27 is terribly unreliable on RHEL 3,
see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122356, so that's
clearly out. I'd like to summarize the issues and get updates.
We run a master and 3 slaves, typically 150K searches (mostly eq indexed
email aliases) and less than 500 mods/deletes/modrdns on a typical day (but
up to 7K changes when semesters roll over). TLS is a requirement, krb5 is
not (but it might be nice if it were stable).
* OpenLDAP 2.1 v. 2.2 - the sense seems to be that openldap 2.1.30 is where
I should focus my attention. Would anyone recommend that I jump to 2.2.11
* So is anyone running a serious production environment on RHEL 3/openldap
2.0.27? How did you compile/configure it so that it crashes less than
twice per week?
* Kerberos. There are some old notes that heimdall is required because MIT
kerberos is not thread-safe. Is this still an issue? RedHat seems to
believe that it is not, because they link servers with 1.2.7-19.
* Backend - bdb is the clear consensus, with caveats that I need to read
the friendly cache tuning documentation.
* Berkeley DB version. 4.2.52+patches freshly compiled, no question. Don't
try to use the system installed version.
* libtool, automake, autoconf. I don't understand why the RPM builds have
gone back and forth on dependencies on particular versions of these.
Fedora Core 1.92 wants to compile local copies of all of these just for
openldap. Can someone point me to a discussion of why?
* NPTL kernel issues - redhat backported an entirely new threading model
from the 2.6 kernel. Here's where I'm lost. Mailing list mentions
possible severe performance penalty, with 2 messages recommending use of
the older RHEL 2.1 instead of 3 for this reason. Fedora Core 1.92 adds
extra linkage with this note. Does this patch resolve the problem? Would
building and running with LD_ASSUME_KERNEL=2.2.5 be a good idea?
# Build an NPTL libdb if we're on a Linux arch with NPTL. NPTL gives us
# the ability to share mutexes between threads in different processes, and
# to have threads in both honor those locks. We have to do this because if
# you build libdb with support for intra-process locks, it dies if you
# don't have it and the application has specified to libdb that it's
# multi-threaded (as slapd ability to share mutexes between threads in
# different processes, and to have threads in both honor those locks. We
# have to do this because if you build libdb with support for intra-process
# locks, it dies if you don't have it and the application has specified to
# libdb that it's multi-threaded (as slapd does).
Rich Graves <email@example.com>
UNet Systems Administrator