[SAC] Vhost standards, etc...

[Jason Birch]

I think that we need to remain flexible, to a certain degree :)

Part of the problem is that many existing projects are using their own infrastructure, including CMS of choice, project tracker of choice, etc.  I'd suggest the following:

- For projects wanting to use their own infrastructure, redirect a host (project.osgeo.org) to their chosen IP.
- Use osgeo.org/projects/projectname as the location for "marketing" content
- Use projectname.osgeo.org to host community-focussed content, such as documentation, Trac, etc, using our standard provided/supported toolset.  It may be useful for direct requests to / on projectname.osgeo.org be redirected to osgeo.org/projects/projectname ?

I agree that keeping multiple instances of Drupal is a maintenance nightmare, but projects will absolutely need their own Trac instances, svn repositories, etc, so we may as well have a host for each project.  It introduces less risk than trying to manage them all under one host.

In any case, let's talk about this more in January, once we're on the new infrastructure and are thinking more about ongoing information/infrastructure management than just moving what we've got.

Jason


-----Original Message-----
From: Tyler Mitchell [mailto:tylermitchell at shaw.ca] 
Sent: Friday, December 15, 2006 10:50
To: sac at sac.osgeo.org
Subject: [SAC] Vhost standards, etc...

On 15-Dec-06, at 6:23 AM, Kanhaiya kale ( कન્હૈযা ਕਾளெ ) wrote:

> Hi jo walsh,
> Yeah it can be possible to handle multiple drupal instance with   
> little  difference.
> As soon HyperJohnGraham  create a virtualhost for this on telascience 
> server, i will copy current drupal instance there and make some policy 
> to share themes and modules.

If we've had this discussion already, please remind me.. but it seems we need to agree on our approach for handling subdomains/vhosts on our new install.

This affects both mailing lists and drupal sites equally as much.   
Because our historic infrastructure automatically creates subdomains for every project, we have a legacy of many many subdomains that are marginally useful.

I think we've already discussed mailing lists, but I hope we can move to a format like:
project at lists.osgeo.org and project-dev at lists.osgeo.org

Instead of the historic discuss at project.osgeo.org and dev at project.osgeo.org.

Similarly on the www/drupal side, we have http://project.osgeo.org, even for projects that have a marginal web presence.  I believe it is safe to say that maintaining this level of vhost management is more painful than simply adding node-based drupal urls like:
http://osgeo.org/project
That way there is no vhost set up required and CMS managers can do dirty work without bothering sysadmins.  Of course, we have some legacy usage of http://project.osgeo.org - but can we do some rewrites to handle this in the meantime?

I am innately opposed to having multiple drupal instances unless we really really need to.  I don't assume I'm correct in my logic, but I think this is a good time to aim for simplicity.  So I ask, at what point do we want/need to keep content all in the same drupal instance?  Can we aim to reduce our need to use subdomains?  When  is it beneficial to use them instead?  Can we 'theme' different parts of a drupal site, i.e. by group? (e.g. so http://osgeo.org/project1/* has different theme than http://osgeo.org/project2/* )?

Other thoughts?  Am I being too complicated or too simplistic?

Tyler