System Management with Cfengine automated infrastructure (1)

Introduction

Today, IT data centers must provide and maintain stability, security, and scalability services across multiple operating system versions that can run on multiple server hardware and operating systems. Efficiency is very important. The administrator wants to minimize the support of these services and make them fully automatic, just like automatically turning off the lights. In this two-part series, "using Cfengine to automate Infrastructure Management", we will explore an automatic framework for system management and IT management: Cfengine.

Part 1 of this series provides an overview of Cfengine V3 Community Edition and information about how to build and configure Cfengine policies/publishers and clients. Part 1 describes how to use Cfengine to complete many daily tasks involved in service support.

This document assumes that you have installed the basic UNIX®Or Linux®Operating System, and familiar with Cygwin and Linux Packaging Commands.

Configuration Management and Cfengine

Good configuration management can establish and maintain the consistency of the performance, functions, and physical attributes of IT platforms and products and their environments. It can also be used to determine appropriate security features and ensure that these features are correctly applied. This is a complex task and many configuration management tools are available.

Some tools, such as Arusha Project (ARK), can be used with Cfengine. Although other tools use similar system management concepts, they are written in different programming languages. For example, Puppet is written in Ruby and called in REST. For example, Synctool is written in Python, for example, SmartFrog is based on Java™Technical. Tools like opsi (Open PC Server Integration) are only applicable to Windows®Write. IBM®Systems Director and the recently acquired IBM BigFix can also provide configuration management.

Cfengine is a GNU open-source configuration management framework for Computer System Automation. This framework is lightweight and can be built on almost all platforms. It can run on all common platforms, including AIX, Linux, UNIX, Apple, and Windows.

IT Infrastructure Library is the most widely used IT service management method in the world. IT defines knowledge management as a key process of delivery services. Knowledge Management ensures that a person has the knowledge to deliver and support the services required by the business. The premise is that when the service is provided efficiently, the value brought by the service is clearly understood and the required available information is provided. Cfengine V3 focuses on the knowledge management of each stage of the Management lifecycle. By using a defined configuration, Cfengine ensures that you have the appropriate package, configuration file, and file permissions and that the process runs in your environment.

Cfengine has two versions: one is the Community edition that has existed for a long time, and the other is the Business Enterprise Edition. For the commercial version, there are also several forms: Nova, Constellation and Galaxy.

Lifecycle Management

Cfengine follows the Build-Deploy-Manage-Audit (BDMA) mode for system lifecycle management. BDMA consists of four stages of the system lifecycle: Construction, deployment, management, and audit. During the build phase, you need to plan policy changes, plan the desired state commitment (promise), and build the template of the recommended commitment so that all machines can make and fulfill these commitments, the system can run seamlessly.

In the deployment phase, policies must be published to all autonomous clients (autonomous clients), and each client must run a proxy, which can be implemented and maintained without assistance.

In the management phase, this independent agent is responsible for managing the system. You only need to handle very few events that cannot be automatically handled.

Finally, the changes are audited and maintained locally in the audit phase. The decision result is ensured and automatically maintained by the Cfengine design.

Cfengine should not be considered a rolout system, where people try to remove absolute changes and reverse the Cfengine when an error occurs. They need to publish a policy revision sequence and continue. These status changes are managed locally by each client and are continuously repaired to comply with the policy.

Dependency

Cfengine requires OpenSSL and BerkeleyDB V3.2 or later. You can also choose to build to support Perl Compatible Regular Expression library (PCRE), OpenLDAP, PostgreSQL, or MySQL. Some database features are only available in commercial versions. On Windows, Cfengine requires the Cygwin environment. In addition, version control software such as Subversion (SVN) can be used to control changes to configuration files.

Terms

• Commitment-defined actions or rules for system compliance.
• Package-commitment group.
• Policy-defines the actual knowledge packages that we can manage.
• Class-attribute/variable defined as "on" or "off.
• The policy contains the commitment package.
• Key-it can be public or private, used to authenticate the identity of the server that can be accessed, generated using cf-key on each client, and then copied to the key warehouse on the server. At IBM, server keys alone are sufficient to provide security.

Start preparation

Cfengine can run on any UNIX server. If Cygwin is available, it can also run on Windows. On a UNIX server, install OpenSSL, BerkeleyDB, and all the additional packages discussed above. Cfengine is usually installed from a distributed package (such as rpm or deb), or the source code can also be downloaded and compiled.

If you plan to build Cfengine from source code, additional tools such as gcc, flex, And bison will also need to be installed on UNIX/Linux servers. On a Windows Server, install Cygwin, and then install the gcc, flex, and bison tools to compile and install the code.

These basic Cfengine files are installed in the/var/Cfengine subdirectory of the cfengine working directory. This working directory is used by Cfengine and defined during build. This path can be considered as a secure local file system. After the configuration file is encoded, it can be placed in the configuration distribution points (such as/var/cfmasterfiles) on all Cfengine servers ). This path is usually placed in the version control directory.

Build Cfengine from source code

