Forum OpenACS Development: Re: Multiple DNS and subsites
What naviserver and OpenACS version are you using?
The host-node part of it is working locally on ns 4.99.11 and oacs-5-9 (acs-kernel 4.9.1d4).
But, It seems the solution is one step further, in the application level. It requires something similar to example:
The user access eventeasy.iurix.com, OACS core notices the DNS is within hostnode's table, that the triple (eventeasy.iurix.com, 9589839, /eventeasy/)
OACS serves the entire subsite to the user as if it is /
In the worst scenario it would impact url's structure, and that means a core change.
Is there any other possibility?
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.
You can definitely map a domain name to a subsite, and serve that subsite as the root of the mapped domain. Is that what you are trying to do?
You should not need a proxy server, but if you are using one in addition to AOLserver or Naviserver the configuration is more complicated.
That's precisely what I'm trying to achieve. To map a domain name (i.e. eventeasy.iurix.com) to a subsite (i.e. /eventeasy), serving the subsite as in eventeasy.iurix.com/ , using a unique OpenACS instance,
The ideal is to not need different AOLServer settings, neither separated OpenACS instances.
p.s. I don't know if that is even possible in OpenACS, or even if it is its responsability to do so. But I can foresee this new feature as a parameter of the acs-subsite (/shared/parameters?...), i.e. DomainNameMapping
Good to know about Naviserver's virtual approach. Actually I'm thinking to move from AOLServer 4.5 to NaviServer soon. I already have a box runnig it. No problems so far.
I agree with Gustaff. Changes within ad_proc ad_conn and templating would have substancial impacts in OpenACS core and even non-core packages. In fact OpenACS is one oif the most stable framework available and there are reasons for that: 1. robust datamodel, 2. well implemented source code TCL and TCLO scripts, 3. regression test, 4. OpenACS installation tests, 4. DotLRN, frequently used packages, and the list goes on...)
There are an abundance of benefits to switching to naviserver and upgrading to oacs-5-9, if the system isn't using ecommerce package.
Here is an example of host-node mapping working as I believe you expect. One of the host-node sites: http://dekka.com which points to subsite: http://or97.net/dekka-com
(It just serves a static page right now; until we re-tackle the various templating / form issues.) No proxy is used.
That's exactly what I'm trying to accomplish. It's still not clear to me how to achieve it.
Is hostnode feature on OpenACS 5.7 and AOLServer 4.5 simply broken?
An incredible amount of refactoring OpenACS has happened since 5.7, incluiding upgrading tcl syntax. Here is a discussion about compatibility matrix of oacs 5.7 and dependencies: http://openacs.org/forums/message-view?message_id=3920280
And the compatibility matrix: http://openacs.org/xowiki/openacs-compatibility-matrix
Definitely go with naviserver if you can make the change.
Up to january this year, openacs.org had on average 1 error per second.
Concerning the request of Iuri: i did some tests and fixed a few issues (mostly IPv6) and the following testing scenarios work fine:
Testing setup (A):
- http-port: 8009
- https-port: 8443
- base-hostname: localhost
- alternate-hostname: hugo
- main-subsite: /
- alternate-subsite: /hugo
- host-node map: hostname "hugo" -> /hugo/
- apm-parameter (acs-tcl): UseHostnameDomainforReg: 0
In this setup, the subsite (here: /hugo/) has to be given explicit read permission for public, otherwise, one cannot login, since subsite/register won't work (one needs already permissions to reach the subsite main node). Therefore, the site-admin has to grant read permissions to the public explicitly.
Other than this, everything looks ok with setup (A), the subsite works with http and https.
Testing setup (B):
- same as above, but:
- apm-parameter (acs-tcl): UseHostnameDomainforReg: 1
When UseHostnameDomainforReg is activated:
- login is redirected to the main site; the return_url as well.
- login cookies are set on the main-site and are not available on the subsite via the browser (maybe when setting "CookieDomain" and use "domain cookies" and appropriate sub-domain host names; not tested).
- This means that out of the box the user does not stay on the subsite but has to do all authorized work on the main site (which makes management of different users on subsite useless).
Also setup (B) works as well with the newest version in the oacs-5-9 branch. There were some issues in earlier version, but the actual version is fine in this respect. No nginx is involved.
For more details. see: http://openacs.org/bugtracker/openacs/patch?patch_number=848
all the best
@Gustaff, Nice results!
So far, I've set up a fresh installation of OACS 5.9 instance under NaviServer and Postgresql 9.1.
I assigned eventeasy.iurix.com to the same IP that iurix.com uses. Both DNS's point to /var/www/oacs-5-9/. There is only one NS service up, thus a unique config file: iurix.tcl.
I've created eventeasy as an acs-subsite. I've created a host-node eventeasy.iurix.com /eventeasy
However I don't have the behavior expected. the address eventeasy.iurix.com shows the Main Site. It was supposed to display /eventeasy.
Take a look: http://eventeasy.iurix.com/