Re: OL, SSL/TLS, and load balancing

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

It seems this thread has moved off-topic for this list.
Please direct further discussion of issues regarding use
of OpenLDAP Software to the openldap-software list.

Regarding the original issue, I suggest Quanah submit
an ITS (preferably with a patch).

Kurt

At 12:40 PM 5/4/2004, Donn Cave wrote:
>On Monday, May 3, 2004, at 01:46 PM, Quanah Gibson-Mount wrote:
>
>>Yes, our HTTP service is also load balanced... If you work with RL Bob Morgan, it wouldn't surprise me if the software you are using is the same we are using...
>>
>>When we initially went to deploy OpenLDAP, we experimented with the certs and software load balancing, without much luck... perhaps I should do it some more.
>
>Yes, he's involved, but this load balancing DNS service predates him,
>I believe parts of it came from UCLA's "groupd".   He has more than once
>brought the virtues of Stanford's way to our attention - I think you
>use an intermediate alias somewhere?  Ours just returns an A record with
>a rotating subset of the cluster IPs.
>
>This seems to work OK for OpenDLAP - with only one member in the cluster.
>I set that member up with an "ldap.washington.edu" (or something to that
>effect) certificate.
>
>For SSL, I expect the client to connect to ldap.washington.edu and not
>ever resolve that to ldap01.washington.edu.  Well, oddly, one ldapsearch
>seems to work fine with ldap01.  Others as expected do not work, but
>if I can figure out the difference, that may be the answer to the SSL
>replication and other cluster-member-specific operations.
>
>For GSSAPI, I expect the client to resolve to a canonical name, and this
>seems to happen (I get an ldap/ldap01 ticket.)   GSSAPI may be ready to
>go.  The clients are resolving the name, the only question is when.  If
>they're taking care of that BEFORE either requesting the ticket or making
>the connection, then we're fine, we just need them to connect to the same
>host as they got a ticket for.  This only shows up as a problem when there
>are multiple addresses and they're being shuffled.
>
>So this is way short of a complete success story - it's only initial
>reports from fooling around with a cluster of one this morning - but I
>haven't seen anything yet that looks like severe trouble for load based
>clustering.
>
>        Donn Cave, donn@u.washington.edu