The Rules plugin resolves the following Abstract Configuration Entities:

  • Service
  • Package
  • Path
  • Action

to literal configuration entries suitable for the client drivers to consume.

For an entity specification to be included in the Literal configuration the name attribute from an Abstract Entity Tag (from Base or Bundler) must match the name attribute of an Entity tag in Rules, along with the appropriate group associations of course.

Each file in the Rules directory has a priority. This allows the same Entities to be served by multiple files. The priorities can be used to break ties in the case that multiple files serve data for the same Entity.

Usage of Groups in Rules

Groups are used by the Rules plugin, along with host metadata, for selecting the Configuration Entity entries to include in the clients literal configuration. They can be thought of as:

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

Nested groups are conjunctive (logical and).:

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

Group membership may be negated.

Tag Attributes in Rules

Rules Tag

The Rules Tag may have the following attributes:

Name Description Values
priority Sets the priority for Rules in this Rules list.The higher value wins. String

Rules Group Tag

The Rules Group Tag may have the following attributes:

Name Description Values
name Group Name String
negate Negate group membership (is not a member of) (true|false)

Package Tag

The Package Tag may have the following attributes:

Name Description Values
name Package name or regular expression String or regex
version Package Version or version=’noverify’ to not do version checking in the Yum driver only (temporary work a round). String
file Package file name. Several other attributes (name, version) can be automatically defined based on regular expressions defined in the Pkgmgr plugin. String
simplefile Package file name. No name parsing is performed, so no extra fields get set String
verify verify=’false’ - do not do package verification String
multiarch Comma separated list of the architectures of this package that should be installed. String
srcs Filename creation rules for multiarch packages. String
type Package type. (rpm, yum, apt,sysv,blast) String

Action Tag

See Actions

Service Tag

Name Description Values
mode Per Service Mode (New in 1.0) (manual | default | supervised | interactive_only )
name Service name or regular expression String or regex
status Should the service be on or off (default: off). (on | off | ignore)
target Service command for restart (default: restart) String
type Driver to use on the client to manage this service.
(chkconfig | deb | rc-update | smf | upstart |
systemd | freebsd | launchd )
sequence Order for service startup (debian services only) integer
parameters Pass parameters to service (Upstart services only) String

Service mode descriptions

New in version 1.0.0.

  • manual
    • do not start/stop/restart this service
    • service installation is not performed
  • interactive_only
    • only attempt to start/stop/restart this service if the client is run interactively
    • service installation is performed
  • default
    • perform appropriate service operations
  • supervised
    • default and ensure service is running (or stopped) when verification is performed
    • deprecates supervised=’true’

Service status descriptions

  • on
    • start the service at boot time
  • off
    • don’t start the service at boot time
  • ignore
    • don’t check the status, leave it as-is (valid for deb and upstart services only)

Client Tag

The Client Tag is used in Rules for selecting the package entries to include in the clients literal configuration. Its function is similar to the Group tag in this context. It can be thought of as:

if client is name then
    assign to literal config

The Client Tag may have the following attributes:

Name Description Values
name Client Name String
negate Negate client selection (if not client name) (true|false)

Path Tag

The Path tag has different values depending on the type attribute of the path specified in your configuration. Below is a set of tables which describe the attributes available for various Path types.

Attributes common to all Path tags:

Name Description Values
name Full path or regular expression matching the path String or regex


Name Description Values
dev_type Type of device (block|char|fifo)
owner Device owner String
group Device group String
major Major number (block or char devices) integer
minor Minor number (block or char devices) integer


Name Description Values
perms Permissions of the directory String
owner Owner of the directory String
group Group Owner of the directory String
prune prune unspecified entries from the Directory true|false


Name Description Values
type Type of file nonexistent
recursive Recursively remove directory contents true


Name Description Values
perms Permissions of the file. String
owner Owner of the file. String
group Group of the file. String

Rules Directory

The Rules/ directory keeps the XML files that define what rules are available for a host. All the files in the directory are processed.

The names of the XML files have no special meaning to Bcfg2; they are simply named so it’s easy for the administrator to know what the contents hold. All Rules could be kept in a single file if so desired. Bcfg2 simply uses the Groups in the files and priorities to determine how to assign Rules to a host’s literal configuration.

