RE: OpenLDAP 2.1 (?) on RedHat Enterprise summary

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Rich Graves

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

2.1.30 is the most stable release. With that said, our customers have been
happy on 2.2; it has
higher performance and a number of new features that they need. Also, 2.1 is
pretty much at the end of its life. If you're going to do a disruptive
migration anyway, it may make more sense to jump all the way to 2.2 and avoid
having to migrate twice in rapid succession. On the flip side, if you can
live with its feature set, 2.1.30 is probably stable enough to use
indefinitely. (Whereas the last 2.0 release was definitely not.)

> * 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.

It is still an issue. slapd will not run safely when linked with MIT
Kerberos.

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

None of these tools are needed when you're just compiling the released
OpenLDAP source. Only the OpenLDAP developers ever need to have them
installed locally.

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

Targeting 2.2.5 probably is no help since that was a development branch,
i.e., inherently unstable. If you're going to aim for a back-rev kernel then
target 2.2.4 which was a release branch. Your glibc will have to play along
too, otherwise you'll just make things worse.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support