From 66af36e006651832549e57c982c96ee455360222 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Mon, 6 Jun 2005 16:42:34 +0000 Subject: more updates (Logical change 1.232) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@968 ce84e21b-d406-0410-9b95-82705330c041 --- doc/deployment.xml | 500 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 315 insertions(+), 185 deletions(-) (limited to 'doc') diff --git a/doc/deployment.xml b/doc/deployment.xml index 19777f619..d687ea187 100644 --- a/doc/deployment.xml +++ b/doc/deployment.xml @@ -1,193 +1,323 @@ -Deploying Bcfg2 - + Deploying Bcfg2 + + + Bcfg2 can be deployed in several different ways. The strategy + chosen varies based on the level of complexity accepted by the + administrators. The more literal a representation used, the less + powerful and reusable it is. We will describe three strategies for + Bcfg2 deployment, ranging from a cfengine-like deployment, to a + highly abstract configuration. While the abstract configuration is + much more powerful, the cfengine-like deployment is much easier to + understand and manipulate. + + +
+ Simple Deployments + + + The Bcfg2 server will build configurations based on a set of + high-level specifications that use class-based abstractions to + provide reusability. This approach works pretty well; however, + it can be hard to deploy and may be too complicated to solve + simple problems. + + + + This issue can be addressed through the use of the Bcfg2 client + with a static configuration specification. This method works as + follows: important configuration details are statically + specified in a file on each system. The Bcfg2 client runs + periodically, and ensures that all aspects of configuration + included in the static specification are correct. It then + performs any update operations needed on the client. + + + + The format of static specifications is identical to that + provided by the Bcfg2 server, when it is used. It consists of a + series of "Bundle" and "Independent" clauses. Independent + clauses contain a series of configuration elements that can be + installed without any install time dependence on other + configuration elements. Bundles are series of dependent + clauses. This means that configuration elements may interfere + with one another, or that services may need to be restarted upon + configuration update. + + + + Each of these containers consists of a series of configuration + elements. The same elements may appear in either type of + clauses. These are basic types that are the same across all OS + ports. + + + + + Package + + + A software package. This entity includes a package name + and version number. It may optionally include installation + information (such as a package source URL) if one is + needed. + + + + + ConfigFile + + + A configuration file. This entity includes a file path, + owner, group, permissions, and file contents. + + + + + SymLink + + + A symbolic link. This entity includes a source and + destination. + + + + + Service + + + A service (de)activation. This controls services, a la + chkconfig or update-rc.d. Services are restarted + whenever co-located configuration entities are + modified. This ensures that any configuration changes + are flushed out to all active processes. + + + + + Directory + + + A filesystem directory. This entity includes an owner, + group and permissions. + + + + +
+ +
+ A Near-Literal Deployment + + The next easiest method to deploy is one where the configuration + specification is as simple and literal as possible. This style + of configuration specification can be characterized as near + copies of parts of the system. + + + + This style of deployment uses the stock generators: Cfg, Pkgmgr, + and Svcmgr. These manage configuration files, packages and + services, respectively. Copies of configuration files are placed + in the Cfg repository, in as generic a location as possible. + +
+ +
+ An Abstract Deployment + +
+ +
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 - + 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) - - - -Home machine - - - - need to have a GUI interface( Xwindows or what not ) - - - use static password file - - - use local disk for home directories - + + 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. - - - - -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 - - - + + 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. - - + 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