Lots of cleanup for bcfg2-repo-validate rewrite:

* Changed all references to bcfg2-repo-validate in the documentation
  to bcfg2-lint
* Wrote man pages for bcfg2-lint and bcfg2-lint.conf
* Cleaned up straggling references to bcfg2-repo-validate in
  Makefiles, spec files, and the POSIX tool
* A few minor bug fixes

1 files changed, 169 insertions, 0 deletions

diff --git a/man/bcfg2-lint.8 b/man/bcfg2-lint.8
new file mode 100644
index 000000000..624082960
--- /dev/null
+++ b/man/bcfg2-lint.8
@@ -0,0 +1,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.