[SAC] Virtual Hosts Policy

Howard Butler hobu at iastate.edu
Mon Jan 22 15:53:42 EST 2007


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



More information about the Sac mailing list