[SAC] Vhost standards, etc...

[Allan Doyle]

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 :)
>> 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
>
>
> -- 
> Daniel Morissette
> http://www.mapgears.com/

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org