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
112
113
114
115
116
117
|
<chapter>
<title>Deploying Bcfg2</title>
<para>
Bcfg2 can be deployed in several different ways. The strategy
chosen varies based on the level of complexity accepted by the
administrators. The more literal a representation used, the less
powerful and reusable it is. We will describe three strategies for
Bcfg2 deployment, ranging from a cfengine-like deployment, to a
highly abstract configuration. While the abstract configuration is
much more powerful, the cfengine-like deployment is much easier to
understand and manipulate.
</para>
<section>
<title>Simple Deployments</title>
<para>
The Bcfg2 server will build configurations based on a set of
high-level specifications that use class-based abstractions to
provide reusability. This approach works pretty well; however,
it can be hard to deploy and may be too complicated to solve
simple problems.
</para>
<para>
This issue can be addressed through the use of the Bcfg2 client
with a static configuration specification. This method works as
follows: important configuration details are statically
specified in a file on each system. The Bcfg2 client runs
periodically, and ensures that all aspects of configuration
included in the static specification are correct. It then
performs any update operations needed on the client.
</para>
<para>
The format of static specifications is identical to that
provided by the Bcfg2 server, when it is used. It consists of a
series of "Bundle" and "Independent" clauses. Independent
clauses contain a series of configuration elements that can be
installed without any install time dependence on other
configuration elements. Bundles are series of dependent
clauses. This means that configuration elements may interfere
with one another, or that services may need to be restarted upon
configuration update.
</para>
<para>
Each of these containers consists of a series of configuration
elements. The same elements may appear in either type of
clauses. These are basic types that are the same across all OS
ports.
</para>
</section>
<section>
<title>A Near-Literal Deployment</title>
<para>
The next easiest method to deploy is one where the configuration
specification is as simple and literal as possible. This style
of configuration specification can be characterized as near
copies of parts of the system.
</para>
<para>
This style of deployment uses the stock generators: Cfg, Pkgmgr,
and Svcmgr. These manage configuration files, packages and
services, respectively. Copies of configuration files are placed
in the Cfg repository, in as generic a location as possible.
</para>
</section>
<section>
<title>An Abstract Deployment</title>
<para/>
</section>
<section>
<title>Bcfg2 Server Administration</title>
<para/>
</section>
<section>
<title>An example application of bcfg2</title>
<para>
In my computing environment there are quite a diverse set of machines
and requirements for their operation. What this meant was that I needed
to devise a build system for machines that would allow me to easily
customize the software and services on the machine while still being
able to easily manage them and keep them secure. What I came up with
that solved this problem was that the initial install needed to be the
smallest subset of software that all machines had in common and
install this with whatever automated install system fit the OS. The
goal being that the OS automated installer( ie: kickstart, or
systemimager ) would put the initial bits on disk and take care of
hardware stuff and then as part of the postinstall process I run bcfg2
to insure that the rest of the software and configuration occurs based
on the machines metadata. The overall goal was met. I could now build
any type of machine that I needed just by using the common buildsystem
and let bcfg2 determine what was different machine to machine.
</para>
<para>
My current build process is centered around systemimager and
bcfg2. I have done some small enhancements to systemimager so that
with one floppy or cdrom any administrator can build any number of
machine profiles automatically. This is all done with some of the new
features that allow the encoding of the profile and image in the
clientside command so that the back end metadata can be asserted from
the client, which overrides the defaults specified in the metadata.xml
file.
</para>
</section>
</chapter>
|
