[SAC] Vhost standards, etc...

[shawn barnes]

As usual Jason, this makes more than a little sense.

I prefer to not have multiple drupal instances running, the more
instances the more headaches in the long run.

i think only sysadmins should have shell access to the servers, as the
servers won't have sandboxes and the like for dev purposes.  Any direct
access or changes to the system should be done by a sysadmin.

shawn

Jason Birch wrote:
> Should probably put the question to the MapGuide PSC :)  My preference
> would be to split the content between the osgeo.org/project area and the
> projectname.osgeo.org, interlinking between the sites as necessary.  
> 
> Same goes for other projects with content in their host area.
> 
> Many of the projects have basic content at projectname.osgeo.org, but
> really these sites should either commit entirely to our infrastructure
> or have the host redirected to their domain.
> 
> Others have limited content that is only available on our site (like
> GeoData) but I feel that this content would really work better under the
> osgeo.org/(projects|committees)/projectname/ structure, so that they
> have the benefit of the CMS without giving us the overhead of
> maintaining multiple CMS instances.
> 
> We need to leverage the CMS and the functionality of Trac as much as
> possible, so that we don't have to manually maintain HTML files, but
> setting up an individual Drupal instance for each site is not
> supportable in the long run.  I also don't think it's wise from a
> security/stability standpoint to allow direct filesystem or shell level
> access to the site servers for project maintainers.  Changes should go
> through SAC (once SAC is up to speed on the servers).
> 
> Jason
> 
> -----Original Message-----
> From: Tyler Mitchell [mailto:tylermitchell at shaw.ca] 
> Sent: Friday, December 15, 2006 11:22
> To: sac at sac.osgeo.org
> Subject: Re: [SAC] Vhost standards, etc...
> 
> 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
>