-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/07/2010 11:57 AM, Dmitri Pal wrote:
Hi,
I was looking at the ideas that Steve vocalized yesterday for the INI
validation.
To recap:
Consider using XML/XSLT/Relax NG/Schematron to do ini file validation.
I did some research on the matter and here is what I am thinking.
What we want to accomplish is the internal validation of the INI file
when it is loaded.
We do not want to fork a separate process that will validate the INI file.
Though the suggested approach generally makes sense but there is no open
source C implementation for the Schematron that I could find.
And even if it exists it will take time to make sure it is a part of the
distributions we care about.
I thought it was a part of libxml2, but upon further research I see I
was mistaken.
Libxml supports schema validation but I really do not see a big
benefit
in going this path.
To validate an ini file the library (embeded into the application) would
have to:
1) Read the schema file
2) Convert schema to the RelaxNG schema on the fly
I think you missed the point that I was describing having the schema
file be written directly in RelaxNG or XST, but that's irrelevant now.
3) Read the config file
4) Convert it to xml probably using XSLT
5) Use libxml to implement validation logic
This just sounds a bit too heavy.
I had in mind a more customized approach
1) Read schema file
2) Read config file
3) Validate
This is essentially how the SSSDConfig API does things now (albeit it's
a very limited validation: we only validate that it matches the expected
Python type (str, int, etc.)
...
> Here is the design that I have in mind for the INI schema definition
> file and logic related to it.
> The INI file schema definition ini file will consist of description of
> the experted configuration optioins in the INI file.
> It will consist of the sections that describe keys in the ini files and
> sections that describe rules.
> We will skip rules for now and will talk about just the sections that
> define keys.
> I think that if we implement just that we will bring a lot of value.
> Any section in the schema definition file will have a
unique name. This
> the name of the section not the name of the key.
> This is an important difference. Think about the name of the section as
> the name of the variable that holds an object that describes some key.
> Each key definition section would have the following possible attributes
> that describe the properties of the key and its value in the
> configuration file.
> Here is an example. Say we want to describe the key
"provider" in the
> section "backend" of the INI file. Here how it might look like in the
> INI schema definition:
> [backendprovier]
> type = field <- Optional if omitted type
> "field" is assumed. Possible values: field, rule. Rule value not
> supported in v1
> section = backend <- Optional, specifies what
> section the key belongs to. If omitted the "secref" key should be
> defined. See below.
> name = provider <- Required, must be a unique
> name within the section.
> required = yes <- Optional, if omitted "no"
> is assumed
> vtype = string <- Type of the value. Can be :
> int32, uint32, long32, ulong32, double, bool,
> list = no <- Optional, if omitted
> "no" is assumed, specifies if the value is the list or not
> sep = ,; <- Potential other
> symbols that can be used as list item separators - can be added later
> And so on...
> Other interesting keys that came to mind:
> min = 0 <- Min
value for a numeric key
> max = 1000 <- Max value for a nemeric key
We really need to have
regex =
as an option. For example:
[ldap_uri]
type = field
vtype = string
regex = ldaps?://[\w\.]*
list = true
sep = , #How would we do space-separation? Should we even bother?
> Alternatively we can support (later) something like:
> ranges = 0, 10, 20, 30 < will mean that
the value should
> be in range from 0 to 10 or between 20 and 30. Might come up with some
> better syntax...
> The following keys would be interesting too:
> depends = backendprovier, backendsomthingelse <- This means that
> the key becomes required if the key backendprovier or key
> backendsomthingelse is defined.
>
> Notice that "backendsomthingelse" is used as a reference to another
> section in the schema.
> So far all this can be handled by the INI parsing without
modification.
> We some improvements and additions we can add something like this:
> depends = backendprovier[foo, bar, baz] <- That would
mean that the key
> becomes required only in case the value of the backendprovier is foo,
> bar or baz.
> Another interesting key that we might want to define is:
seclist
> seclist = yes <- Would mean that the value of
> the key specifies sections in the ini file. Can be used in the
> conjunction with "secprefix"
> secprefix = sometext <- Would mean that the name of the
> sections should be constructed by prepending this value
> Potentially we can also add "secprefixref" that
will point to a key
> whose value should be added as prefix for the section names.
> Here is the example. The configuration like this:
> [backends]
> domain =
foo.com
> be = bar, baz
> [
foo.com/bar]
> one = 1
> Will be described with schema
definition like this:
> [backend_domains]
> section = backends
> name = domain
> required = yes
> vtype = string
> [backend_bs]
> section = backends
> name = domain
> required = yes
> seclist = yes <implies list=yes and vtype = string
> secprefixref = backend_domains
> [subsection_one]
> secref = backend_ds
> name = one
> vtype = int32
This example is completely unparseable to my brain. Could you please try
representing it with a real-world example, such as ldap_uri? Also, I
don't like seclist, secprefixref and secref. They are not descriptive
and it will be impossible for anyone to keep them straight.
> We can get more complex as we go and find use cases we
need to cover.
> As we go we will also create best practices about creating your INI files.
> For example one of the things that IMO should be prohibited in the INI
> files
> at least for now is multiple dependency on presence or value. I mean
> things like:
> value of the key X should be present if the key Y is present and the key
> Z has value "abc".
> I envision the "rules" type section for dependencies like this. I think
> that complexity
> can be added later if ever needed.
> With the schema definition like this we would be able to
validate the
> following things about configuration:
> 1) The value is present when it should
> 2) The value has expected type and range
> 3) The dependencies are correct
> I think that covers most of the issues we need to deal
with in the INI
> files.
> Steve can we check that this grammar covers what we currently have in
> the sssd.ini?
See above, but we need to add, at a minimum, support for
regular-expression handling. I'd also prefer it strongly if we could add
support for something like +=
In other words, I want to be able to say:
[id_provider]
type = field
vtype = multi
choices = local
in the core config file, but then be able to say:
[id_provider]
type = extend #implies vtype=multi
choices = ldap
in the sssd-ldap.conf and have the resulting combined INI be effectively:
[id_provider]
type = field
vtype = multi
choices = local,ldap
This way, for things like the providers, we can provide a selection list
of options. Since otherwise, our only option would be
[id_provider]
type = field
vtype = string
regex = .*
Naturally, that's error-prone.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAku8wqUACgkQeiVVYja6o6PCagCfSSHOvNkLPUaAlNJj91v7aBHq
qskAn1dayukWHXnXKhUKhCJyNene6qwx
=J/IE
-----END PGP SIGNATURE-----