On 2005.12.31, at 02:01 AM, Joseph Alotta wrote:
On Dec 29, 2005, at 8:06 PM, Joel Rees wrote:
Maybe it would help to tell you it ain't that simple?
To mention openssl again, it can be installed in a variety of places,
and it depends in part on where other things you may have installed
might have wanted to put the packages they depend on. That's another
reason for using a sandbox.
(Using the separate perl also helps me avoid building a sandbox for
my personal server, where I don't have resources for doing things the
ideal way.)
Hi Joel,
What's a sandbox?
A place where you can play with impunity. <grin />
If you start with the live chicken (to recklessly mix metaphors), you
replicate your server machine/cluster on the internal net, where only
the dev, test, evaluation, etc., crew can access it. This is the
sandbox. You fix bugs and add functionality on the sandbox, then when
you've tested the sandbox sufficiently, you take a backup of the
sandbox for both archival and to use as the base of the next version,
and mirror the sandbox back to the live server/cluster.
If you start with the egg, you set up the sandbox before you set up
anything live on the external network, and the initial server/cluster
is basically built by taking a backup of the sandbox and restoring the
backup to the hardware that will be the live system.
One of the things that having the sandbox helps with is that you can
take a diff of the sandbox and the current base system and use the diff
to figure out what doesn't need to be copied when mirroring back to the
live system. (The diff also helps with security analysis of the new
version.)
Using jails, virtual servers, separate installs of perl and other
components, careful partitioning and the like, you can often put the
sandbox on workstations, but only if you are willing to trust the
employees whose workstations you use.
