[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Wed Apr 7 15:57:29 UTC 2010


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.
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
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

The step 3 here is the core of the work but it is definitely comparable
with the conversion work and validation logic in the XML case.
The first approach at the point looks a bit too heavy both from
application point of view and development point of view.
Another point is that in the second approach we can do the work
gradually and increase the complexity of the validation as we go.
And do not forget that the option 1 is just schema validation without
any conditions. I have some ideas about how we can use the conditions
in the second approach more easily.
Not to forget that first approach would require some time to get fluent
with XSLT, RelaxNG and libxml - this would take some time while
with the second approach the development can start immediately.

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

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

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?

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/







More information about the sssd-devel mailing list