[Date Prev][Date Next]
Re: OpenLDAP 2.1 (?) on RedHat Enterprise summary
I'll hit these one by one, to the best of my knowledge at this time.
On 6 May 2004 at 10:55, Rich Graves wrote:
> 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
Many people will. I will not. I recommend 2.1.25 because that's what I am
using successfully. 2.1.30 is too new for me.
> * 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?
I was unable to get it to run reliably under load on any version other than
RHL 9.0. I could make it run with 7.3 and 7.2 as long as the load was very
light. I spent about 3 years working with Red Hat's packages, I think... maybe
more! (I started doing OpenLDAP on Red Hat when v6.2 was still supported).
> * 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.
Kerberos/LDAP integration is too much work for too little return, unless you
require that level of security (such as in a University environment?). SASL is
arcane and immature.
> * Backend - bdb is the clear consensus, with caveats that I need to read
> the friendly cache tuning documentation.
I am happy with ldbm so far. I have no requirements it doesn't satisfy, so
why should I bother with all that tuning?
> * Berkeley DB version. 4.2.52+patches freshly compiled, no question. Don't
> try to use the system installed version.
I am using Jehan Proccaccia's SRPMS to build my RHEL3 RPMS. They use patched
4.2.52 I believe.
> * 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?
Google the list. I agree with Red Hat, I like to have my system
authentication stuff kept separate from other uses, so this doesn't bother me.
Disk space and compute cycles are cheap!
> * 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?
I don't know the answer to this; but our problems with the threading on RHEL3
(which were not LDAP related anyway) cleared up after a few kernel up2dates.
Red Hat seems to be aggressively pursuing the remaining bugs.
I like OpenLDAP, a lot. But then again I like the sasser worm ;) so I may
not be a typical user.