support needed to clone production machines

[Mike Hoskins]

.VWV. wrote:
> 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
> interests
> 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 
possible solutions:

http://www.infrastructures.org/papers/bootstrap/bootstrap.html
http://www.openpkg.org
http://www.freebsd.org/doc/articles/fbsd-from-scratch/index.html

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"...

good luck.