[Deploying Sakai] For folks using load balancers...

[David Adams]

Hey everyone, just saw this thread. Every load balancer and reverse proxy I've worked with sets the X-Forwarded-For header in the HTTP request, and so we've been using that. For logging, you can tell Apache or Tomcat to log a particular header instead of (or in addition to) the remote IP with the "%{X-Forwarded-For}i" log format placeholder.

The only problem with X-Forwarded-For that makes it not suitable to be a complete drop-in replacement for IP address is that it stacks at each layer, so if the users are coming in from behind another proxy or through multiple layers of proxy/load balancing in your architecture, you'll get a comma-separated list of IPs intead of a single IP.

However, that works well enough for us, and just adds a little bit of extra post-processing.

As to the more immediate issue of the SAKAI_SESSION table and session objects in memory keeping track of remote IP, I came up with a small patch that takes care of the issue in one swoop. I'll attach it to this message, but basically, in the kernel session creation code, it checks for the X-Forwarded-For header, and uses it in place of remote IP if it's been set. This works great with an Apache reverse proxy and a BIG-IP load balancer, while still correctly tracking actual direct-to-tomcat requests from our internal network or localhost (which can't be said for the log format hack mentioned above).

-dave


Maurer, Christopher Wayne wrote:
> Excellent, thanks guys!
>
> Chris
>
> From: Matthew Jones <jonespm at umich.edu<mailto:jonespm at umich.edu>>
> Date: Thu, 3 Nov 2011 09:28:59 -0400
> To: Seth Theriault <slt at columbia.edu<mailto:slt at columbia.edu>>
> Cc: production <production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>>, Chris Maurer <chmaurer at iupui.edu<mailto:chmaurer at iupui.edu>>
> Subject: Re: [Deploying Sakai] For folks using load balancers...
>
>
> Right, was in this thread. Sam was also using it.
>
> http://comments.gmane.org/gmane.comp.cms.sakai.production/2052
>
> We locally talked about a code/property change where you could specify which header the real remote ip was in. This solution is already available though. :)
>
> On Nov 3, 2011 9:25 AM, "Seth Theriault" <slt at columbia.edu<mailto:slt at columbia.edu>> wrote:
> Maurer, Christopher Wayne wrote:
>
> > This isn't exactly a new problem for us, just thought I'd ask
> > others and see if maybe it's a configuration issue. Any calls
> > in the code for request.getRemoteAddress() always return the IP
> > of the load balancer.  We do pass the client's IP through in
> > the request header, so it's available, but we'd have to
> > specifically ask for it when we want to check for it.  Can you
> > tell either tomcat or the load balancer to do that so
> > getRemoteAddress() returns the IP of the client?  As an example
> > of the results of this, all the records in our sakai_session
> > table have the load balancer's IP in the session_ip column.
> > Just curious what others do here.
>
> I use this Tomcat valve locally:
>
> http://code.google.com/p/xebia-france/wiki/RemoteIpValve
>
> I mentioned it about a month ago on this list.
>
> Seth
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-- 
David Adams
Director, Learning Systems Integration and Support
Virginia Tech Learning Technologies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xff.patch
Type: application/octet-stream
Size: 1489 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20111121/0304cbb8/attachment.obj