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

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
  instead?

* 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 <rcgraves@brandeis.edu>
UNet Systems Administrator