From 377f83a1e9a60d4938f56ad4ac271ae7cb9f44c6 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Wed, 16 Jan 2008 16:21:17 +0000 Subject: remove stale documentation git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@4247 ce84e21b-d406-0410-9b95-82705330c041 --- doc/deployment.xml | 117 ----------------------------------------------------- 1 file changed, 117 deletions(-) delete mode 100644 doc/deployment.xml (limited to 'doc/deployment.xml') 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 @@ - - 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. - - -
- -
- 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 - -
- -
- Bcfg2 Server Administration - - - -
- -
- An example application of bcfg2 - - 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. - - - - 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