Hi Pascal,
We also faced this issue of having no cookie set prior authentication
and simply solved it with mod_headers this way:
Header add Set-Cookie "SOGOID=.%{BALANCER_WORKER_ROUTE}e; path=/"
env=BALANCER_ROUTE_CHANGED
ProxyPass /balancer-manager !
ProxyPass / balancer://sogocluster/ stickysession=SOGOID
<Proxy balancer://sogocluster>
BalancerMember http://vmsogo1.univ-rennes1.fr/ route=vmsogo1
timeout=60 loadfactor=100
BalancerMember http://vmsogo2.univ-rennes1.fr/ route=vmsogo2
timeout=60 loadfactor=100
</proxy>
Hope this helps,
PA
Le 10/12/2010 16:05, Pascal Gienger a écrit :
I saw that bug #698 is on the roadmap for 1.3.5, nice.
Another idea for that:
It would be a FINE idea to include a suffix in this cookie with a unique name
for that node where sogod runs on. The suffix has to be separated by a dot (and
no other dot must appear in the cookie):
Example:
Set-Cookie: 0xHIGHFLYxSOGo=r5hfjkrblvhjlvrjehjkgfhrkj4kl3hjgb4glbv.node01;
Path=/SOGo/
In that case, you may write in the front end Apache (example from my setup)
<Proxy balancer://sogocluster>
BalancerMember http://10.0.0.2:20000/SOGo route=edea
BalancerMember http://10.0.0.3:20000/SOGo route=bafoussam
BalancerMember http://10.0.0.4:20000/SOGo route=kousseri
BalancerMember http://10.0.0.5:20000/SOGo route=limbe
RequestHeader set "x-webobjects-server-port" "443"
RequestHeader set "x-webobjects-server-name" "sogo.uni-konstanz.de"
RequestHeader set "x-webobjects-server-url" "https://sogo.uni-konstanz.de";
RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
RequestHeader set "x-webobjects-remote-host" "%{SENDER_IP_ADDRESS}e"
AddDefaultCharset UTF-8
ProxySet stickysession=0xHIGHFLYxSOGo (1)
Order allow,deny
Allow from all
</Proxy>
The "route" parameter on "BalancerMember" names this particular worker route and the
cookie's name mentioned with "stickysession=" is used to derive the route where the request has to
be sent.
AN idea would be to use one of these nifty dictionary variables of "defaults"
(GNUstepdefaults), something like "defaults write sogod SOGoClusterNodeName bafoussam"
(as an example).
The user would be on the same machine after login eliminating all kind of
synchronization issues and you still have a load balanced session. If one node
breaks the apache uses another route or breaks the session, it is up to you to
configure it.
(1) In my actual setup I am doing this voodoo magic in my updated sogosession (not yet public)
apache module with an additional cookie ("uniknsogoroute") with the value
"worker.${nodename} which is set from inside the module to select the right worker. It
works nicely here with 4 cluster nodes. So in my config there is in reality
ProxySet stickysession=uniknsogoroute
Pascal
--
users@sogo.nu
https://inverse.ca/sogo/lists
