[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP 2.1 (?) on RedHat Enterprise summary
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?
At least this switch can be staged easily.
> that MIT Kerberos libraries are still not thread safe. Note that you only
> need Heimdal compiled on the OpenLDAP servers, and you can use MIT as your
> kerberos distribution in general (we do). I.E., all our login binaries are
> compiled against MIT Kerberos, etc. It is only the cyrus-sasl/openldap
There isn't any symbol pollution or anything, is there? Just risks if you
actually try to *use* kerberos calls in a multithreaded app?
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.
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.
> 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. :-)
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'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.
--
Rich Graves <rcgraves@brandeis.edu>
UNet Systems Administrator