Configuration Entries

This page describes the names and semantics of each of the configuration entries used by Bcfg2.

Non-POSIX entries

TagName Description Attributes
Action Command name, command, when, timing, status, build
Package Software Packages name, type, version, url
PostInstall PostInstall command name
Service System Services name, type, status, target


PostInstall entries are deprecated in favor of Action entries. In fact, a PostInstall entry is simply a specific type of Action. Basically, the following are equivalent:

<PostInstall name='foo'/>


<Action timing='post' when='modified' name='n' command='foo' status='ignore'/>

POSIX entries

New in version 1.0.0.

The unified POSIX Path entries prevent inconsistent configuration specifications of multiple entries for a given path. The following table describes the various types available for new Path entries.

The abstract specification of these entries (i.e. In Bundler) will only contain a name attribute. The type will be added by the plugin that handles the entry in the case of Cfg, TGenshi, or TCheetah. If the entry is handled by the Rules plugin (i.e. it is a device, directory, hardlink, symlink, etc), then you will specify both the type and any other necessary attributes in Rules.

Running bcfg2-lint will check your configuration specification for the presence of any mandatory attributes that are necessary for the Path type specified.


A tool for converting old POSIX entries is available in the Bcfg2 source directory at tools/

Type Replacement/New Description Attributes
device New Create block, character, and fifo devices name, owner, group, dev_type (block, char, fifo), major/minor (for block/char devices)
directory Replaces Directory entries Directories name, owner, group, perms, prune
file Replaces ConfigFile entries Configuration File

name, owner, group, perms, encoding, empty

Note: see below

hardlink New Create hardlinks name, to
symlink Replaces SymLink entries SymLinks name, to
ignore New Ignore files that cause package verification failures (currently applies to only APT and YUMng) name
nonexistent New Specify a path that should not exist name, recursive
permissions Replaces Permissions entries Permissions of POSIX entities name, owner, group, perms, recursive
vcs New Create version control checkout vcstype (git), sourceurl, revision

Keep in mind that permissions for files handled by Cfg/TGenshi/TCheetah are still handled via the traditional Info mechanisms.

Additional information

This section describes some additional behavior relating to POSIX entry attributes.

Recursive permissions

As per the request in ticket 871, Path type=’permissions’ entries allow you to set a recursive attribute which allows the owner/group to be set recursively for a directory.

Bound Entries

This feature is a mechanism to specify a full entry at once from a bundle. Traditionally, entries are defined in two stages. First, an abstract entry is defined in a bundle. This entry includes a type (the XML tag) and a name attribute. Then this entry is bound for a client, providing the appropriate instance of that entry for the client. Specifying a bound entry short-circuits this process; the only second stage processing on Bound entries is to remove the “Bound” prefix from the element tag. The use of a bound entry allows the single stage definition of a complete entry. Bound entries can be used for any type.


<Bundle name='ntp'>
   <BoundPackage name='ntp' type='deb' version='1:4.2.4p4+dfsg-3ubuntu2.1'/>

Fun and Profit using altsrc

Altsrc is a generic, bcfg2-server-side mechanism for performing configuration entry name remapping for the purpose of data binding.

Use Cases

  • Equivalent configuration entries on different architectures with different names
  • Mapping entries with the same name to different bind results in a configuration (two packages with the same name but different types)
  • A single configuration entry across multiple specifications (multi-plugin, or multi-repo)


  • Consider the case of /etc/hosts on linux and /etc/inet/hosts on solaris. These files contain the same data in the same format, and should typically be synchronized, however, exist in different locations. Classically, one would need to create one entry for each in Cfg or TCheetah and perform manual synchronization. Or, you could use symlinks and pray. Altsrc is driven from the bundle side. For example:

    <Bundle name='netinfo'>
       <Group name='solaris'>
         <Path name='/etc/inet/hosts' altsrc='/etc/hosts'/>
       <Group name='linux'>
         <Path name='/etc/hosts'/>

    In this case, when a solaris host gets the ‘netinfo’ bundle, it will get the first Path entry, which includes an altsrc parameter. This will cause the server to bind the entry as if it were a Path called /etc/hosts. This configuration entry is still called /etc/inet/hosts, and is installed as such.

  • On encap systems, frequently multiple packages of the same name, but of different types will exist. For example, there might be an openssl encap package, and an openssl rpm package. This can be dealt with using a bundle like:

    <Bundle name='openssl'>
       <Package name='openssl' altsrc='openssl-encap'/>
       <Package name='openssl' altsrc='openssl-rpm'/>

    This bundle will bind data for the packages “openssl-encap” and “openssl-rpm”, but will be delivered to the client with both packages named “openssl” with different types.

  • Finally, consider the case where there exist complicated, but completely independent specifications for the same configuration entry but different groups of clients. The following bundle will allow the use of two different TCheetah templates /etc/firewall-rules-external and /etc/firewall-rules-internal for different clients based on their group membership.

    <Bundle name='firewall'>
       <Group name='conduit'>
         <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/>
       <Group name='internal'>
         <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-internal'/>
  • Consider the case where a variety of files can be constructed by a single template (TCheetah or TGenshi). It would be possible to copy this template into the proper location for each file, but that requires proper synchronization upon modification and knowing up front what the files will all be called. Instead, the following bundle allows the use of a single template for all proper config file instances.

    <Bundle name='netconfig'>
      <Path name='/etc/sysconfig/network-scripts/ifcfg-eth0' altsrc='/etc/ifcfg-template'/>
      <Path name='/etc/sysconfig/network-scripts/ifcfg-eth1' altsrc='/etc/ifcfg-template'/>
      <Path name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/>

    altsrc can be used as a parameter for any entry type, and can be used in any structure, including Bundler and Base.

Table Of Contents

Previous topic


Next topic


This Page