[OPEN-ILS-DEV] login problem with Evergreen and LVS -- SOLVED

[dkyle]

Nope, both EG app servers are running their own memcache - we'll have to 
change that.

How do you guys deal with memcache for a bunch of EG app servers?

Mike Rylander wrote:
> On 5/22/07, dkyle <dkyle at grpl.org> wrote:
>> After some more poking around, I'm guessing that the client receives a
>> session key from the initial http request, and any subsequent https
>> requests to a server that was not aware of that key (the other real
>> server in my case) would fail?
>
> The most likely reason is that the auth service is not using the same
> memcache pool on both of the EG app servers.  If this is the case,
> you'll likely get errors about not being logged in or sessions timing
> out or the like from within the staff client.
>
> Can you confirm that both EG servers are pointing to the same set of
> memcache servers (opensrf.xml =>
> /opensrf/default/cache/global/servers/server)?
>
> --miker
>
>>
>> We had two different virtual services setup, http, and https.  I changed
>> the LVS to use one virtual service for the virtual IP regardless of
>> port, and it works.
>>
>> dkyle wrote:
>> > We are testing a small Evergreen cluster.  We setup two servers
>> > running Postgres and pgpool, two "real servers" running Evergreen, and
>> > one LVS server.  Login with the Evergreen client would sometimes fail
>> > with a lengthy message regarding no authentication seed being found.
>> > Some packet capturing revealed that the error occurred whenever the
>> > LVS director changed real servers between the clients initial http
>> > request, and the subsequent https request.  This seemed a little
>> > strange since this involves 2 separate TCP streams.
>> >
>> > Is this what would be expected? If so, how have others dealt with the
>> > issue?
>> > What is going on with the client login process during the initial http
>> > request that requires the https request to hit the same real server?
>> > I did look through the packet decode for that, but I don't understand
>> > the internal workings enough.
>> >
>> > Doug.
>>
>>
>
>