[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP 2.1 (?) on RedHat Enterprise summary
--On Thursday, May 06, 2004 4:15 PM -0400 Rich Graves
<rcgraves@brandeis.edu> wrote:
Quanah Gibson-Mount <quanah@stanford.edu> said:
I'd just note that 2.0.x is deprecated and shouldn't be used anywhere.
It is sad that RedHat still ships it at all.
I do sympathize with their plight. Core LDAP services are not things you
want to be forcing your customers to rebuild completely every two or three
years. How long did it take Stanford to turn off kerberos 4?
We haven't yet. ;) But we get closer every year! :P A large number of our
services have been migrated to K5 at this point.
There isn't any symbol pollution or anything, is there? Just risks if you
actually try to *use* kerberos calls in a multithreaded app?
No symbol polluting. We install all the libraries into /usr/local/, and
that works just fine. Note that OpenLDAP is a multi-threaded application,
which is why this matters. I found that the entire application stack
(openssl,cyrus-sasl,openldap) became unstable when using MIT Kerberos, even
if I was simply doing anonymous binds to the OpenLDAP server.
I ask because RedHat links the world with MIT kerberos -- including
OpenSSL. As long as I don't configure SASL/GSSAPI, I don't have to mess
with recompiling a private copy of OpenSSL too, do I? RHEL 3 includes
openssl 0.9.7a plus backported security patches.
I suggest you compile everything into its own location (i.e., /usr/local).
Look at a package management software system like "stow". Then all of the
openldap related pieces live in /usr/local, and do not conflict with the
default packages shipped with RedHat.
We still have application needs for simple binds and userPassword in the
directory, so kerberos would just be a singe-login convenience for myself,
mainly. Our kerberos servers are Windows boxes, so we've already lost the
"separate identification and authorization data from authentication
tokens" battle anyway.
Unfortunate. ;)
You may also find these pages useful:
<http://www.stanford.edu/services/directory/openldap/configuration/index
.html>
I have, thanks. I used to work in Pine Hall, so I've been cribbing Jeff
and Bob and successors for years. :-)
Cool. :) You bugging Rob Riepel then? ;)
OK, so my only remaining unanswered question is how much I need to worry
about how well the new Native Poxix Threads Library stuff in RHEL 3 plays
with OpenLDAP. I guess nobody knows because the big sites just don't run
on RHEL 3.
I would be curious to know. I've had issues with multiple CPUs under linux
-- The servers seem to best perform when they are a single CPU.
I've considered switching to Solaris/Intel or even SPARC -- the Intel
price/performance advantage is much smaller than it used to be -- but
as a small school, I feel a need to stick with an OS my student sysadmins
can deal with in an emergency.
We run our current OpenLDAP servers under Solaris 8, and that has been rock
stable for us. A year ago, I attempted it under Solaris 9, and it failed
miserably. Sun changed how threading is done in Solaris 9 as compared to
8. I haven't had an opportunity to go and test under Solaris 9 since then,
so it may be better now, since a number of new kernel revisions have been
released.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html