path: root/doc/unsorted/writing_specification.txt

.. -*- mode: rst -*-

.. _unsorted-writing_specification:

===========================
Writing Bcfg2 Specification
===========================

Bcfg2 specifications are logically divided in to three areas:

* Metadata
* Abstract
* Literal

The metadata portion of the configuration assigns a client to its profile
group and to its non-profile groups. The profile group is assigned
in Metadata/clients.xml and the non profile group assignments are in
Metadata/groups.xml.

The group memberships contained in the metadata are then used to constuct
an abstract configuration for the client. An abstract configuration for
a client identifies the configuration entities (packages, configuration
files, service, etc) that a client requires, but it does not identify
them explicitly. For instance an abstract configuration may identify
that a client needs the Bcfg2 package with

.. code-block:: xml

    <Package name=bcfg2/>

but this does not explicitly identify that an RPM package version
0.9.2 should be loaded from http://rpm.repo.server/bcfg2-0.9.2-0.1.rpm.
The abstract configuration is defined in the xml configuration files
for the Base and Bundles plugins.

A combination of a clients metadata (group memberships) and abstract
configuration is then used to generate the clients literal configuration.
For instance the above abstract configuration entry may generate a
literal configuration of


.. code-block:: xml

    <Package name='bcfg2' version='0.9.2-0.1' type='yum'/>

A clients literal configuration is generated by a number of plugins that
handle the different configuration entities.

.. image:: specification_overview.png

Dynamic Groups
==============

Dynamic groups are likewise complex, and are covered on their own
[wiki:DynamicGroups page]

Abstract Configuration (Structures)
===================================

A clients Abstract Configuration is the inventory of configuration
entities that should be installed on a client. Two plugins provide the
basis for the abstract configuration, the Bundler and Base.

The plugin Bundler builds descriptions of interrelated configuration
entities. These are typically used for the representation of services,
or other complex groups of entities.

The Base provides a laundry list of configuration entities that need to
be installed on hosts. These entities are independent from one another,
and can be installed individually without worrying about the impact on
other entities.

Usage of Groups in Base and Bundles
-----------------------------------

Groups are used by the Base and Bundles plugins for selecting
Configuration Entity Types for inclusion in a clients abstract
configuration.  They can be thought of as::

    if client is a member of group1 then
        assign to abstract config

Nested groups are conjunctive (logical and).::

    if client is a member of group1 and group2 then
        assign to abstract config

Group membership maybe negated.  See "Writing Bundles" for an example.

Configuration Entity Types
--------------------------

Entities in the abstract configuration (and correspondingly in the
literal configuration) can have one of several types. In the abstract
configuration, each of these entities only has a tag and the name
attribute set.

The types of Configuration Entities that maybe assigned to the abstract
configuration can be seen at :ref:`server-configurationentries`.

An example of each entity type is below.

.. code-block:: xml

    <Package name='bcfg2'/>
    <Path name='/etc/bcfg2.conf'/>
    <Service name='ntpd'/>
    <Action name='action_name'/>

Writing Bundles
---------------

Bundles consist of a set of configuration entities. These entities
are grouped together due to a configuration-time interdependency.
Basic services tend to be the simplest example of these. They normally
consist of

* some software package(s)
* some configuration files
* an indication that some service should be activated

If any of these pieces are installed or updated, all should be rechecked
and any associated services should be restarted.

All files in the Bundles/ subdirectory of the repository are processed.
Each bundle must be defined in its own file and the filename must be the
same as the bundle name with a .xml suffix.::

    # ls Bundler
    Glide3.xml
    LPRng.xml
    Tivoli-backup.xml
    Tivoli.xml
    a2ps.xml
    abiword.xml
    account.xml
    adsm-client.xml
    amihappy.xml
    apache-basic.xml
    apache.xml
    apache2-basic.xml
    apt-proxy.xml
    at.xml
    atftp-server.xml
    atftp.xml
    ....

Groups can be used inside of bundles to differentiate which entries
particular clients will receive. This is useful for the case where
entries are named differently across systems; for example, one linux
distro may have a package called openssh while another uses the name ssh.
Configuration entries nested inside of Group elements only apply to
clients who are a member of those groups; multiply nested groups must
all apply.

Also, groups may be negated; entries included in such groups will only
apply to clients who are not a member of said group.

When packages in a bundle are verified by the client toolset, the Paths
included in the same bundle are taken into consideration.  That is,
a package will not fail verification from a Bcfg2 perspective if the
package verification only failed because of configuration files that
are defined in the same bundle.

The following is an annotated copy of a bundle:

.. code-block:: xml

    <Bundle revision='$Revision: 2668 $' name='ssh' version='2.0'
            origin='https://svn.mcs.anl.gov/repos/bcfg/trunk/repository/Bundler/ssh.xml'>
      <Path name='/etc/ssh/ssh_host_dsa_key'/>
      <Path name='/etc/ssh/ssh_host_rsa_key'/>
      <Path name='/etc/ssh/ssh_host_dsa_key.pub'/>
      <Path name='/etc/ssh/ssh_host_rsa_key.pub'/>
      <Path name='/etc/ssh/ssh_host_key'/>
      <Path name='/etc/ssh/ssh_host_key.pub'/>
      <Path name='/etc/ssh/sshd_config'/>
      <Path name='/etc/ssh/ssh_config'/>
      <Path name='/etc/ssh/ssh_known_hosts'/>
      <Group name='rpm'>
        <Package name='openssh'/>
        <Package name='openssh-askpass'/>
        <Service name='sshd'/>
        <Group name='fedora' >
           <Group name='fc4' negate='true'>
             <Package name='openssh-clients'/>
           </Group>
           <Package name='openssh-server'/>
        </Group>
      </Group>
      <Group name='deb'>
        <Package name='ssh'/>
        <Service name='ssh'/>
      </Group>
    </Bundle>

