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

[Mike Rylander]

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


-- 
Mike Rylander