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.