In this bundle, most of the entries are common to all systems. Clients
in group "deb" get one extra package and service, while clients in group
"rpm" get two extra packages and an extra service. In addition, clients
in group "fedora" and group "rpm" get one extra package entries, unless
they are not in the fc4 group, in which case, they get an extra package.
Notice that this file doesn't describe which versions of these entries
that clients should get, only that they should get them. (Admittedly,
this example is slightly contrived, but demonstrates how group entries
can be used in bundles)

|| '' '''Group ''' '' || '' '''Entry ''' '' ||
|| all  || /etc/ssh/ssh_host_dsa_key  ||
|| all  || /etc/ssh/ssh_host_rsa_key  ||
|| all  || /etc/ssh/ssh_host_dsa_key.pub  ||
|| all  || /etc/ssh/ssh_host_rsa_key.pub  ||
|| all  || /etc/ssh/ssh_host_key  ||
|| all  || /etc/ssh/ssh_host_key.pub  ||
|| all  || /etc/ssh/sshd_config  ||
|| all  || /etc/ssh/ssh_config  ||
|| all  || /etc/ssh/ssh_known_hosts  ||
|| rpm  || Package openssh  ||
|| rpm  || Package openssh-askpass  ||
|| rpm  || Service sshd  ||
|| rpm and fedora  || Package openssh-server  ||
|| rpm and fedora and not fc4  || Package openssh-clients  ||
|| deb  || Package ssh  ||
|| deb  || Service ssh ||

Bundle Tag
^^^^^^^^^^

The Bundle Tag has the following possible attributes:

|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
|| name || The name of the bundle || String ||
|| version || Bundle schema version || String ||
|| origin || URL of master version (for common repo) || String ||
|| revision || Master version control revision || String ||

As mentioned above the Configuration Entity Tags may only have the name
attribute in Bundle definitions.

Abstract Group Tag
^^^^^^^^^^^^^^^^^^

In the Abstract Configuration plugins (Base and Bundle) the Group Tag
may have the following attributes:

|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
|| name || Name of group. || String ||
|| negate || Negate the group association (is not a member of) || (True|False*) ||

An abstract group may contain any of the Configuration Entity types and other groups.

Using Base
^^^^^^^^^^

The Base plugin provides a mechanism to add independent configuration
entities to a client's abstract configuration.  All files in the Base/
subdirectory of the repository are processed, and all entries that fall
within the scope of the client metadata are included in its abstract
configuration.::

    $ ls Base/
    centos-4-x86.xml
    fedora-core-4-x86.xml
    rhel-as-4-x86.xml
    rhel-es-4-x86.xml
    rhel-ws-4-x86_64.xml
    rhel-ws-4-x86.xml

.. code-block:: xml

    <Base>
        <Group name='Centos4.4-Standard'>
            <Package name='audit'/>
            <Package name='audit-libs'/>
            <Package name='basesystem'/>
            <Package name='bash'/>
            <Package name='bcfg2'/>
            <Package name='beecrypt'/>
            ....
            <Package name='yum'/>
            <Package name='zlib'/>
            <Group name='x86_64'>
                <Package name='systemimager-x86_64initrd_template'/>
            </Group>
        </Group>
    </Base>

The format of the Base files are similar to those used by the Bundler.
The majority of the elements are usually Packages, but Paths of any type
may all be defined. A partial example is below:

Base Tag
^^^^^^^^

The Base Tag has no attributes

As mentioned above the Configuration Entity Tags contained in a Base
definition may only have the name attribute in Base definitions.

Abstract Group Tag
^^^^^^^^^^^^^^^^^^

In the Abstract Configuration plugins (Base and Bundle) the Group Tag
may have the following attributes:

|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
|| name || Name of group. || String ||
|| negate || Negate the group association (is not a member of) || (True|False*) ||

An abstract group may contain any of the Configuration Entity types and
other groups.

Literal Configuration (Generators)
==================================

A Generator is a Bcfg2 piece of code that is run to generate the literal
configuration for a host using a combination of the hosts metadata and
abstract configuration.

A Generator can take care of a particular configuration element. Any time
this element is requested by the client, the server dynamically generates
it either by crunching data and creating new information or by reading
a file off of disk and passes it down to the client for installation.

Usage of Groups in Generators
-----------------------------

Similar to Abstract Configuration plugins, groups are used by generator
plugins for selecting Configuration Entities for inclusion in a clients
literal configuration.  They can be thought of as::

    if client is a member of group1 then
        assign to abstract config

Nested groups are conjunctive (logical and).::

    if client is a member of group1 and group2 then
        assign to abstract config

How the groups are configured is specific to the plugin, but here are
two common methods:

* xml configuration file (Pkgmgr, Rules)
* file name encoding (Cfg, TCheetah, SSHBase)

Details are included on each plugin's page.

Generators
----------

Each of the generators is covered on their own page.

|| '' '''Plugin''' '' || '' '''Description''' '' ||
|| [wiki:Plugins/Actions Actions] || Action entries are commands that are executed either before bundle installation, after bundle installation or both. ||