Re: OpenLDAP 2.1 (?) on RedHat Enterprise summary

["Medievalist" <ldap@HBCS.Org>]

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

  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.

--Charlie