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.

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.

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.

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.

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.