Deploying Bcfg2

<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>