summaryrefslogtreecommitdiffstats
path: root/man/bcfg2-lint.8
blob: 6240829604eca11be2478c36d32fe9441ce37788 (plain)
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
.TH "bcfg2-lint" 8
.SH NAME
bcfg2-lint \- Check Bcfg2 specification for validity, common mistakes,
and style

.SH SYNOPSIS
.B bcfg2-lint
.I [OPTIONS]
.I [<plugin> [<plugin>...]]

.SH DESCRIPTION
.PP
.B bcfg2-lint
This script checks the Bcfg2 specification for schema validity, common
mistakes, and other criteria.  It can be quite helpful in finding
typos or malformed data.

.B bcfg2-lint
exits with a return value of 2 if errors were found, and 3
if warnings (but no errors) were found.  Any other non-0 exit value
denotes some failure in the script itself.

.B bcfg2-lint
is a rewrite of the older
.B bcfg2-repo-validate
tool.

.SH OPTIONS

.TP
.BR "-v" 
Be verbose.

.TP
.BR "-C" 
Specify path to bcfg2.conf (default /etc/bcfg2.conf)

.TP
.BR "--lint-config" 
Specify path to bcfg2-lint.conf (default /etc/bcfg2-lint.conf)

.TP
.BR "-Q" 
Specify path to Bcfg2 repository (default /var/lib/bcfg2)

.TP
.BR "--stdin" 
Rather than operating on all files in the Bcfg2 specification, only
validate a list of files supplied on stdin.  This mode is particularly
useful in pre-commit hooks.

This makes a few assumptions:

Metadata files will only be checked if a valid chain of XIncludes can
be followed all the way from clients.xml or groups.xml.  Since there
are multiple formats of metadata stored in Metadata/ (i.e., clients
and groups), there is no way to determine which sort of data a file
contains unless there is a valid chain of XIncludes.  It may be useful
to always specify all metadata files should be checked, even if not
all of them have changed.

Property files will only be validated if both the property file itself
and its matching schema are included on stdin.

.TP
.BR "--require-schema" 
Require property files to have matching schema files

.RE

.SH "PLUGINS"

See
.BR bcfg-lint.conf(5)
for more information on the configuration of the plugins listed below.

.TP
.BR Bundles
Check the specification for several issues with Bundler: bundles
referenced in metadata but not found in 
.I Bundler/
; bundles whose
.I name
attribute does not match the filename; and Genshi template bundles
that use the
.I <Group>
tag (which is not processed in templated bundles).

.TP
.BR Comments
Check the specification for VCS keywords and any comments that are
required.  By default, this only checks that the
.I $Id$
keyword is included and expanded in all files.  You may specify VCS
keywords to check and comments to be required in the config file.
(For instance, you might require that every file have a "Maintainer"
comment.)

In XML files, only comments are checked for the keywords and comments
required.

.TP
.BR Duplicates
Check for several types of duplicatesin the Metadata: duplicate
groups; duplicate clients; and multiple default groups.

.TP
.BR InfoXML
Check that certain attributes are specified in
.I info.xml
files.  By default, requires that
.I owner
,
.I group
, and
.I perms
are specified.  Can also require that an
.I info.xml
exists for all Cfg files, and that paranoid mode be enabled for all
files.

.TP
.BR Pkgmgr
Check for duplicate packages specified in Pkgmgr.

.TP
.BR RequiredAttrs
Check that all
.I <Path>
and
.I <BoundPath>
tags have the attributes that are required by their type.  (E.g., a
path of type
.I "symlink"
must have
.I name
and
.I to
specified to be valid.  This sort of validation is beyond the scope of
an XML schema.

.TP
.BR Validate
Validate the Bcfg2 specification against the XML schemas.

Property files are freeform XML, but if a
.I .xsd
file with a matching filename is provided, then schema validation will
be performed on property files individually as well.  For instance, if
you have a property file named
.I ntp.xml
then by placing a schema for that file in
.I ntp.xsd
schema validation will be performed on
.I ntp.xml
.


.SH "SEE ALSO"
.BR bcfg2(1),
.BR bcfg2-server(8),
.BR bcfg2-lint.conf(5)

.SH "BUGS"

bcfg2-lint may not handle some older plugins as well as it handles
newer ones.  For instance, there may be some places where it expects
all of your configuration files to be handled by Cfg rather than by a
mix of Cfg and TGenshi or TCheetah.