RE: [SAC] Virtual Hosts Policy

Committees SAC mailing list
1

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@lists.osgeo.org [mailto:sac-bounces@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac

_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac