Thank you for comments! See my response.

On 02/19/2016 12:18 PM, Jakub Hrozek wrote:
On Thu, Feb 18, 2016 at 07:00:53PM +0100, Michal Židek wrote:
Hi!

This is the WIP design stub for config file checks:
https://fedorahosted.org/sssd/wiki/DesignDocs/libini-config-file-checks

For the first version we just want to
have the typo detection mechanism. To be more
precise, we want to detect:
1. options with wrong names
2. options in wrong sections

For the more complicated checks in later
version I would like to add possibility
to define constraints for the config file.

The idea is also described in the design stub.

For the definitions of constraints, we can use INI format
as well and not the custom format that I use now.
However the custom format is quite simple and
looks better IMO and allows to parse different
attributes in different way which results in less
verbose and better formatted file. However as I said it
is not required to get the functionality.

Well, using the INI format would have the advantage of having the parser
ready already. It feels a bit backwards to me to configure the INI
parser with another file format.

Ok. I had the same feeling. In the earlier version I had
it was not possible to use INI format for the rules, but I
simplified it to the current form were it is. I will
continue with the INI format.


What about having the allowed options per section, like this?

Having per section allowed options would save some
typing for options that can be in the same sections.
In the custom format I do this using inheritance from
previous line, but this is not possible with the INI
format.

Also I wanted to have the 'section' value a regular expression
so that it can be written for subsections like this

domain/.*

Because actually we use subsections for domain definitions and
we can not predict how the domain will be called. Regexes seem
to be flexible and easy to use in this situation.

To have per section allowed_options we could use
subsections so that there are no conflicts, for example
[allowed_options/pam]

But it is not possible to use regular expression in the
subsection name for example this is not possible
[allowed_options/domain/.*]

However we could use something like this:

[allowed_options/domains]
section = domain/.*
option = value
option = value
...

instead of:

[allowed_options]
option = section; value
option = section; value
...

Would that be OK?


[allowed_options]
section = domain
apply_if_exists = id_provider; ad
apply_if_exists = ldap_id_mapping; false
apply_contraint = all
option = value
option = value
option = value

Also I would like to not mix allowed_options with the rules. That
would make allowed_options very difficult IMO. allowed_options
should only list all options that are allowed together with
section (no sections means any section) and value (no value
means any value). To get the typo detection and detection
of misplaced options.

If some options are allowed only with ad provider and ldap_id_mapping
false, that should be written using a rule like this:

[rules/only_ad_provider_id_mapping_false]
scope = domain/.*
apply_if_exists_any = here will be list of option-section-value triples that are allowed only with id_provider ad and id_mapping false
fail_if_miss_any = id_provider, ,ad; ldap_id_mapping, ,false
                              ^^^                   ^^^
The section here can be left blank because the scope was set. Any
section specified here would actually be subsection of the section
in scope.

Michal



The abilities of the rules can be further
extended by adding new attributes with special
meaning (see the design).

Lukas could you also describe the idea you told
me with the hooks in C? It sounded like a
good idea but I do not remember all the
details.

Michal
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

Reply via email to