Configuration and change management with Bcfg2
Bundles can be broken down still further: Bcfg2 groups the configuration files and software packages belonging to a specific system service in a file below the Bundler directory. For example, the Bundler/motd.xml file defines the configuration bundle for the /etc/motd welcome message:
<Bundle name='motd' version='2.0'> <Package name='login' /> <ConfigFile name='/etc/motd' /> </Bundle>
Some nicely commented examples of bundles are available from the project's wiki . Bundles contain a number of configuration items, which Bcfg2 aptly refers to as entries.
The system defines six different entry types (see Table 1): The ConfigFile type manages a file and its content; the Directory, Permission, and SymLink types let administrators manage or monitor objects. The Package and Service types of entries have more in the way of artificial intelligence.
Bcfg2 abstracts the distribution-specific methods used to, for example, install a package on a client; that is, it will call aptitude on a Debian system and rpm or yum on an openSUSE system. The same principle applies to system services that are typically listed in /etc/init.d.
Installing the Server
The abstract structure that describes the client is managed entirely on the server side. Typing bcfg2-admin init initializes a new configuration.
First, you are prompted for the details of the repository path, an SSL certificate for secure communications with the clients, and an access password. The Bcfg2 admin script then goes on to create several files and directories and populate the /etc/bcfg2.conf configuration file with meaningful defaults. You might need to modify the entry in the [components] section to match the hostname, which your clients can resolve with DNS.
This name is also the perfect choice for the Common Name when you generate a certificate. bcfg2-admin might create the file with world-readable permissions, but you will want to change this because it contains the client access password.
Additionally, the tool sets up an empty configuration repository below /var/lib/bcfg2. Calling /etc/init.d/bcfg2-server start launches the server.
The only component you need to install on the client is the bcfg2 client package. Additionally, you need to store the configuration file in /etc/bcfg2.conf.
The next step is to add each Bcfg2 client to the Metadata/clients.xml file on the server (Listing 2). All specifications use the XML format. The administrator can later assign profiles to hosts by using this file.
01 01 <Clients> 02 02 <Client profile="desktop" 03 name="alpha.example.com" pingable="N"/> 04 03 <Client profile="desktop" 05 name="beta.example.com" pingable="Y"/> 06 04 <Client profile="webserver" 07 name="gamma.example.com" pingable="N"/> 08 05 <!-- .. --!> 09 06 </Clients>
Bcfg2 identifies clients by their DNS names, which makes it important to have a working DNS system. The example assigns the desktop profile to the hosts alpha and beta.example.com and webserver to gamma.example.com. Bcfg2 is now ready for action.
New release comes with better semantic search and improvements to Kontact.
Annual code quality report shows FOSS is more secure at all project size levels.
The Raspberry Pi Foundation has announced an even smaller version of the tiny computer that will fit into a DIMM slot.
A new class of problems lets a malicious app pre-configure an invisible privilege update.
New Hack language adds static typing and other conveniences.
New crypto policy system will offer easier configuration and more uniform security.
Ubuntu founder denounces insecurity in proprietary, close-source software blobs.
Vulnerability affects many Linux web servers
The Bavarian capital shuns Microsoft, Google, and other alternatives to implement an open source groupware solution.
Phone vendor partnerships bring Mark Shuttleworth's dream of Ubuntu on a phone a step closer to reality.