I've been having problems with the through-the-web cut-and-paste
functionality in a plone site running in multiple zope client
instances load balanced via pound.
Here's what is happening.
My site is running on a three server cluster. Server 1 (hereafter
S1) listens for client requests via apache and rewrites requests to a
squid instance listening on localhost:3128. Squid passes requests
back to a pound instance listening on localhost:8992. Pound balances
these requests across five zope instances running on server #2
(hereafter S2). The zope instances all refer to a single zeo
instance running on server 3 (hereafter S3).
So in summary, my signal chain looks like this:
Apache (S1 port 443) -> Squid (localhost:3128) -> Pound (localhost:
8992) -> Zope Clients (S2:8901-8905) -> Zeo (S3:8100)
My zope instance is failing to properly allow cut-and-paste through
the web. Generally, this problem is attributable to an issue with
session affinity. There appear to be two ways to deal with this
problem when load balancing via pound. #1 is to implement session
affinity via cookie in pound. #2 is to move zope's temporary storage
(which holds session data) back into the zeo server so that all zope
clients use the same information. This second option is the route I
have chosen.
I've tried several alternative strategies with the following results:
I've set up an alternative virtual host in apache on S1 listening on
port :8901. This virtual host sets a few headers needed to fake
authentication that would normally have been handled by apache via
the pubcookie SSO system. It passes requests back to squid, then
pound using the exact same instances with the exact same
configuration as the normal apache :443 virtual host. Cut-and-paste
when using this virtual host works perfectly.
I've also tried removing squid and pound from the signal chain and
load balancing directly from apache on S1:443 to the zope clients on
S2. Cut-and-paste works perfectly in this configuration as well.
I've set up squid to log request and response headers that it sees,
and in all three of the above configurations, squid sees the cookies
that zope/plone sets for cut-and-paste (as well as all other sso
authentication cookies and status messages set by plone).
I've used tcpdump to read packet traffic on S1 localhost:8992 to see
the traffic going into pound. In all three of the above
configurations packets at that interface and port still contain all
the required headers.
I've set up a python script in zope that shows me the request headers
that zope sees once the request gets there. In the problematic
configuration (apache:443->squid->pound->zope->zeo) _all_ headers
are
missing when the request reaches zope. In the other two
configurations (both of which work for cut-and-paste) _all_ headers
are still present when the request reaches zope.
From this, I am forced to conclude that somewhere in the operation
of pound, all cookie information in my request headers is being
stripped, but only on the condition that the request originated from
an SSL request to apache.
I'm wondering if there is anything that might account for this
behaviour. Have you ever seen or heard of anything like this? Is
there any misconfiguration on my part that might account for the
problem? If not, do you have any suggestions for how I might begin
to debug the issue? I'm a bit stumped at this point, as pound is
something of a black box to me :)
All three of my servers are Apple Intel XServe boxes running OS X
Server 10.5.8. I am using apache 2.2.11, squid 2.7stable6 pound
2.4.3 with configuration switches --enable-ceret1l and --with-ssl
(and the path to ssl is valid). Zope is 2.12, plone is 3.1.7
Thanks for reading to this point, and in advance for any help you
might be able to offer
Cris
********************************
Cris Ewing
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
Pager: (206) 559-2306
E-mail: cewing(at)u.washington.edu
Web: http://www.rad.washington.edu
*******************************
|
