[SSSD] [INI] Ding-libs, controversial points in the design to allow merging configuration snippets

Jakub Hrozek jhrozek at redhat.com
Mon Apr 14 10:18:20 UTC 2014


On Tue, Apr 08, 2014 at 10:32:25AM -0400, Simo Sorce wrote:
> On Tue, 2014-04-08 at 09:54 -0400, Dmitri Pal wrote:
> > On 04/07/2014 10:13 PM, Simo Sorce wrote:
> > > On Mon, 2014-04-07 at 19:20 -0400, Dmitri Pal wrote:
> > >> Hello,
> > >>
> > >> This is the continuation of the discussion of the following design page:
> > >> https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
> > >>
> > >> I see three controversial items in this design based on the previous
> > >> discussion:
> > >>
> > >> a) Merging values
> > >> This horse has been beaten in the other thread.
> > >> The answer is simple. If we can make SSSD to make a change to not use
> > >> lists or domains or providers as Simo suggest we can remove this
> > >> consideration from the merge design. If we can't then we need to make it
> > >> optionally available in the merge logic. To make a final decision here
> > >> we need Jakub's input on how hard it is to implement Simo's idea.
> > >>
> > >> c) Snippets in a directory vs. snippets in a subdirectory per application.
> > >> The design is built around the fact that it is better to put snippets
> > >> into different subdirectories per source/application that updated them
> > >> so that we can make sure that different sources of config info do not
> > >> step on each other. We also can jail the config files with SELinux and
> > >> allow different access to different subdirectories.
> > > Keep in mind that selinux labels can be applied to single files, they do
> > > not need to be in subdirectories.
> > >
> > >>   This is a deviation
> > >> from the current approaches where all snippets are supposed to go into a
> > >> single directory.
> > >> IMO this is quite limiting and I see an opportunity to change it for
> > >> better. However if people agree with Simo that this is too over
> > >> engineered and complicated I can understand. It is in fact more complex.
> > >> So chime in. If you think single directory is good enough so be it.
> > >>
> > >> d) .merge files
> > >> I do not like them either.
> > >> If we:
> > >> a) Can avoid value merges
> > >> b) Will require each snippet to have a section header ( the problem is
> > >> really the fact that INI automatically generates one called "default" if
> > >> there is none so it is hard to say whether the parse filled the blank or
> > >> the snippet section really is called "[default]"). I think I can work
> > >> around it but it would require a change that I wanted to avoid with the
> > >> design.
> > >> c) Do not allow overwrites
> > >> we can drop the .merge files.
> > >>
> > >> They are needed to support any of the three use cases above.
> > >> I am mostly concerned about the last one because allowing overwrites on
> > >> per section basis was something was requested in one of the RFEs.
> > >> However here is how we can work around this because IMO it is a corner case.
> > >>
> > >> - The merge code will read snippets from a single directory.
> > >> - It will inspect the name. If the name is <xxx>.over.conf then it will
> > >> treat this file as the snippet that the author of the snippet wants to
> > >> use to overwrite sections in the original config file. If the name of
> > >> the file is <yyyy>.conf it will user it to do additive merge. If file
> > >> has any other extension it will be ignored.
> > > This is not a bad idea, I need to think about it.
> > 
> > Sure. I am open to alternatives.
> > I do not like naming conventions that much but if we have to do it here 
> > so be it.
> 
> The other option is to add a directive within the file.
> Like the first key must be merge = yes or override = yes without
> section ?
> 
> > > Another option I can see is that he application tells you (via library
> > > call) what sections are overridable, but that is quite limiting and may
> > > not satisfy the original requester.
> > >
> > >> Common rules about snippets:
> > >> - Snippets must have a section defined - absence will cause an error and
> > >> snippet will be ignored
> > > +1
> > >
> > >> - Snippets can't have the same section defined in more than one .conf
> > >> file. If same name is detected it will be treated as a collision and all
> > >> snippets will be ignored
> > > I would rather say, only the first will be considered and all
> > > conflicting one after that ignored.
> > 
> > Which one is the first?
> > It becomes implementation specific and depends on either dates or 
> > lexical order of the file names.
> 
> A lot of programs depend on ordering, so we need to explicitly know how
> INI will order snippets.
> 
> It is conventional to do it in lexicographic order.
> 
> SSSD also scans domains in order in the list (when more than one domain
> is configured to not use fully qualified names, that is important), so
> we need to be able to tell admin what the order will be.

I'm sorry to jump so late into the thread.

About omiting the list of domains and services -- in general I agree
with the idea. It was also requested by Stef earlier and would be nice
to have for the desktop integration down the road.

If the list, is present, on the other hand, we should treat it as
authoritative and only take domains/services that are in the list into
account and conversely error out on domains/services that are referenced
from the list but not defined.

With ordering, I think lexicographic is the only option. Init scripts
have used the same schema (also proposed by Lukas in the other mail) for
ages and it's something admins are used to.

But I also wanted to check about ordering in a single file. If I define
two section in the INI file, would the parser process them in the same
order they are defined in the file? I think this is also something the
admins expect.



More information about the sssd-devel mailing list