Forum OpenACS Q&A: Multiple sites, one AOLServer, and one database?
multiple, related sites. I know that it's possible (using nsvhr) to
have one copy of AOLServer host multiple virtual hosts. My question
is whether I can (or would even want to) have multiple OpenACS sites
share a single database.
In most cases, I can see where this would be a bad idea; if there
isn't any overlap among the users, administrators, or page design,
then sharing an OpenACS instance wouldn't be of much help.
But I have another client where the whole point of the system is to
have multiple domains that share a list of users. That is, the same
user and groups will apply to www.abc.org, www.def.org, and
www.ghi.org -- but the contents and design of the three sites will be
different. Each site will be able to choose which applications it
wants to use, which I'll simply mount on an appropriate URL.
(In case you think that I'm totally out of my mind for wanting this,
consider that abc.org is an umbrella organization that includes
def.org and ghi.org. And there are common members to def.org and
ghi.org that we'll want to query from the umbrella organization, in
addition to the individual organizations.)
Does anyone have any good suggestions for doing this sort of thing? I
imagine that virtual hosts with AOLServer is the right way to go, but
perhaps rewriting the URLs (with AOLServer or Apache's mod_rewrite) is
the right thing to do.
In case you aren't aware a single instance of OpenACS supports mutliple subsites, each of which could be separate instances of most applications in the toolkit.
I do remember there were a few issues with the host-node map and things like permission checking, but perhaps someone can remind me if that all got resolved. Don?
But I have another client where the whole point of the system is to have multiple domains that share a list of users. That is, the same user and groups will apply to www.abc.org, www.def.org, and www.ghi.org -- but the contents and design of the three sites will be different.I am working on exactly this problem with Greenpeace International, which is made more complex by the fact that we're talking about countries, which means the various subsites are to be presented in different languages. We're basing our work on OpenACS 4.5.
The basic mechanism which is available is acs-subsite. You can mount as many subsites under the main subsite as you wish, and then - as Simon suggests - use the site-node mapping feature to point your various domain names to the appropriate subsite.
You can change the look and feel of each mounted acs-subsite instance by changing the "default master" parameter to a subsite-specific master. This master will let you wrap custom headers and footers, and if you use a table for the page, custom column elements. For instance you could have a leftmost column nav widget that's customized for each subsite, with content from the OpenACS 4.5 packages put in the right column.
And of course each master can define its own CSS stylesheet.
This alone gives you considerable power to change the look and feel for each subsite.
In the case of Greenpeace, this isn't quite sufficient so we're providing a mechanism to allow the mapping of arbitrary custom templates to arbitrary package pages. I have some ideas for generalizing this in the future for use in the standard toolkit, but frankly I think 90% of folks needs can be met by the process I describe above using subsite-specific default master templates.
Currently all users in OpenACS 4.5 have access to all subsites. There's a special "membership" group in acs-subsite that allows the segregation of folks by subsite, but this isn't interwoven into the various packages at this point in time. However, it sounds like you want everyone to have access to each subsite. You can control access further by use of permissions ...
I will definitely want to give a different look-and-feel to different subsites, and the ability to change the master template will definitely make that pretty easy. Between that and different CSS stylesheets, we should be just fine.
Believe it or not, permissions will be important. The umbrella organization wants to be completely sure that the individual member organizations won't have access to each other's data, except when explicitly allowed. But once I learned about the subsites, those worries went away.
As for the site-node mapping, that seems to work for URLs within a single domain. But what happens if I have different domains, each of which should point to a different URL inside of my OpenACS site? (Or do I just need to read more documentation?)
I keep telling people that everything you want is somewhere within OpenACS, if you look hard enough...
to a subsite (or URL) such as
/my-domain... i.e. it maps to www.real-domain.com/my-domain
Therefore you can have different URLs point to the same AOLServer instance, but when request hit the site, the host-node map directs them to the appropriate subsite based on the URL they requested.
so, you could have three subsites mounted as
with sub-one.com mapping to sub-1
sub-two.com mapping to sub-2
sub-three mapping to sub-3
then if someone went to www.sub-two.com they'd actually end up at your subsite i.e. /sub-1
I agree wholeheartedly.
So when are we going to see an OpenACS 4 LJ article? wink, wink, nudge.
How about an introduction to AOLServer in the September issue, followed by several articles on OpenACS in the October through December issues?
I actually would have started on OpenACS previously, but Apache 2.0 and the LJ 100th issue forced my hand a bit. But don't worry; OpenACS will get treatment equal to what I did for J2EE and Zope! (The article -- and book, I hope -- comparing the environemnts will come soon afterwards...)
Sounds good. Count on us (the community) to help out.
Subsites might turn out to be the killer application for openACS. Being able to provide a complete web presence for a parent organisation while allowing each subsidiary to customise its own look and feel is not as unique a requirement as one might think.
As PhilG might put it, it becomes a lot easier to build purposeful communities around particular subsidiary/product/brand/department/region .....
With subsites, portals, groups and host-node-mapping (dotLRN anyone?), one can build some really powerful websites!
I have used subsites for on our extranet. Basically for each client we have an extranet. I customized acs-subsite and mount bboard, file-storage and ticket-tracker-list on each subsite. Since I needed permissions I have made use of groups.
For every subsite there is an application group, party that is associated to it. For each of our client I mount the subsite and change the permission so it will not inherit from "Main Site". I then mount the other packages. But since this packages will have the context_id pointed to the "Main Site" rather than the subsite it is mounted into. I then do an update a couple rows on acs_objects with something like this.
update acs_objects set context_id = '[object_id of new subsite]' where object_id = '[object_id of file storage]' or object_id = '[object_id of bboard]' or object_id = '[object_id of tt-lite]';
Although for some weird bug all new subsites has a relationship with the first subsite. I then have to nuke this relationship on the table acs_rels.
As for the users since the group pages admin still broken I was lazy not to make admin page on my own and sql does gives me some flexibility. I manually put in the relationships. I do a
You can get the group_id on groups table.
So far our clients are happy but I did uncover a performance problem in file-storage. You may also want to use [acs_root]/www/templates/[subsite1] rather than [acs_root]/templates. Since most of the time the templates are not just tcl and adp, I put in some logo, images and css files.
I hope this helps to anybody who has a similar case. And maybe see some stuff that we should fix in OpenACS.