Forum OpenACS Development: Re: Multiple DNS and subsites

Collapse
Posted by Benjamin Brink on
With 5.7, maybe this variation will work for you:

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).

cheers,
Ben

Collapse
Posted by Benjamin Brink on
ps, Know that host-node mapping tends to be unstable between releases. It requires extra time to periodically test and maintain between upgrades, because it is rarely tested before new releases (and apparently rarely used);

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.

Collapse
Posted by Gustaf Neumann on
The right way to aim for a "stable" host-node mapping is to add tests to the regression test suite (after sorting out, what in detail is expected or not). The host-node mapping is (and was since ever) very limited, but it seems useful as it is for several sites.... but actually, i am not aware of site using it.

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.

Collapse
Posted by Benjamin Brink on
I'm sorry; I should have provided more context for my comments about the unstable nature of ad_conn in context of host-node mapping:

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.

@Gustaf,

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.