The Rules plugin resolves the following Abstract Configuration Entities:
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.
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.
Running bcfg2-lint will check your configuration specification for the presence of any mandatory attributes that are necessary for the entry specified.
Concrete specification of a package to be installed. A package can be specified in one of two ways:
- A single Package tag that lists all of the attributes for the single instance of the package that should be installed.
- A Package tag with any number of Instance children, each of which lists the attributes of an instance of the package that should be installed. In this case, the Package tag should only have name and type.
Note that many of the attributes listed below are specific to one or a few package drivers.
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
string | Yes | None |
type |
|
apk | ips | macport | opencsw | pacman | deb | rpm | blast | encap | sysv | ebuild | yum | freebsdpkg | Yes | None |
arch |
|
string | No | None |
bname |
|
string | No | None |
file |
|
string | No | None |
multiarch |
|
string | No | None |
pkg_checks |
|
true | false | No | None |
pkg_verify |
|
true | false | No | true |
release |
|
string | No | None |
simplefile |
|
string | No | None |
srcs |
|
string | No | None |
verify |
|
true | false | No | false |
verify_flags |
|
string | No | None |
version |
|
string | No | None |
An Instance element describes a single instance of a package that may have several different versions, arches, etc., installed at once.
Name |
Description |
Values |
Required |
Default |
---|---|---|---|---|
arch |
|
No |
None |
|
epoch |
|
No |
None |
|
installed_action |
|
No |
install | |
pkg_verify |
|
true | false |
No |
None |
release |
|
No |
None |
|
simplefile |
|
No |
None |
|
verify_fail_action |
|
No |
None |
|
verify_flags |
|
No |
None |
|
version |
|
No |
None |
|
version_fail_action |
|
No |
upgrade |
Most Genshi templating directives can be used either as standalone elements or as attributes on existing elements. This element group defines the standalone tags.
Name | Description | Values | Required | Default |
---|---|---|---|---|
py:vars |
|
string | Yes | None |
Any arbitrary child elements allowed
Name | Description | Values | Required | Default |
---|---|---|---|---|
py:value |
|
string | Yes | None |
Any arbitrary child elements allowed
Name | Description | Values | Required | Default |
---|---|---|---|---|
py:test |
|
string | No | None |
The when directive is used inside py:chooseType or choose to handle a single specific condition.
Name |
Description |
Values |
Required |
Default |
---|---|---|---|---|
py:test |
|
Yes |
None |
Any arbitrary child elements allowed
Any
Any arbitrary child elements allowed
Any
Name | Description | Values | Required | Default |
---|---|---|---|---|
py:each |
|
string | Yes | None |
Any arbitrary child elements allowed
Name | Description | Values | Required | Default |
---|---|---|---|---|
py:test |
|
string | Yes | None |
Any arbitrary child elements allowed
Name | Description | Values | Required | Default |
---|---|---|---|---|
py:path |
|
string | Yes | None |
py:buffer |
|
true | false | No | true |
py:once |
|
true | false | No | false |
py:recursive |
|
true | false | No | true |
Any arbitrary child elements allowed
Action entries are external shell commands that are executed either before bundle installation, after bundle installation or both.
Name | Description | Values | Required | Default |
---|---|---|---|---|
command |
|
string | Yes | None |
name |
|
string | Yes | None |
build |
|
true | false | No | true |
shell |
|
true | false | No | None |
status |
|
ignore | check | No | None |
timing |
|
both | pre | post | No | None |
when |
|
modified | always | No | None |
See also Actions.
Concrete description of a service entry. Note that, due to the great proliferation of init systems, many of the attributes listed only apply to one or a few client tools.
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
string | Yes | None |
FMRI |
|
string | No | None |
bootstatus |
|
on | off | No | off |
install |
|
true | false | No | true |
parameters |
|
string | No | None |
restart |
|
true | false | interactive | No | true |
sequence |
|
string | No | None |
status |
|
on | off | ignore | No | off |
target |
|
string | No | restart |
type |
|
chkconfig | deb | rc-update | smf | upstart | systemd | launchd | freebsd | No | None |
New in version 1.3.0.
In the 1.3.0 release, the “mode” attribute has been replaced by a pair of attributes, restart and install, which control how a service is handled more granularly than the old “mode” attribute. The old “mode” attribute values are equivalent as follows:
Mode attribute | Equivalent |
---|---|
mode="default" | restart="true" install="true" |
mode="interactive_only" | restart="interactive" install="true" |
mode="supervised" | restart="true" install="true" |
mode="manual" | restart="false" install="false" |
The default is restart="true" install="true"
Previously, “supervised” could be used to start a service during the verification phase; this is no longer supported. Services that have been stopped on a client will be started during the install phase.
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.
Note that secontext below expects a full context, not just the type. For instance, “system_u:object_r:etc_t:s0”, not just etc_t. You can also specify “__default__”, which will restore the context of the file to the default set by policy. If a file has no default context rule, and you don’t wish to set one, you can specify secontext='' (i.e., an empty secontext), in which case the client will not try to manage the SELinux context of the file at all.
See SELinux for more information.
Attributes common to all Path tags:
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
string | Yes | None |
type |
|
augeas | device | directory | file | hardlink | ignore | nonexistent | permissions | symlink | vcs | No | None |
Run Augeas commands. See Augeas for more details.
Name | Description | Values | Required | Default |
---|---|---|---|---|
group |
|
string | Yes | None |
mode |
|
nonNegativeInteger | Yes | None |
owner |
|
string | Yes | None |
lens |
|
token | No | None |
secontext |
|
string | No | __default__ |
Manage devices.
Name | Description | Values | Required | Default |
---|---|---|---|---|
dev_type |
|
block | char | fifo | Yes | None |
group |
|
string | Yes | None |
mode |
|
nonNegativeInteger | Yes | None |
owner |
|
string | Yes | None |
major |
|
nonNegativeInteger | No | None |
minor |
|
nonNegativeInteger | No | None |
secontext |
|
string | No | __default__ |
Entry represents a directory. prune can be set to remove all contents from the directory that are not explicitly specified in Bcfg2.
Name | Description | Values | Required | Default |
---|---|---|---|---|
group |
|
string | Yes | None |
mode |
|
nonNegativeInteger | Yes | None |
owner |
|
string | Yes | None |
prune |
|
true | false | No | None |
secontext |
|
string | No | __default__ |
Distribute an file with content explicitly specified in-line (i.e., as opposed to using Cfg for this file). If the file has no content, empty must be set to true.
Name | Description | Values | Required | Default |
---|---|---|---|---|
group |
|
string | Yes | None |
mode |
|
nonNegativeInteger | Yes | None |
owner |
|
string | Yes | None |
empty |
|
true | false | No | None |
secontext |
|
string | No | __default__ |
Manage a hard link.
Name | Description | Values | Required | Default |
---|---|---|---|---|
group |
|
string | Yes | None |
mode |
|
nonNegativeInteger | Yes | None |
owner |
|
string | Yes | None |
to |
|
string | Yes | None |
secontext |
|
string | No | __default__ |
ignore lets you flag files that are distributed by system software packages, but have been modified locally, to be ignored by package verification routines. This is useful for, e.g., a package that installs an initial version of a file and then modifies it automatically.
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
string | Yes | None |
Remove the specified file or directory. If recursive is set, remove the directory recursively (i.e., rm -rf).
Name | Description | Values | Required | Default |
---|---|---|---|---|
recursive |
|
true | false | No | None |
Merely set permissions on the specified path, which is presumed to already exist.
Name | Description | Values | Required | Default |
---|---|---|---|---|
group |
|
string | Yes | None |
mode |
|
nonNegativeInteger | Yes | None |
owner |
|
string | Yes | None |
recursive |
|
true | false | No | None |
secontext |
|
string | No | __default__ |
Manage symlinks.
Name | Description | Values | Required | Default |
---|---|---|---|---|
to |
|
string | Yes | None |
Check out the specified VCS repository to the given path.
New in version 1.3.0.
ACLs on a Path entry are specified not by attributes on the tag but by child <ACL> tags. For instance:
<Path name="/etc/foo" type="directory" owner="root" group="root"
mode="0775">
<ACL type="default" scope="user" user="foouser" perms="rw"/>
<ACL type="default" scope="group" group="users" perms="rx"/>
<ACL type="default" scope="other" perms="r"/>
</Path>
Name | Description | Values | Required | Default |
---|---|---|---|---|
perms |
|
string | Yes | None |
type |
|
default | access | Yes | None |
group |
|
string | No | None |
scope |
|
user | group | other | No | None |
user |
|
string | No | None |
It is not currently possible to manually set an effective rights mask; the mask will be automatically calculated from the given ACLs when they are applied.
For directories either no default ACL entries or at least an entry for the owner, owning group and other must be defined.
Note that it is possible to set ACLs that demand different permissions on a file than those specified in the perms attribute on the Path tag. For instance:
<Path name="/etc/foo" mode="0644" group="root" owner="root">
<ACL type="access" scope="user" user="foouser" perms="rwx"/>
</Path>
In this case, we’ve specified permissions of 0644, but the effective rights mask will be “rwx,” so setting the ACL will change the permissions to 0674. When this happens, Bcfg2 will change the permissions and set the ACLs on every run and the entry will be eternally marked as bad.
New in version 1.3.0.
Note
In order to use these entries, the client also needs to be at least version 1.3.0 since they require a client tool which is unavailable in previous versions.
Below is a set of tables which describe the attributes available for various SELinux types. The entry types (except for module) correspond to semanage subcommands.
Note that the selinuxtype attribute takes only an SELinux type, not a full context; e.g., “etc_t”, not “system_u:object_r:etc_t:s0”.
As it can be very tedious to create a baseline of all existing SELinux entries, you can use selinux_baseline.py located in the tools/ directory to do that for you.
See SELinux for more information.
Concrete SELinux port entry
Concrete SELinux file context (“fcontext”) entry
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
string | Yes | None |
selinuxtype |
|
token | Yes | None |
filetype |
|
all | regular | directory | symlink | pipe | socket | block | char | No | all |
mlsrange |
|
token | No | None |
Concrete SELinux node entry
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
|
Yes | None |
selinuxtype |
|
token | Yes | None |
mlsrange |
|
token | No | None |
proto |
|
ipv4 | ipv6 | No | None |
Concrete SELinux user entry
Concrete SELinux interface entry
New in version 1.3.0.
Note
In order to use this, the client also needs to be at least version 1.3.0 since they require a client tool which is unavailable in previous versions.
The POSIXUser tag allows you to create users on client machines.
Name | Description | Values | Required | Default |
---|---|---|---|---|
name |
|
token | Yes | None |
gecos |
|
string | No | None |
group |
|
token | No | None |
home |
|
string | No | None |
shell |
|
string | No | /bin/bash |
uid |
|
integer | No | None |
For example:
<POSIXUser name="daemon" home="/sbin" shell="/sbin/nologin"
gecos="daemon" uid="2" group="daemon">
<MemberOf group="lp"/>
<MemberOf group="adm"/>
<MemberOf group="bin/>
</POSIXUser>
The group specified will automatically be created if it does not exist, even if there is no POSIXGroup tag for it. If you need to specify a particular GID for the group, you must specify that in a POSIXGroup tag.
If you with to change the default shell, you can do so with the Defaults plugin.
See POSIXUsers for more information on managing users and groups.
New in version 1.3.0.
Note
In order to use this, the client also needs to be at least version 1.3.0 since they require a client tool which is unavailable in previous versions.
The POSIXGroup tag allows you to create groups on client machines.
See POSIXUsers for more information on managing users and groups.
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" mode="0755"/>
<Path type='directory' group="utmp" name="/var/run/screen" owner="root" mode="0775"/>
<Path type='directory' group="root" name="/autonfs/stage" owner="root" mode="0755"/>
<Path type='directory' group="root" name="/exports" owner="root" mode="0755"/>
<Path type='directory' name="/etc/condor" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/logs" group="wwwtrans" owner="root" mode="0775"/>
<Path type='directory' name="/mnt" group="root" owner="root" mode="0755"/>
<Path type='directory' name="/my" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/my/bin" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/nfs" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/sandbox" mode="0777" owner="root" group="root"/>
<Path type='directory' name="/software" group="root" owner="root" mode="0755"/>
<Path type='permissions' mode="0555" group="audio" owner="root" name="/dev/dsp"/>
<Path type='permissions' mode="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/libgd.so.1.8" to="/usr/lib/libgd.so.1.8.4"/>
<Path type='symlink' name="/usr/lib/libtermcap.so.2" to="/usr/lib/libtermcap.so"/>
<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'/>
</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, add the following setting to bcfg2.conf:
[rules]
regex = yes
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 regexes to match the same rule.