Date: Mon, 26 Jan 2004 17:03:41 -0800 From: Mike Hoskins <mike@adept.org> To: advocacy@freebsd.org Subject: Re: support needed to clone production machines Message-ID: <4015B8ED.4060006@adept.org> In-Reply-To: <000901c3a020$bdf1e490$2ffc2dd5@workstation> References: <000901c3a020$bdf1e490$2ffc2dd5@workstation>
next in thread | previous in thread | raw e-mail | index | archive | help
.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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4015B8ED.4060006>