On 02/24/2016 04:30 PM, Jakub Hrozek wrote:
On Wed, Feb 24, 2016 at 04:20:10PM +0100, Michal Židek wrote:
On 02/23/2016 09:17 PM, Jakub Hrozek wrote:
On Tue, Feb 23, 2016 at 05:06:57PM +0100, Michal Židek wrote:
On 02/22/2016 09:21 AM, Jakub Hrozek wrote:
On Fri, Feb 19, 2016 at 04:35:38PM +0100, Michal Židek wrote:
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.
Right, but should we care in the parser? I man, the domain name is just
a label (with the exception of local, but we can remove that..)
My point was different. The name of the section (the regular
expression, that will match sections in configuration file)
cannot be specified in the file with constraints as a section
name. So we still need to have the
[alowed_options/domains]
section = domain/.* // this is still needed
option = value
option = value
or this
[allowed_options/domains]
option = section; value
option = section; value
^^^^^^^ or this is needed
I don't mind this format too much, are you concerned it's too much
typing?
Yes. Because the section value will be the same for all options in the
same section and technically it is a regular expression. We may have
a section like this:
[allowed_options/service_common]
section = regex_that_describes_all_services
option = value
option = value
option = value
or
[allowed_options/service_common]
option = regex_that_describes_all_services, value
option = regex_that_describes_all_services, value
option = regex_that_describes_all_services, value
Now if you want to add a new service, you need to modify the
regex. It is better to have it on one place. Also
with one such regex per section, it is IMO visually
more readable.
OK, fair point. So I guess you chose the variant will less duplication? Can
you update the design page with the format you selected after all?
Yes, the less verbose one.
Will update the page.
Michal
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
