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.

Figure 1: The administrator uses Bcfg2 to create a specification defining the required client configuration. Bcfg2 attempts to perform the changes and documents the results.

Listing 3

Non-Configured Server

01 Loaded tool drivers:
02  Chkconfig    POSIX        PostInstall  RPM
03
04 Phase: initial
05 Correct entries:        0
06 Incorrect entries:      0
07 Total managed entries:  0
08 Unmanaged entries:      242
09
10 Phase: final
11 Correct entries:        0
12 Incorrect entries:      0
13 Total managed entries:  0
14 Unmanaged entries:      242

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

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Network Management Intro

    Professional admins with tightening IT budgets are always looking for new tools that will help them do more with less. This month we feature some popular open source applications for deploying, configuring, updating, and monitoring software and systems on the network.

  • SCPM

    SCPM lets you switch your network configuration when your portable moves to a different network. Read on to learn more about deploying the SCPM profile manager with Suse Linux.

  • Radius and 802.1X

    The Radius protocol is typically used to authenticate users in dial-up scenarios. But Radius is also useful in LAN environments: in combination with 802.1X, Radius forces users to authenticate at a low level before the switch opens up a port.

  • FAI

    FAI helps you automate the process of installing and configuring new Debian systems.

  • Likewise

    Likewise Open provides smooth integration with Active Directory environments. We show you how to install and configure the admin-friendly authentication system.

comments powered by Disqus

Direct Download

Read full article as PDF:

030-035_bcfg.pdf  (884.49 kB)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia