diff options
Diffstat (limited to 'doc/deployment.xml')
-rw-r--r-- | doc/deployment.xml | 117 |
1 files changed, 0 insertions, 117 deletions
diff --git a/doc/deployment.xml b/doc/deployment.xml deleted file mode 100644 index 4c4cc9bf6..000000000 --- a/doc/deployment.xml +++ /dev/null @@ -1,117 +0,0 @@ -<chapter> - <title>Deploying Bcfg2</title> - - <para> - 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. - </para> - - <section> - <title>Simple Deployments</title> - - <para> - 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. - </para> - - <para> - 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. - </para> - - <para> - 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. - </para> - - <para> - 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. - </para> - - </section> - - <section> - <title>A Near-Literal Deployment</title> - <para> - 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. - </para> - - <para> - 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. - </para> - </section> - - <section> - <title>An Abstract Deployment</title> - <para/> - </section> - - <section> - <title>Bcfg2 Server Administration</title> - - <para/> - - </section> - - <section> - <title>An example application of bcfg2</title> - <para> - In my computing environment there are quite a diverse set of machines - and requirements for their operation. What this meant was 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. - </para> - - <para> - 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. - </para> - </section> -</chapter> |