support needed to clone production machines
mike at adept.org
Mon Jan 26 17:08:14 PST 2004
> new DSL line in an isolated place. After all, America have decided to make
> Europe as a second world, at the beginning of the last century. I live at
> the margins of your empire. I live in a city where nobody cares of my
> for the true unix. I have learnt completely alone, with the only help of
> your books.
not sure what this means... since the project attempts translation of
docs/web to various languages, has mirrors (web/doc/cvs) in various
places around the globe, etc... what america has or has not done
matters very little. the project itself doesn't try to exclude anyone.
perhaps you are a minority in your city/etc -- welcome to life as a
bsd user. :) i have been a part of that minority since 94/95 -- and i
live in america!
> I'm running FreeBSD for production purposes on a workstation I have built,
> purchasing all of the components in the U.S. I'll need to clone exactly the
> same machine on a similar hardware in the next future. The support for the
> FreeBSD production systems abandones previous releases too fast. The ports
> and the packages become too fast unavailable.
how do you mean? you could pick some "deployment release" and track
that (say 4.8 security branch, as only one random example). then your
OS and related packages are at least not trying to "keep up" with the
general release schedule... which is fast-paced for good reason.
if you require further "stabalization" of installed packages/etc you
may/probably want to build your own packages for commonly installed
software, possibly even multiple "package sets" for your various host
"categories" (webserver, database server, etc). more time spent coming
up with a packaging scheme and managing the result means more stability,
or at least seeing only changes you are comfortable with.
> The scientific environment is in Europe often a chaos, many institutes often
> purchase junk hardware in a total anarchy.
that sounds like ".edu" everywhre i've seen it. money usually is NOT
that available... so people make due with what they can attain. the
commercial world is not so different these days.
> It is quite impossible to clone production operating systems at a distance
> of one year,
does this mean you want to follow a process similar to this:
a) install target OS/packages on host A
b) wait one year
c) install target OS/packages on host B (using same method)
d) host B == host A
i think you're going to need to head in this general direction:
- pick a target release (say 4.8, probably not the newest release)
- create a local CVS repository for that release (stable.yourdomain)
- create a "gold" server where changes are applied (gold.yourdomain)
- create local copies of any/all used software (your packages)
- make/test all changes (OS/package/etc) on gold server
- move changes to production servers after testing
you can monitor a list like cvs-all or other sources to see exactly
what's being done on freebsd.org's servers, and update your local
repository as needed. when you update your local CVS repository, you
update the gold server from there... if it is stable and you are OK
with observed changes, you can then update other machines expecting only
changes you have already seen on the gold server.
new installs progress as usual, but pull sources from the gold server
and only install packages installed there...
so it's really possible and up to you to "insolate" yourself from
undesirable changes... it just requires more time/work. as an example,
i know people that follow a similar scheme because they must develop
software that is based upon an old 2.2.x tree.
some helpful URLs that may help you think about this problem and form
if you refine the "from scratch" method to suit your needs and build
everything from a locally-controlled repository... then it follows you
could control what a "fresh install" looks like. this sounds like what
you are trying to do.
the only thing i would add is that filesystem snapshots along with a
"stable/trusted" gold server could probably be used to do something like
this as well. along those lines, 5.x would be your friend. i have
verified snapshots work quite well and as expected there... but not on
a large scale unfortuneately (few machines). you would still make all
changes on your "gold" server, but push those changes to other servers
using filesystem snapshots. then you should have byte-for-byte
consistency provided through a standardized, easy-to-use interface.
granted, i have not tried this myself. ;)
> Am I perhaps the only fanatic running FreeBSD where I live... I have tried
> to donate my discs to several institutes or students, they have always been
> scared of it. It's a common practice to run another well known unix variant.
this is human behavior. evolution taught us "don't trust things that
are different, they may eat you or your children. run away." only
examples of stability/performance/security/etc will convince most people
otherwise. (it is no different here. solaris has a strong following,
sometimes for good reason... sometimes for superstitious ones!) it is
good to know that examples of stability, security, etc. abound in the
freebsd world. likewise, daily examples of microsoft's INstability,
INsecurity, etc. also abound.
> I am prepared for my usual dose of 'flames'.
i think this is only the "language barrier"...
More information about the freebsd-advocacy