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
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
|
.. -*- mode: rst -*-
.. vim: ft=rst
.. _server-plugins-generators-rules:
=====
Rules
=====
The Rules plugin resolves the following Abstract Configuration Entities:
* Service
* Package
* Path
* Action
* All SELinux entries
* POSIXUser
* POSIXGroup
to literal configuration entries suitable for the client drivers to
consume.
For an entity specification to be included in the Literal configuration
the name attribute from an Abstract Entity Tag (from Base or Bundler)
must match the name attribute of an Entity tag in Rules, along with the
appropriate group associations of course.
Each file in the Rules directory has a priority. This allows the same
Entities to be served by multiple files. The priorities can be used to
break ties in the case that multiple files serve data for the same Entity.
Usage of Groups in Rules
========================
Groups are used by the Rules plugin, along with host metadata, for
selecting the Configuration Entity entries to include in the clients
literal configuration. They can be thought of as::
if client is a member of group1 then
assign to literal config
Nested groups are conjunctive (logical and).::
if client is a member of group1 and group2 then
assign to literal config
Group membership may be negated.
Tag Attributes in Rules
=======================
Running ``bcfg2-lint`` will check your configuration specification for
the presence of any mandatory attributes that are necessary for the
entry specified.
Rules Tag
---------
.. xml:element:: Rules
:linktotype:
:noautodep:
:inlinetypes: RContainerType
Package Tag
-----------
.. xml:type:: PackageType
Action Tag
----------
.. xml:type:: ActionType
See also :ref:`client-tools-actions`.
Service Tag
-----------
.. xml:type:: ServiceType
Service mode specification
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. versionadded:: 1.3.0
In the 1.3.0 release, the "mode" attribute has been replaced by a pair
of attributes, :xml:attribute:`ServiceType:restart` and
:xml:attribute:`ServiceType:install`, which control how a service is
handled more granularly than the old "mode" attribute. The old "mode"
attribute values are equivalent as follows:
+-----------------------------+------------------------------------------+
| Mode attribute | Equivalent |
+=============================+==========================================+
| ``mode="default"`` | ``restart="true" install="true"`` |
+-----------------------------+------------------------------------------+
| ``mode="interactive_only"`` | ``restart="interactive" install="true"`` |
+-----------------------------+------------------------------------------+
| ``mode="supervised"`` | ``restart="true" install="true"`` |
+-----------------------------+------------------------------------------+
| ``mode="manual"`` | ``restart="false" install="false"`` |
+-----------------------------+------------------------------------------+
The default is ``restart="true" install="true"``
Previously, "supervised" could be used to start a service during the
verification phase; this is no longer supported. Services that have
been stopped on a client will be started during the install phase.
Path Tag
--------
The Path tag has different values depending on the *type* attribute of
the path specified in your configuration. Below is a set of tables which
describe the attributes available for various Path types.
Note that ``secontext`` below expects a full context, not just the
type. For instance, "``system_u:object_r:etc_t:s0``", not just
``etc_t``. You can also specify "``__default__``", which will restore
the context of the file to the default set by policy. If a file has
no default context rule, and you don't wish to set one, you can
specify ``secontext=''`` (i.e., an empty ``secontext``), in which case
the client will not try to manage the SELinux context of the file at
all.
See :ref:`server-selinux` for more information.
Attributes common to all Path tags:
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: name,type
device
^^^^^^
Manage devices.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: dev_type,owner,group,mode,secontext,major,minor
:requiredattrs: dev_type,owner,group,mode
directory
^^^^^^^^^
Entry represents a directory. :xml:attribute:`PathType:prune` can be
set to remove all contents from the directory that are not explicitly
specified in Bcfg2.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: owner,group,mode,secontext,prune
:requiredattrs: owner,group,mode
file
^^^^
Distribute an file with content explicitly specified in-line (i.e., as
opposed to using :ref:`server-plugins-generators-cfg` for this file).
If the file has no content, :xml:attribute:`PathType:empty` *must* be
set to ``true``.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:onlyattrs: owner,group,mode,secontext,empty
:requiredattrs: owner,group,mode
hardlink
^^^^^^^^
Manage a hard link.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: owner,group,mode,secontext,to
:requiredattrs: owner,group,mode,to
.. _path-ignore:
ignore
^^^^^^
``ignore`` lets you flag files that are distributed by system software
packages, but have been modified locally, to be ignored by package
verification routines. This is useful for, e.g., a package that
installs an initial version of a file and then modifies it
automatically.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: name
:requiredattrs: name
nonexistent
^^^^^^^^^^^
Remove the specified file or directory. If
:xml:attribute:`PathType:recursive` is set, remove the directory
recursively (i.e., ``rm -rf``).
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: recursive
permissions
^^^^^^^^^^^
Merely set permissions on the specified path, which is presumed to
already exist.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: owner,group,mode,secontext,recursive
:requiredattrs: owner,group,mode
symlink
^^^^^^^
Manage symlinks.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: to
:requiredattrs: to
vcs
^^^
Check out the specified VCS repository to the given path.
.. xml:type:: PathType
:nochildren:
:noattributegroups:
:nodoc:
:notext:
:onlyattrs: vcstype,revision,sourceurl
:requiredattrs: vcstype,revision,sourceurl
.. _server-plugins-generators-rules-acls:
ACLs
^^^^
.. versionadded:: 1.3.0
ACLs on a Path entry are specified not by attributes on the tag but by
child ``<ACL>`` tags. For instance:
.. code-block:: xml
<Path name="/etc/foo" type="directory" owner="root" group="root"
mode="0775">
<ACL type="default" scope="user" user="foouser" perms="rw"/>
<ACL type="default" scope="group" group="users" perms="rx"/>
</Path>
.. xml:element:: ACL
It is not currently possible to manually set an effective rights mask;
the mask will be automatically calculated from the given ACLs when
they are applied.
Note that it is possible to set ACLs that demand different permissions
on a file than those specified in the ``perms`` attribute on the
``Path`` tag. For instance:
.. code-block:: xml
<Path name="/etc/foo" mode="0644" group="root" owner="root">
<ACL type="access" scope="user" user="foouser" perms="rwx"/>
</Path>
In this case, we've specified permissions of ``0644``, but the
effective rights mask will be "rwx," so setting the ACL will change
the permissions to ``0674``. When this happens, Bcfg2 will change the
permissions and set the ACLs on every run and the entry will be
eternally marked as bad.
SELinux Entries
---------------
.. versionadded:: 1.3.0
.. note::
In order to use these entries, the client also needs to be at least
version 1.3.0 since they require a client tool which is unavailable
in previous versions.
Below is a set of tables which describe the attributes available
for various SELinux types. The entry types (except for ``module``)
correspond to ``semanage`` subcommands.
Note that the ``selinuxtype`` attribute takes only an SELinux type,
not a full context; e.g., "``etc_t``", not
"``system_u:object_r:etc_t:s0``".
As it can be very tedious to create a baseline of all existing SELinux
entries, you can use ``selinux_baseline.py`` located in the ``tools/``
directory to do that for you.
See :ref:`server-selinux` for more information.
SEBoolean Tag
^^^^^^^^^^^^^
.. xml:type:: SEBooleanType
SEPort Tag
^^^^^^^^^^
.. xml:type:: SEPortType
SEFcontext Tag
^^^^^^^^^^^^^^
.. xml:type:: SEFcontextType
SENode Tag
^^^^^^^^^^
.. xml:type:: SENodeType
SELogin Tag
^^^^^^^^^^^
.. xml:type:: SELoginType
SEUser Tag
^^^^^^^^^^
.. xml:type:: SEUserType
SEInterface Tag
^^^^^^^^^^^^^^^
.. xml:type:: SEInterfaceType
SEPermissive Tag
^^^^^^^^^^^^^^^^
.. xml:type:: SEPermissiveType
SEModule Tag
^^^^^^^^^^^^
.. xml:type:: SEModuleType
See also :ref:`server-plugins-generators-semodules`.
.. _server-plugins-generators-rules-posixuser-tag:
POSIXUser Tag
-------------
.. versionadded:: 1.3.0
.. note::
In order to use this, the client also needs to be at least version
1.3.0 since they require a client tool which is unavailable in
previous versions.
.. xml:type:: POSIXUserType
For example:
.. code-block:: xml
<POSIXUser name="daemon" home="/sbin" shell="/sbin/nologin"
gecos="daemon" uid="2" group="daemon">
<MemberOf group="lp"/>
<MemberOf group="adm"/>
<MemberOf group="bin/>
</POSIXUser>
The group specified will automatically be created if it does not
exist, even if there is no :xml:type:`POSIXGroup tag <POSIXGroupType>`
for it. If you need to specify a particular GID for the group, you
must specify that in a ``POSIXGroup`` tag.
If you with to change the default shell, you can do so with :ref:`the
Defaults plugin <server-plugins-structures-defaults>`.
See :ref:`client-tools-posixusers` for more information on managing
users and groups.
.. _server-plugins-generators-rules-posixgroup-tag:
POSIXGroup Tag
--------------
.. versionadded:: 1.3.0
.. note::
In order to use this, the client also needs to be at least version
1.3.0 since they require a client tool which is unavailable in
previous versions.
.. xml:type:: POSIXGroupType
See :ref:`client-tools-posixusers` for more information on managing
users and groups.
Rules Directory
===============
The Rules/ directory keeps the XML files that define what rules are
available for a host. All the files in the directory are processed.
The names of the XML files have no special meaning to Bcfg2; they
are simply named so it's easy for the administrator to know what the
contents hold. All Rules could be kept in a single file if so desired.
Bcfg2 simply uses the Groups in the files and priorities to determine
how to assign Rules to a host's literal configuration.
.. code-block:: xml
<Rules priority="0">
<Path type='directory' group="root" name="/autonfs" owner="root" mode="0755"/>
<Path type='directory' group="utmp" name="/var/run/screen" owner="root" mode="0775"/>
<Path type='directory' group="root" name="/autonfs/stage" owner="root" mode="0755"/>
<Path type='directory' group="root" name="/exports" owner="root" mode="0755"/>
<Path type='directory' name="/etc/condor" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/logs" group="wwwtrans" owner="root" mode="0775"/>
<Path type='directory' name="/mnt" group="root" owner="root" mode="0755"/>
<Path type='directory' name="/my" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/my/bin" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/nfs" owner="root" group="root" mode="0755"/>
<Path type='directory' name="/sandbox" mode="0777" owner="root" group="root"/>
<Path type='directory' name="/software" group="root" owner="root" mode="0755"/>
<Path type='permissions' mode="0555" group="audio" owner="root" name="/dev/dsp"/>
<Path type='permissions' mode="0555" group="audio" owner="root" name="/dev/mixer"/>
<Path type='symlink' name="/bin/whatami" to="/mcs/adm/bin/whatami"/>
<Path type='symlink' name="/chibahomes" to="/nfs/chiba-homefarm"/>
<Path type='symlink' name="/home" to="/nfs/mcs-homefarm"/>
<Path type='symlink' name="/homes" to="/home"/>
<Path type='symlink' name="/mcs" to="/nfs/mcs"/>
<Path type='symlink' name="/my/bin/bash" to="/bin/bash"/>
<Path type='symlink' name="/my/bin/tcsh" to="/bin/tcsh"/>
<Path type='symlink' name="/my/bin/zsh" to="/bin/zsh"/>
<Path type='symlink' name="/software/common" to="/nfs/software-common"/>
<Path type='symlink' name="/software/linux" to="/nfs/software-linux"/>
<Path type='symlink' name="/software/linux-debian_sarge" to="/nfs/linux-debian_sarge"/>
<Path type='symlink' name="/usr/bin/passwd" to="/usr/bin/yppasswd"/>
<Path type='symlink' name="/usr/bin/yppasswd" to="/mcs/bin/passwd"/>
<Path type='symlink' name="/usr/lib/libgd.so.1.8" to="/usr/lib/libgd.so.1.8.4"/>
<Path type='symlink' name="/usr/lib/libtermcap.so.2" to="/usr/lib/libtermcap.so"/>
<Path type='symlink' name="/usr/local/bin/perl" to="/usr/bin/perl"/>
<Path type='symlink' name="/usr/local/bin/perl5" to="/usr/bin/perl"/>
<Path type='symlink' name="/usr/local/bin/tcsh" to="/bin/tcsh"/>
<Service name='ntpd' status='on' type='chkconfig'/>
<Service name='haldaemon' status='on' type='chkconfig'/>
<Service name='messagebus' status='on' type='chkconfig'/>
<Service name='netfs' status='on' type='chkconfig'/>
<Service name='network' status='on' type='chkconfig'/>
<Service name='rawdevices' status='on' type='chkconfig'/>
<Service name='sshd' status='on' type='chkconfig'/>
<Service name='syslog' status='on' type='chkconfig'/>
<Service name='vmware-tools' status='on' type='chkconfig'/>
</Rules>
Using Regular Expressions in Rules
==================================
If you wish, you can configure the Rules plugin to support regular
expressions. This entails a small performance and memory usage
penalty. To do so, add the following setting to ``bcfg2.conf``::
[rules]
regex = yes
With regular expressions enabled, you can use a regex in the ``name``
attribute to match multiple abstract configuration entries.
Regular expressions are anchored at both ends, so ``<Service
name="bcfg2".../>`` will *not* match a Service named ``bcfg2-server``;
you'd have to explicitly specify ``<Service name="bcfg2.*".../>``.
Note that only one Rule can apply to any abstract entry, so you cannot
specify multiple regexes to match the same rule.
|