Forum OpenACS Development: Apache as a frontend: sharing our experience

What I grasp from the "Apache support critical" and "forget about apache support" threads is that it seems there is some interest in using apache as a frontend to to openacs.

That's actually what we (SII) are doing on one of our production machines.

Leaving aside the "why" (which we could discuss separately), let me give you a brief overview of the how.

I’m referring to an "out-of-the-box" configuration for apache 2.0.56 on fedora 3. (althought from my experience most of the parameters would do ok on apache 1.3.x series).

1st) check activation mod_proxy within apache (as well as mod_rewrite if you want to do some tricks) – those are in by default.

2nd) Set following options. (ProxyRequests On is not necessary since we are not really proxying but just "reverse" proxying).

ProxyTimeout 600 (according to your preferences)

ProxyPreserveHost On (necessary as long as the host you are calling matters to openacs: eg if you are using host-node maps or doing any hostname-based request processing within oacs. I think this would be a feature missing on earlier apache versions)

3rd) Then within each apache virtual host you want to be an openacs frontend:

and that would do the trick, as long as

a) openacs is bound to the (localhost) port corresponding to the one you want to expose it externally through apache.

b) the "hostname" is corresponding to the parameter you set in oacs config.tcl (don’t use localhost there)

to do a more sophisticated reverse proxying (such as exposing multiple oacs instances on port 80, as well as having them bound to different localhost ports (or even on an external ip, be it the same as apache or else) ), a bit of a hack in utilities-procs.tcl (thanks for this to jade) would be necessary:

a) add the following to acs-tcl/tcl/utilities-procs.tcl in util_current_location just before last "if" (circa line 2780) (this assumes you want apache to serve it through port 80, while oacs is not bound to port 80):

#HACK TO WORK WITH NON - STANDARD PORTS

#as per message_id 84289 in oacs forums

return "$proto://$hostname"

b) configure the apache virtual host directive:

<VirtualHost hostname:80>

ServerAdmin webmaster@sii.it

DocumentRoot /www/docs/default.server

ProxyPass / http://hostname:8002/

ErrorLog logs/default.server.error_log

CustomLog logs/default.server.access_log common

</VirtualHost>

This works, and with a bit of tuning for apache is also performing acceptably.

There is one limitiation I can recall: webdav should be accessed bypassing the proxy because (i think) it doesn’t go through the hack above, although file storage UI displays the address you should connect to as the one set in kernel systemURL parameter (while instead it should display the config.tcl parameters), well this is a bit confusing but hasn’t really got to do with the philosophy of the apache reverseproxying method.

Obviously you should set oacs kernel SystemUrl parameter according to what you set in apache VirtualHost.

By using mod_rewrite some more tricks could be done, (such as exposing different static frontends on a per-hostname basis) and then redirecting "real" openacs requests to the same openacs/.LRN instance.

Let me know if anyone uses this and if successful.

BTW: this same thing can be done by using AOLserver+nsvhr (nsunix instead doesn’t seem to compile on AOLserver 4.x) as a reverseproxying frontend, requiring the same tcl hack, and needing a couple of aolserver patches (for doing uploads and passing the remote ip – for logging purposes - to the proxied instance).

As a reference on this there is some documentation and the patches:

http://borkware.com/rants/aolserver-vhosting/

I’ve not been able to use WebDav with this, but that could be just the same problem as per apache. What can make a difference is that it seems better performing than the apache solution: that’s something we already knew, alright.