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

[Mike Rylander]

Mostly out of curiosity (mixed with just a pinch of ego ;), I'd be
very interested in hearing more about your setup.  You mentioned
pgpool -- are you using pgpool I or II, and are you replicating using
that?  And, are you using the VMWare images as the basis of this
cluster?  I imagine that answers to those questions would be
informative for others as well...

TIA

--miker

On 5/22/07, Mike Rylander <mrylander at gmail.com> 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.
> >
> >
>
>
> --
> Mike Rylander
>


-- 
Mike Rylander