[SAC] Virtual Hosts Policy
Jason Birch
Jason.Birch at nanaimo.ca
Mon Jan 22 16:26:39 EST 2007
I also prefer the project-level names:
mapguide.osgeo.org/svn
mapguide.osgeo.org/trac
Mainly because it means that projects are self-contained. Those who are
bringing their own infrastructure are not as different from the others.
I'm wondering if this affects the current server->service allocations
though. Does it mean that all services for a particular project need to
be on the same server?
I think that it also imposes an all-or-none infrastructure choice on our
projects, but that's not necessarily a bad thing.
What about Foundation-level stuff?
www.osgeo.org/trac
???
Jason
-----Original Message-----
From: sac-bounces at lists.osgeo.org [mailto:sac-bounces at lists.osgeo.org]
On Behalf Of Tyler Mitchell
Sent: Monday, January 22, 2007 13:11
To: System Administration Committee Discussion/OSGeo
Subject: Re: [SAC] Virtual Hosts Policy
This all makes sense to me. There is increasing need for web hosting
with vhosts, it seems, as more projects move over to this new
infrastructure. I prefer the project-based names but could argue either
way.
Tyler
On 22-Jan-07, at 12:53 PM, Howard Butler wrote:
> All,
>
> I propose that we make every attempt to use virtual hosts and
> explicit DNS for services that we provide. This document will
> outline the proposal and why I think this is important for us in
> the future.
>
> As Jason pointed out, some search engines penalize certain
> layouts. As evidenced by the "Subversion is 403 right now" thread,
> monkeypatching with rewrites can have unintended consequences and
> eventually get downright impossible to track through and maintain.
> For an organization as multifaceted as we are, I do not think that
> mere rewriting is a long term solution.
>
> Our experience on Collabnet showed us that a massive proliferation
> of DNS-bound services can be a large burden. Knowing where you are
> and what you were dealing with was tiring and tedious. On the
> other hand, explicit separation of either projects or services will
> provide us flexibility in the future. I propose that we choose one
> -- separate based on services or separate based on project -- for
> things like Trac, Subversion, Buildbot, and Web hosting. CN's
> approach was ok except for the fact that it proliferated so many
> "projects" that things got crazy. Right now, we have all of our
> eggs in this bucket, but in the future we may want to spread a few
> around.
>
> So, we have things look like
> http://gdal.osgeo.org/trac http://gdal.osgeo.org/svn
>
> or
> http://svn.osgeo.org/gdal http://trac.osgeo.org/gdal
>
> but not like
> http://svn.osgeo.org/svn/gdal http://trac.osgeo.org/trac/gdal
>
>
> Some virtues of this approach include:
> - Our ability to offload this service from the existing single
> machine to someplace else when and if we need to without much
> service disruption and minimal migration (URL relocation pain).
> - Guess-able and non-redundant URLs, once we establish a pattern
> and stick to it.
> - Fat-fingering a setting in one virtual host doesn't hose everyone
> else. If we're to distribute the administration load, it is
> important that changes be as localized as possible.
>
>
> Thoughts or comments? Project based or service based (makes no
> difference to me, as long as we choose one)? When we come to
> agreement on how to proceed, I'll write up a "policy doc" for the
> wiki that we can follow when adding new services/projects.
>
> Howard
>
> _______________________________________________
> Sac mailing list
> Sac at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/sac
_______________________________________________
Sac mailing list
Sac at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
More information about the Sac
mailing list