From 2696b7c055f0c1db49199de7775d5b0540b23a9b Mon Sep 17 00:00:00 2001 From: Rick Bradshow Date: Wed, 9 Mar 2005 21:12:44 +0000 Subject: initial file (Logical change 1.210) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@890 ce84e21b-d406-0410-9b95-82705330c041 --- doc/deployment.xml | 193 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 193 insertions(+) (limited to 'doc/deployment.xml') diff --git a/doc/deployment.xml b/doc/deployment.xml index e69de29bb..19777f619 100644 --- a/doc/deployment.xml +++ b/doc/deployment.xml @@ -0,0 +1,193 @@ + +Deploying Bcfg2 + + Object Oriented Configs + +One of the most powerful and useful parts about bcfg2 metadata system +is the ability to have truely Object Oriented configs. I have found +that this has made me understand the machines I am managing in a whole +new light. Instead of focusing on what is installed, I now focus on +how machines relate to each other, or what pieces of the metadata are +similar in their configs. To illistrate this think about the following +example machines: + + +A users desktop machine +A multiuser compute machine +A users home machine. (telecommuter) + + +These 3 machines have 3 distinct focuses for usage, but in reality +they can have a very similar metadata, depending on how the config is +broken up or the view that is taken of the config. If you focus first +on where the machines are the same it will help to build the common +metadata. below is what all 3 machines have in common: + + +users need to have the software they need to perform +there work. + + +let just encode this into metadata by creating a Class called +common-software that contains all the common software between all 3 +machines. + + + + + .... + +]]> + + +now we need to find where they differ: + + + +Desktop machines + + + + need to have a GUI interface( Xwindows or what not ) + + + use NIS for authentification + + + use Autofs to mount home directories + + + + + +Multiuser compute machines + + + + only accessible by SSH, No GUI interface + + + use NIS for authentification + + + use Autofs to mount home directories + + + + + +Home machine + + + + need to have a GUI interface( Xwindows or what not ) + + + use static password file + + + use local disk for home directories + + + + + + +As you can see that there are common things pairwise in these configs +that can be further exploited by the object oriented system of bcfg2 + + + + + ... + + + + ... + +]]> + + +now all that is left is to ensure that all needs are met and we find +we need to make one more class: + + + + + ... + +]]> + + +Now we can mix and match these classes together to build the 3 +profiles or even build new profiles with these descrete entities. + + + + + + + + + + + + + + + + + + + +]]> + + +The free form object oriented fashion in which metadata can be +constructed is truely a double edge sword. On one hand you can build +up a nice list of descrete entities that can compose even the most +complicated configs, but it also allows for the creation of entities +that could provide monolithic solutions to each machines config. It is +all in how one views the machines and how much they are willing to +harness the power of the OO based metadata system. + + + + Tips & Tricks + + + + An example application of bcfg2 + + In my computing environment there are quite a diverse set of machines +and requirements for there operation. What this meant is that I needed +to devise a build system for machines that would allow me to easily +customize the software and services on the machine while still being +able to easily manage them and keep them secure. What I came up with +that solved this problem was that the initial install needed to be the +smallest subset of software that all machines had in common and +install this with whatever automated install system fit the OS. The +goal being that the OS automated installer( ie: kickstart, or +systemimager ) would put the initial bits on disk and take care of +hardware stuff and then as part of the postinstall process I run bcfg2 +to insure that the rest of the software and configuration occurs based +on the machines metadata. The overall goal was met. I could now build +any type of machine that I needed just by using the common buildsystem +and let bcfg2 determine what was different machine to machine. + + +My current build process is centered around systemimager and +bcfg2. I have done some small enhancements to systemimager so that +with one floppy or cdrom any administrator can build any number of +machine profiles automatically. This is all done with some of the new +features that allow the encoding of the profile and image in the +clientside command so that the back end metadata can be asserted from +the client, which overrides the defaults specified in the metadata.xml +file. + + + -- cgit v1.2.3-1-g7c22