Download the source code from the Cfengine repository. Log on to the system as a non-root user and run the following command.

tar –zxf cfengine-x.x.x.tar.gzcd cfengine-x.x.x./configure --prefix=/var/cfengine--sbindir=/var/cfengine/bin --localstatedir=/var/cfengine--with-workdir=/var/cfengine --with-openssl=/usr make

Now go to the root user and run the following command (the binary file is placed in/var/cfengine/bin ).

make installmake installcheck

Install Cfengine on Policy/Distribution Server

Log on to the system as the root user and run the following command:

mkdir –p /var/cfengine/masterfilescp cfengine-x.x.x/inputs/update.cf to /var/cfengine/masterfilescp cfengine-x.x.x/inputs/promises.cf to /var/cfengine/masterfiles

Use an appropriate email address to update the "mailto" option in the file promises. cf. In the "body server control" section of promise. cf, add the server to accept the network to which it is connected:

allowconnects => { "192.", "10.", "127.0.0.1" , "::1" };allowallconnects => { "192.", "10.", "127.0.0.1" , "::1" };trustkeysfrom => { "192.", "10.", "127.0.0.1" , "::1" };

Update the policy server to the new server environment in all configuration files:

cp cfengine-x.x.x/inputs/failsafe.cf to /var/cfengine/masterfilescp cfengine-x.x.x/inputs/cfengine_stdlib.cf to /var/cfengine/masterfiles

Cfengine component

The following lists the components that need attention during Cfengine installation. (Note: If you have installed Cfengine from a binary package or customized it during compilation and installation, these basic directories may be different .)

Directory

• /Var/cfengine/bin-directory with Cfengine binary files
• /Var/cfengine/inputs-directory with Cfengine configuration file
• /Var/cfengine/outputs-directory with Cfengine running report
• /Var/cfengine/ppkeys-directory with authentication key
• /Var/cfmasterfiles-directory of the master file on the Policy Server
• /Var/cfengine/repository-contains the directory where important Cfengine files are backed up for recovery (name/location configurable)

Binary files

• /Var/cfengine/bin/cf-promises-command for checking promise syntax
• /Var/cfengine/bin/cf-agent-commands for maintaining the shared commitment and agent packages related to the system status
• /Var/cfengine/bin/cf-serverd-the server (daemon process) used to publish policies or data files to the client and respond to requests from cf-runagent)
• /Var/cfengine/bin/cf-exmcm responsible for running the scheduling daemon process of cf-agent
• /Var/cfengine/bin/cf-runagent-run the cf-agent command on a remote machine
• /Var/cfengine/bin/cf-monitord-the daemon process for collecting system status information
• /Var/cfengine/bin/cf-report-command for generating summary and other reports from the Cfengine Embedded Database
• /Var/cfengine/bin/cf-know-command for generating an ISO standard Topic Map from a large number of commitments (knowledge modeling agent)
• /Var/cfengine/bin/cf-key-a key generation tool that runs once on each host to create a public/private key pair for secure communication

Configuration File

• The main configuration file used by/var/cfengine/inputs/promises. cf-agent
• /Var/cfengine/inputs/library. cf-contains the community library of reusable code sets. For V3.1.x release, it is best to use this community library.

Start Cfengine Policy Server for the first time

Run the following command on the server:

/var/cfengine/bin/cf-keymkdir /var/cfmasterfiles/ppkeyscp /var/cfengine/ppkey/localhost.pub /var/cfmasterfiles/ppkeys/root-.pubcp /var/cfengine/ppkey/localhost.priv \/var/cfmasterfiles/ppkeys/root-.privcp /var/cfmasterfiles/inputs/update.cf /var/cfengine/inputs/cp /var/cfmasterfiles/inputs/failsafe.cf /var/cfengine/inputs//var/cfengine/bin/cf-agent –bootstrap

The Cfengine Policy server is now configured. To prepare Cfengine to act as a remote client, run the following command: start cf-server.

In most environments, you can run cf-serverd through configuration. In other cases, it is best to prepare an independent configuration file for the server configuration. If the process stops unexpectedly, this can provide a location for external processes to restart cf-serverd. We can also use a watchdog script to re-enable cf-serverd. To run it from the command line:

/var/cfengine/bin/cf-serverd/var/Cfengine/bin/cf-serverd –f/var/cfmasterfiles/prod/server/server.cf

Initial settings of the Client

Run the following command to start the Cfengine client for the first time:

/var/cfengine/bin/cf-key/var/cfengine/bin/cf-agent –K –bootstrap

Create a binary package for your environment

In this case, you may want to create an APT or RPM package to configure your client. One package contains the Cfengine binary file, and the other package contains the minimum Cfengine configuration file and the server public key to guide the Cfengine. In addition, there are also cf-key and the cf-agent commands listed above. After these two packages are built, it is very easy to install these packages to configure the Cfengine client.

Next we will show you how to create a binary package for the Red Hat environment. (To create a Debian package, see UbuntuForums.org .) Different releases have different requirements for creating Binary packages. Read the reference documents of your environment to learn how to prepare this information properly.