<Rules priority="0">
    <Path type='directory' group="root" name="/autonfs" owner="root" perms="0755"/>
    <Path type='directory' group="utmp" name="/var/run/screen" owner="root" perms="0775"/>
    <Path type='directory' group="root" name="/autonfs/stage" owner="root" perms="0755"/>
    <Path type='directory' group="root" name="/exports" owner="root" perms="0755"/>
    <Path type='directory' name="/etc/condor" owner="root" group="root" perms="0755"/>
    <Path type='directory' name="/logs" group="wwwtrans" owner="root" perms="0775"/>
    <Path type='directory' name="/mnt" group="root" owner="root" perms="0755"/>
    <Path type='directory' name="/my" owner="root" group="root" perms="0755"/>
    <Path type='directory' name="/my/bin" owner="root" group="root" perms="0755"/>
    <Path type='directory' name="/nfs" owner="root" group="root" perms="0755"/>
    <Path type='directory' name="/sandbox" perms="0777" owner="root" group="root"/>
    <Path type='directory' name="/software" group="root" owner="root" perms="0755"/>
    <Path type='permissions' perms="0555" group="audio" owner="root" name="/dev/dsp"/>
    <Path type='permissions' perms="0555" group="audio" owner="root" name="/dev/mixer"/>
    <Path type='symlink' name="/bin/whatami" to="/mcs/adm/bin/whatami"/>
    <Path type='symlink' name="/chibahomes" to="/nfs/chiba-homefarm"/>
    <Path type='symlink' name="/home" to="/nfs/mcs-homefarm"/>
    <Path type='symlink' name="/homes" to="/home"/>
    <Path type='symlink' name="/mcs" to="/nfs/mcs"/>
    <Path type='symlink' name="/my/bin/bash" to="/bin/bash"/>
    <Path type='symlink' name="/my/bin/tcsh" to="/bin/tcsh"/>
    <Path type='symlink' name="/my/bin/zsh" to="/bin/zsh"/>
    <Path type='symlink' name="/software/common" to="/nfs/software-common"/>
    <Path type='symlink' name="/software/linux" to="/nfs/software-linux"/>
    <Path type='symlink' name="/software/linux-debian_sarge" to="/nfs/linux-debian_sarge"/>
    <Path type='symlink' name="/usr/bin/passwd" to="/usr/bin/yppasswd"/>
    <Path type='symlink' name="/usr/bin/yppasswd" to="/mcs/bin/passwd"/>
    <Path type='symlink' name="/usr/lib/" to="/usr/lib/"/>
    <Path type='symlink' name="/usr/lib/" to="/usr/lib/"/>
    <Path type='symlink' name="/usr/local/bin/perl" to="/usr/bin/perl"/>
    <Path type='symlink' name="/usr/local/bin/perl5" to="/usr/bin/perl"/>
    <Path type='symlink' name="/usr/local/bin/tcsh" to="/bin/tcsh"/>
    <Service name='ntpd' status='on' type='chkconfig'/>
    <Service name='haldaemon' status='on' type='chkconfig'/>
    <Service name='messagebus' status='on' type='chkconfig'/>
    <Service name='netfs' status='on' type='chkconfig'/>
    <Service name='network' status='on' type='chkconfig'/>
    <Service name='rawdevices' status='on' type='chkconfig'/>
    <Service name='sshd' status='on' type='chkconfig'/>
    <Service name='syslog' status='on' type='chkconfig'/>
    <Service name='vmware-tools' status='on' type='chkconfig'/>

Using Regular Expressions in Rules

If you wish, you can configure the Rules plugin to support regular expressions. This entails a small performance and memory usage penalty. To do so, create a file, “Rules/rules.conf”, and add the following text:

regex = yes

You will have to restart the Bcfg2 server after making that change.

With regular expressions enabled, you can use a regex in the name attribute to match multiple abstract configuration entries.

Regular expressions are anchored at both ends, so <Service name="bcfg2".../> will not match a Service named bcfg2-server; you’d have to explicitly specify <Service name="bcfg2.*".../>.

Note that only one Rule can apply to any abstract entry, so you cannot specify multiple regexs to match the same rule.