RE: [SAC] Vhost standards, etc...

Committees SAC mailing list
1

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

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@shaw.ca]
Sent: Friday, December 15, 2006 10:50
To: sac@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@lists.osgeo.org and project-dev@lists.osgeo.org

Instead of the historic discuss@project.osgeo.org and dev@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

2

On 15-Dec-06, at 11:12 AM, Jason Birch wrote:

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.

Sounds good. The other reason I bring it up now is that we have this current issue of some subdomains having web content - and I'm wondering how we will address it within the drupal environment. For example where will the mapguide.osgeo.org content live within osgeo.org drupal site?

Tyler

3

I agree with Jason: trying to do everything under the same vhost (http://osgeo.org/project1, http://osgeo.org/project2, etc.) is going to be too limiting and we should use project.osgeo.org vhosts as he suggests. This will also allow for consistency between projects hosted on OSGeo infrastructure and project hosted on their own servers, i.e. their main URL will all be http://project.osgeo.org/

Also, another benefit of using vhosts this way is that the main website at http://osgeo.org/ will contain mostly OSGeo contents and a only mimnimum of project stuff, all owned and maintained by OSGeo, and project-specific content will always be under project.osgeo.org, owner and maintained by the respective projects.

Daniel

Jason Birch wrote:

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

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@shaw.ca] Sent: Friday, December 15, 2006 10:50
To: sac@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@lists.osgeo.org and project-dev@lists.osgeo.org

Instead of the historic discuss@project.osgeo.org and dev@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

--
Daniel Morissette
http://www.mapgears.com/

4

On Dec 15, 2006, at 16:47, Daniel Morissette wrote:

I agree with Jason: trying to do everything under the same vhost (http://osgeo.org/project1, http://osgeo.org/project2, etc.) is going to be too limiting and we should use project.osgeo.org vhosts as he suggests. This will also allow for consistency between projects hosted on OSGeo infrastructure and project hosted on their own servers, i.e. their main URL will all be http://project.osgeo.org/

Also, another benefit of using vhosts this way is that the main website at http://osgeo.org/ will contain mostly OSGeo contents and a only mimnimum of project stuff, all owned and maintained by OSGeo, and project-specific content will always be under project.osgeo.org, owner and maintained by the respective projects.

I agree with this approach. This seems also to be how MIT manages its webspace. Anything under web.mit.edu is maintained by the Information Systems & Services people and anything under xyz.mit.edu is maintained by xyz. Thus we actually have http://web.mit.edu/museum for the main museum web site and http://museum.mit.edu for project work that's not just web presence. (hmm. maybe that should be a counterexample)

I've found that once you get a system going for maintaining vhosts, it's pretty easy. I have several on the eogeo.org machines (lists.eogeo.org, lists.gsdi.org, wgiss.ceos.org, etc) and it's really not so bad. Some have their own IP addresses, others don't. The place things get tricky is for email vhosts with mailman. It's doable but I would suggest not trying. lists.osgeo.org should be sufficient for all osgeo.org email.

The other benefit of vhosts from the start is that it's easier to split them off onto separate machines as the load grows. If you use subdirectories for projects, then you have to manage a bunch of redirects to other machines if you move things.

Of course, this means that I'm also in favor of foss4g2007.osgeo.org vs. foss4g2007.org to comment on a different thread.

  Allan

Daniel

Jason Birch wrote:

I think that we need to remain flexible, to a certain degree :slight_smile:
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@shaw.ca] Sent: Friday, December 15, 2006 10:50
To: sac@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@lists.osgeo.org and project-dev@lists.osgeo.org
Instead of the historic discuss@project.osgeo.org and dev@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

--
Daniel Morissette
http://www.mapgears.com/

--
Allan Doyle
+1.781.433.2695
adoyle@eogeo.org