1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
<chapter>
<title>Design Goals & Concepts</title>
<para>
Bcfg2 was designed with several goals in mind. This section will
describe those goals, and how they were manifested in the
design. This section will also define important concepts used in
Bcfg2.
</para>
<section>
<title>Goals</title>
<itemizedlist>
<listitem>
<para>
Model configurations using declarative
semantics. Declarative semantics maximize the utility of
configuration management tools; they provide the most
flexibility for the tool to determine the right course of
action in any given situation. This means that users can
focus on the task of describing the desired configuration,
while leaving the task of transitioning clients states to
the tool.
</para>
</listitem>
<listitem>
<para>
Configuration descriptions should be comprehensive. This
means that configurations served to the client should be
sufficent to reproduce all desired functionality. This
assumption allows the use of heuristics to detect extra
configuration, aiding in reliable, comprehensive
configuration definitions.
</para>
</listitem>
<listitem>
<para>
Provide a flexible approach to user interactions. Most
configuration management systems take a rigid approach to
user interactions; that is, either the client system is
always correct, or the central system is. This means that
users are forced into an overly proscribed model where the
system asserts where correct data is. Configuration data
modification is frequently undertaken on both the
configuration server and clients. Hence, the existance of a
single canonical data location can easily pose a problem
during normal tool use.
</para>
<para>
Bcfg2 takes a different approach. The default assumption is
that data on the server is correct, however, the client has
option to run in another mode where local changes are
catalogued for server-side integration. If the Bcfg2 client is
run in dry run mode, it can help to reconcile differences
between current client state and the configuration described
on the server.
</para>
<para>
The Bcfg2 client also searches for extra configuration; that
is, configuration that is not specified by the configuration
description. When extra configuration is found, either
configuration has been removed from the configuration
description on the server, or manual configuration has
occurred on the client. Options related to two-way
verification and removal are useful for configuration
reconciliation when interactive access is used.
</para>
</listitem>
<listitem>
<para>
Generators, and administrative applications.
</para>
</listitem>
<listitem>
<para>
Imcremental operations.
</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Important Concepts</title>
<variablelist>
<varlistentry>
<term>Bundles</term>
<listitem>
<para>
Bundles are groups of interdependent configuration
elements. Service configurations including software,
configuration files, and service activations are a good
example of bundles. When any of these components are
modified, all should be re-checked, and any associated
services should be restarted. We refer to this process as
coherent reconfiguration; this guarentees that all
configuration changes are active before reconfiguration
has completed.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Metadata</term>
<listitem>
<para/>
</listitem>
</varlistentry>
</variablelist>
</section>
</chapter>
|
