Configuration and change management with Bcfg2
Multi-Stage Process
An update process consists of multiple steps (see Figure 1): The client first retrieves its XML-formatted configuration from the server, performs an inventory, and compares the current and target states. After completing all the changes associated with the update, the client again checks the vectors and informs the server of the results. The server generates reports and statistics on the basis of the information. To check the reports, the system administrator can trigger a test update. To trigger an update on the client side, type the following:
bcfg2 -q -v -n
This command launches the update process in a non-invasive, no-op mode (-n option). The -q option, which stands for quick, omits some checks. The -v option provides more information. Listing 3 shows the results of this kind of query.
Listing 3
Non-Configured Server
So far, the specification is still empty. Bcfg2 will not display correct (line 5) or incorrect (line 6) entries because the server does not have a single configuration entry in its central repository (line 7). The number of unmanaged entries in line 8 is more interesting: The Bcfg2 client has found 242 configuration objects that the administrator has not explicitly configured. The server will want to register and manage these objects in the future. These entries are mainly Service- and Package-type items added on the client side by the Linux distribution. Line 2 tells more about them.
Bcfg2 has automatically identified the distribution as one that uses the Chkconfig service to configure init services and RPM as its package manager. A Debian system would use update-rc.d and the DEB package format.
Because the bcfg2 command has just requested an update without changes, the details in lines 10 through 14 match the values in the lines above. It is now up to the system administrator to view the unmanaged entries one by one and add any appropriate definitions. Stipulating the -e option tells the system to detail the entries. One of Bcfg2's main strengths is its ability to gradually complete an incomplete configuration.
The update process is the core element in any configuration management system, and it makes sense to examine this process in more detail. The process comprises three phases.
Probing
In the initial phase, the client connects with the server and performs a number of tests, known as probes. These probes take the form of short shell scripts that run on the client side. Depending on the results, the server might add groups or bundles to the client specification. A test will simply return a result of group:group name.
The server automatically assigns the client to additional groups. This means that it will automatically add, say, a matching modem bundle if it discovers lspci on the client. For more examples and an exhaustive HOWTO, see the Bcfg2 website [6].
Configuring
In the second phase, the client receives the configuration description from the server. This description contains many configuration entries of the six basic types. The client does a local inventory to create a comparable structure and then goes on to compare the local inventory with the description from the server. In case of deviations, the client will perform changes depending on the corresponding configuration element types: The Bcfg2 client will resolve differences between configuration files by using the version defined on the server.
If a service is not running, the client will start it. Dependencies between configuration elements are resolved automatically.
The client repeats this process until no further progress is made – that is, until the next call to the update process fails to make any changes.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.