1
edit
Changes
no edit summary
<pre>bcfg2 -vqn </pre>
===Client Daemon===
Although BCFG2 ships with a systemd unit and a SYSV init script, this is not the method for daemonizing the client software. The crontabs and cron-utils packages must be installed on the client for automatic checking in to occur. Additionally, the file /etc/sysconfig/bcfg2 can be modified to set the frequency of the cron tasks. This file contains documentation in the comments and does not need to be explained here.
==The BCFG2 Configuration Management System==
H file specify a file meant for a specific host. H files are used by creating a file called <filename>.H_<FQDN>. H files should only be files who's content are totally unique to that file, such as certificates or keys. If there are minor changes required, such as usernames, hostnames or the like the better option is to use a templating system such as [[#TCheetah|TCheetah]]. H files always take priority over G files.
====Info Files====
If you wish bcfg2 to push out executable scripts, or have specific permissions applied to files, the directory that contains the file must have a :info file.
Common entries for :info files include:
* Owner: the file owner
** Syntax-> owner: apache
* Group: The group ownership for the file
** Syntax-> group: libvirt
* Perms: File permissions
** Syntax-> perms: 755
===Metadata===
Metadata is where the [[#Configuring Clients|clients.xml ]] and [[#Configuring Groups|groups.xml ]] files reside. These have already been discussed previously in this documentation and this entry is here only for completeness' sake.
===Packages===
The default package management system for bcfg2 is PkgMgr, but the Packages plugin has enhanced yum support, so it will be used in it's stead. To enable the Packages plugin, add the entry "Packages" to the plugins line in /etc/bcfg2.conf. The folder "/var/lib/bcfg2/Packages" must also be present.
The Packages Plugin as implemented on the Armory Build farm has three prerequisites:
* A sources.xml file
* An architecture [[#Probes|probe]]
* [[#Package Bundles|Package Bundles]]
=====sources.xml=====
The sources.xml file must be located under "/var/lib/bcfg2/Packages" and is used to define the repositories that a certain group should query for their packages. A sample of such a file is as follows:
<pre>
<Sources>
<Group name="fedora-15">
<Source type="yum" rawurl="http://mirror.chpc.utah.edu/pub/fedora-secondary/releases/15/Everything/armhfp/os/Packages">
<Arch>armhfp</Arch>
</Source>
<Source type="yum" rawurl="http://mirror.chpc.utah.edu/pub/fedora-secondary/releases/15/Everything/arm/os/Packages">
<Arch>arm</Arch>
</Source>
</Group>
</Sources>
</pre>
The Group tags indicate which group this repository declaration is for. In order to use the repositories defined within this group, a client must be a member of said group.
The source tag has the declarations of type and rawurl. Type can be defined as apt, yum, or any other number of package management systems, but as the Armory is comprised of only Fedora machines, yum is selected. The "rawurl" attribute points to the URI of the the RPM files in a given repository.
The Arch tag indicates a specific repository for an architecture. This tag is used in conjuction with "Magic Groups" in order to ensure client machines get packages specifically for their architecture.
====Magic Groups and Probes====
Bcfg2 uses the concept of Magic Groups, which "Magically" identify a client's operating system, architecture, and other attributes. These groups are usually not declared in groups.xml, and are usually used by having [[#Probes|probes]] identify and associate a client with these groups.
====packages.conf====
This file is normally not needed, but in the case of the Armory build farm, it's presence grant's an administrative advantage. As the Armory consists of machines of only one operating system, OS magic groups are not needed. The contents of this file are:
<pre>
[global]
magic_groups=0
</pre>
===Probes===
The Probes plugin allows information to be collected from a client before bcfg2 generates a configuration for it. This information can be used by [[#TCheetah|templating systems]] or by [[#Magic Groups and Probes| magic groups]] to customized configuration for a given client. To make use of the Probes plugin, add the entry "Probes" to the Plugins section of "/etc/bcfg2.conf".
Probes should be placed under /var/lib/bcfg2/Probes and are nothing more than simple shell scripts. An example probe which probes the architecture of an ARM machine is as follows:
<pre>
#!/bin/bash
barch=$(uname -a | sed 's/\./\n/g' | grep ^arm)
if echo $barch | grep h > /dev/null ; then echo "group: armhfp" ; else echo "group: arm"; fi
</pre>
===TCheetah===
TCheetah is a python based templating system that can be used in bcfg2. To enable TCheetah to be used in bcfg2, add the entry "Metadata,TCheetah" to the end of the plugins line in /etc/bcfg2.conf on the server. This will enable the TCheetah plugin and the Metadata plugin, which allows TCheetah to access elements of the client's Metadata.
The main purpose of TCheetah is to enable dynamic file content to be generated based off of client details, say if a particular configuration file needs a hostname. The /var/lib/bcfg2/TCheetah directory uses a similar structure to the [[#Cfg|Cfg]] plugin, and can use [[#G Files|G]] and [[#H Files|H]] files. However, the template files must be named template. TCheetah can also use [[#Info Files| info files]]. The contents of the files themselves are similar to configuration files, however there are a number of variables that can be used in the files themselves. These variables all start with "$self.metadata" and are discussed in greater detail in the official documentation. The more commonly used ones are: * Hostname: the client's hostname* profile: shows the primary group this client is associated with* groups: shows all groups the client is associated with
The contents of the files themselves are similar to configuration files, however there are templating system reads anything starting with a $ as a variable and anything starting with a # as a number of variables that can be used in the files themselvescomment. These A standard escape (\) will allow TCheetah to process any script variables all start with $selfor comments as plaintext.metadata and are as follows:
=Sources=