Re: [cobalt-users] seeing websites by site #

[Kris Dahl <krislists@xxxxxxxxxxxxx>]

> If implemented at the client level this method is rife with problems,
> because the requester then becomes responsible for files on remote
> client systems that require an intermediary and can inadvertently
> cause substantial difficulty at a later date.

I see this is a positive rather than a negative.  When we migrate sites, we
don't want anyone to see the site before it goes live.  This is often
because the site is in production, may have security holes, whatever.  I
agree that obscurity is no replacement for security, however, having a DNS
record like new.yourdomain.com may pique someone's curiosity.  By having it
be a client side change you are able to reduce this.
 
> This ability to access sites pre-NIC update is an essential part of
> the web hosting migration process and facilitates intermediate
> testing as well.

Well I think having a development, test and production site are even more
important.  This is part of the issue that we deal with when we are
developing sites.

> You could solve this with any number of temporary hacks, mod 'Hosts',
> dummy test domain, etc. The problem is that all the solutions require
> you to undo something when your done "testing/migrating" or run the
> risk of the hardcoded solution breaking later. A much better approach
> is to enable the proper style of global functionality within the Raq
> itself.
>
> This is done by taking a a spare IP and repointing its DocRoot to
> /home/sites/ and a few other mods to httpd.conf thereby creating a
> proper solution permanently and allowing persistent access to sites
> via FQDN/DNS when properly setup and via a designated IP or FQDN of
> the form:
>
> 
> xxx.xxx.xxx.xxx/www.somedomain.com
> 
> xxx.xxx.xxx.xxx/site#
> 
> www.mytestbed.com/www.somedomain.com
> [presuming that www.mytestbed.com = xxx.xxx.xxx.xxx]

As far as I am concerned none of the solutions posted immediately above this
text are adequate solutions.  We have very complicated sites that require
what I call 'full-scale' testing.  This typically can only be done by using
a test web server.  Modifying a path, will break functionality in many
places.  For many reasons (one that instantly comes to mind is having a
global images folder: /images) having the additional path will break
functionality.  Broken functionality is not acceptable for me in a
full-scale test. 

I realize that my expectations and needs are fairly excessive--I take this
stuff very seriously.  When we build web sites, we don't kid around... the
ability to run a test site is extremely important--for that reason I
actually build abstraction layers that allow me to move a site from machine
to machine.  But I still have to have an actual hostname in order for things
to work.  I imagine this is true for many clients.

However, should all this not be neccessary, implementing your above
mentioned solutions are very simple:
something like:

shell> for i in ($(ls --directory -1 /home/sites/site*);do ln -s
/home/sites/$i/web /home/sites/home/web/$i;done

should do the trick.  I haven't tested that so it may not.

Then just make sure that you have the FollowSymLinks enabled for the 'home'
site.

-k