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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
.. -*- mode: rst -*-
.. NOTE: these are relative links (change when directory structure
.. changes)
.. _Base: plugins/structures/base
.. _Bundler: plugins/structures/bundler
.. _Cfg: plugins/generators/cfg.html
.. _TGenshi: plugins/generators/tgenshi
.. _TCheetah: plugins/generators/tcheetah.html
.. _Rules: plugins/generators/rules.html
.. _server-configurationentries:
=====================
Configuration Entries
=====================
This page describes the names and semantics of each of the configuration
entries used by Bcfg2.
Non-POSIX entries
=================
+-------------+---------------------+-----------------------------+
| TagName | Description | Attributes |
+=============+=====================+=============================+
| Action | Command | name, command, when, timing |
+-------------+---------------------+-----------------------------+
| Package | Software Packages | name, type, version, url |
+-------------+---------------------+-----------------------------+
| PostInstall | PostInstall command | name |
+-------------+---------------------+-----------------------------+
| Service | System Services | name, type, status, target |
+-------------+---------------------+-----------------------------+
.. note::
PostInstall entries are deprecated in favor of Action entries. In
fact, a PostInstall entry is simply a specific type of Action.
Basically, the following are equivalent:
.. code-block:: xml
<PostInstall name='foo'/>
and
.. code-block:: xml
<Action timing='post' when='modified' name='n' command='foo' status='ignore'/>
POSIX entries
=============
.. versionadded:: 1.0.0
The unified POSIX Path entries prevent inconsistent configuration
specifications of multiple entries for a given path. The following table
describes the various types available for new **Path** entries.
The abstract specification of these entries (i.e. In `Bundler`_)
will only contain a *name* attribute. The type will be added by the
plugin that handles the entry in the case of `Cfg`_, `TGenshi`_, or
`TCheetah`_. If the entry is handled by the `Rules`_ plugin (i.e. it is
a device, directory, hardlink, symlink, etc), then you will specify both
the *type* and any other necessary attributes in `Rules`_.
Running ``bcfg2-lint`` will check your configuration specification for
the presence of any mandatory attributes that are necessary for the
Path type specified.
.. note:: A tool for converting old POSIX entries is available in the
Bcfg2 source directory at tools/posixunified.py
+-------------+----------------------+-----------------+--------------------------+
| Type | Replacement/New | Description | Attributes |
+=============+======================+=================+==========================+
| device | New | Create block, | name, owner, group, |
| | | character, and | dev_type |
| | | fifo devices | (block, char, fifo), |
| | | | major/minor |
| | | | (for block/char devices) |
+-------------+----------------------+-----------------+--------------------------+
| directory | Replaces Directory | Directories | name, owner, group, |
| | entries | | perms, prune |
+-------------+----------------------+-----------------+--------------------------+
| file | Replaces ConfigFile | Configuration | name, owner, group, |
| | entries | File | perms, encoding, empty |
+-------------+----------------------+-----------------+--------------------------+
| hardlink | New | Create | name, to |
| | | hardlinks | |
+-------------+----------------------+-----------------+--------------------------+
| symlink | Replaces SymLink | SymLinks | name, to |
| | entries | | |
+-------------+----------------------+-----------------+--------------------------+
| ignore | New | Ignore files | name |
| | | that cause | |
| | | package | |
| | | verification | |
| | | failures | |
| | | (currently | |
| | | applies to only | |
| | | APT and YUMng) | |
+-------------+----------------------+-----------------+--------------------------+
| nonexistent | New | Specify a path | name, recursive |
| | | that should not | |
| | | exist | |
+-------------+----------------------+-----------------+--------------------------+
| permissions | Replaces Permissions | Permissions of | name, owner, group, |
| | entries | POSIX entities | perms, recursive |
| | | | |
+-------------+----------------------+-----------------+--------------------------+
| vcs | New | Create version | vcstype (git), |
| | | control | sourceurl, revision |
| | | checkout | |
+-------------+----------------------+-----------------+--------------------------+
Keep in mind that permissions for files handled by Cfg/TGenshi/TCheetah
are still handled via the traditional :ref:`server-info` mechanisms.
Additional information
----------------------
This section describes some additional behavior relating to POSIX entry
attributes.
Recursive permissions
^^^^^^^^^^^^^^^^^^^^^
As per the request in ticket 871, Path type='permissions' entries allow you to
set a recursive attribute which allows the owner/group to be set recursively
for a directory.
.. _boundentries:
Bound Entries
=============
This feature is a mechanism to specify a full entry at once from
a bundle. Traditionally, entries are defined in two stages. First,
an abstract entry is defined in a bundle. This entry includes a type
(the XML tag) and a name attribute. Then this entry is bound for
a client, providing the appropriate instance of that entry for the
client. Specifying a bound entry short-circuits this process; the only
second stage processing on Bound entries is to remove the "Bound" prefix
from the element tag. The use of a bound entry allows the single stage
definition of a complete entry. Bound entries can be used for any type.
Example:
.. code-block:: xml
<Bundle name='ntp'>
<BoundPackage name='ntp' type='deb' version='1:4.2.4p4+dfsg-3ubuntu2.1'/>
</Bundle>
Fun and Profit using altsrc
===========================
Altsrc is a generic, bcfg2-server-side mechanism for performing
configuration entry name remapping for the purpose of data binding.
Use Cases
---------
* Equivalent configuration entries on different architectures with
different names
* Mapping entries with the same name to different bind results in a
configuration (two packages with the same name but different types)
* A single configuration entry across multiple specifications
(multi-plugin, or multi-repo)
Examples
--------
* Consider the case of ``/etc/hosts`` on linux and ``/etc/inet/hosts`` on
solaris. These files contain the same data in the same format,
and should typically be synchronized, however, exist in different
locations. Classically, one would need to create one entry for each
in `Cfg`_ or `TCheetah`_ and perform manual synchronization. Or,
you could use symlinks and pray. Altsrc is driven from the bundle
side. For example:
.. code-block:: xml
<Bundle name='netinfo'>
<Group name='solaris'>
<Path name='/etc/inet/hosts' altsrc='/etc/hosts'/>
</Group>
<Group name='linux'>
<Path name='/etc/hosts'/>
</Group>
</Bundle>
In this case, when a solaris host gets the 'netinfo' bundle, it will
get the first Path entry, which includes an altsrc parameter. This
will cause the server to bind the entry as if it were a Path
called ``/etc/hosts``. This configuration entry is still called
``/etc/inet/hosts``, and is installed as such.
* On encap systems, frequently multiple packages of the same name, but
of different types will exist. For example, there might be an openssl
encap package, and an openssl rpm package. This can be dealt with
using a bundle like:
.. code-block:: xml
<Bundle name='openssl'>
<Package name='openssl' altsrc='openssl-encap'/>
<Package name='openssl' altsrc='openssl-rpm'/>
</Bundle>
This bundle will bind data for the packages "openssl-encap" and
"openssl-rpm", but will be delivered to the client with both packages
named "openssl" with different types.
* Finally, consider the case where there exist complicated, but
completely independent specifications for the same configuration entry
but different groups of clients. The following bundle will allow the use
of two different `TCheetah`_ templates ``/etc/firewall-rules-external``
and ``/etc/firewall-rules-internal`` for different clients based on
their group membership.
.. code-block:: xml
<Bundle name='firewall'>
...
<Group name='conduit'>
<Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/>
</Group>
<Group name='internal'>
<Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-internal'/>
</Group>
</Bundle>
* Consider the case where a variety of files can be constructed by a
single template (`TCheetah`_ or `TGenshi`_). It would be possible to
copy this template into the proper location for each file, but that
requires proper synchronization upon modification and knowing up front
what the files will all be called. Instead, the following bundle allows
the use of a single template for all proper config file instances.
.. code-block:: xml
<Bundle name='netconfig'>
<Path name='/etc/sysconfig/network-scripts/ifcfg-eth0' altsrc='/etc/ifcfg-template'/>
<Path name='/etc/sysconfig/network-scripts/ifcfg-eth1' altsrc='/etc/ifcfg-template'/>
<Path name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/>
</Bundle>
altsrc can be used as a parameter for any entry type, and can be used
in any structure, including `Bundler`_ and `Base`_.
|
