Forum OpenACS Development: Re: Multiple DNS and subsites
In the past, with oacs-5.5 iirc, I ran multiple oacs sites from one ip address.
Each site was served from a different config.tcl, different port, different oacsroot file and different database; No host-node mapping.
A proxy server (apache proxy?) handled the calls between each domain:80 and each oacs:unique_port (forward and reverse).
If you try this, you might want to set the acs-tcl parameter SuppressHttpPort to 1 (and restart).
In addition to session issues, acs-core changes tend to break templating and some underlying ad_conn behavior used to generate forms, for example.
Proxy is most stable way to go.
A much more general virtual hosting approach is available in NaviServer (run multiple servers from a single nsd process, which might or might not have the same blueprints), but that approach is not integrated with OpenACS, since in OpenACS we try to keep AOLserver compatibility.
All releases of OpenACS are tested thoroughly (regression test, OpenACS installation tests, DotLRN, frequently used packages, ...). In addition, OpenACS.org is running as close as possible on the HEAD release (currently the newest version of the oacs-5-9 branch), so on the 70 packages in use on OpenACS.org, bugs are earlier detected.
If someone finds a bug (in templating, core, ...) please submit a proper bug report, where this issue can be addressed. I am not aware of any changed "ad_conn behavior used to generate forms". Such changes would affect openacs.org substantially. Vague and nebulous statements are not constructive and do not help.
Since Uri is using aolserver 4.5, I mentioned our local experience with using host-node mapping with aolserver 4.5 --not naviserver.
site_node::conn_url was developed (in 2009 and submitted to acs-core) in order to work around the inconsistent behavior of ad_conn. It was meant to provide a consistent url depending on if it is called from a main site or when called from a host-node. However, changes in core dependencies caused it to break soon after also. A fix was again provided that worked locally, but it again broke on next release. iirc. CVS browser highlights some of the history and forum discussion on it.
Part of the issue had to do with inconsistent view of the purposes of some of the underlying code between core developers.
The core and maintenance process has matured significantly since then. I'm sure a re-examination and development of regression tests will stabilize the feature into something quite useful. I'll file a bug/suggestion shortly.
Yes. Regression tests should be added at some point to stabilize feature(s). I was going to re-visit this and provide regression tests with bug report/suggestion; Alas regression tests are a few months away still.