[SSSD] Conceptual question

Sumit Bose sbose at redhat.com
Fri Apr 20 08:10:56 UTC 2012


On Thu, Apr 19, 2012 at 08:05:16PM -0400, Stephen Gallagher wrote:
> On Thu, 2012-04-19 at 19:48 -0400, Dmitri Pal wrote:
> 
> > The question is about the ALLOW and DETECT options. As a result of the
> > merge operation using those options one can end up with more than one
> > section with the same name or more than one key with the same name
> > inside the same section. The result will be a merged config with
> > potential duplicates but in case of ALLOW there will be no errors while
> > in case of DETECT there will be some merge errors (not implemented yet)
> > that can be printed later to provide the information about what is wrong
> > with the config.
> > 
> > The ALLOW mode does not make much sense for SSSD but in general case it
> > might be useful. However current interface that deals with querying the
> > configuration and fetching configuration data does not have a way to
> > deal with the values that can have more then one value. Duplicate values
> > would not cause any trouble they are just not accessible via existing
> > interface. The interface that is available is open for changes anyways
> > so there is not problem to extend it to support access to the dup keys
> > (if needed), however it is extra work and it is not clear whether it is
> > actually needed or not.
> > 
> > I think we need to finish the DETECT mode. It has a lot of value.
> > It is ALLOW mode that I am on the fence about.
> > 
> 
> To the best of my knowledge, there are no INI parsers out there that
> allow for multi-valued keys. In the event that two keys have the same
> value, different parsers offer one of three solutions:
> 1) Throw a parse error
> 2) First one listed in the file wins
> 3) Last one listed in the file wins (most common).
> 
> So I really don't think there's much value to implementing either the
> ALLOW or DETECT options. We don't want ini_config to be writing files
> that other parsers may be unable to read (or in the common case will be
> functionally identical to OVERWRITE, since last one usually wins). It's
> best if our output always guarantees single-valued keys.

I would agree with Stephen, we should try to keep it simple and try to
be close to other common ini parsers and usage.

What do you think of adding a small utility which prints out the
resulting flat ini file together with some messages about the duplicated
keys and sections and how they were handled? (I haven't checked the
code, maybe this tool already exists). With this an admin can check if
the includes really does what he expects.

bye,
Sumit

> 
> > So the question is what to do in this situation.
> > 
> > I see several options:
> > 1) Decide that allowing duplicates is a bad idea and we will not going
> > to support it so wipe out ALLOW option
> 
> I'm in favor of scrapping the ALLOW and DETECT options.



> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel




More information about the sssd-devel mailing list