On 03/22/2016 09:10 PM, Jakub Hrozek wrote:
> On 22 Mar 2016, at 12:29, Michal Židek <mzidek(a)redhat.com> wrote:
>
> Hi,
>
> I would like to write a patch that will
> allow SSSD to use the config file merging
> feature from libini. But first I would like
> to ask developers for their opinions on how
> this should be implemented.
>
> My idea was that it could work like this.
>
> The current /etc/sssd/sssd.conf would work
> as usual.
>
> We would add new directory /etc/sssd/conf.d/
> and its content would be following:
> - README file that informs what the direcotory
> is for.
> - any number of files ending with .conf extension
> that would contain additional configuration for
> SSSD. These files would have higher prioriry
> than the /etc/sssd/sssd.conf , meaning if
> the same option is present in these files
> it will override the /etc/sssd/sssd.conf
> value.
>
> SSSD would automatically pick up files ending
> in .conf from that direcory and use them. In
> order to disable the config file, the admin will
> have to rename the file ending (for example
> .conf.disabled). This way, we do not need to
> inspect the snippets for any special options
> like 'enable_this_snippet = true' which would
> just complicate the processing.
>
> In order for SSSD to load a configuration, all
> the config snippets in /etc/sssd/conf.d/ and
> /etc/sssd/sssd.conf must in combination
> result in valid configuration. If there is an
> error in processing one of the config files,
> the whole configuration loading will be
> unsuccessful and there will be no way to
> skip problematic snippets (later we may add
> a fallback config, but that is different issue).
>
I guess for now this is acceptable, because the snippet is similar to editing the conf
file (as Sumit noted) but it would be nice to at least note in the design page of the
fallback config and this merging feature that they are interconnected..
> Of course sssd will have an cli option to
> use alternative directory for snippets (similar
> to what we use for config file now).
>
Does anyone use the -c option actually (maybe except tests?)
If not, do we need to add a new option? I'm cautious here, because any new option
needs to be supported (almost) forever..
Ok, we can do it without an option and add the option if there is a
demand for it. It will be easy change (cca 15 lines + doc).
> Could it be implemented this way?
> Any comments are welcome.
>
Would the admin be able to discover from debug message where an option comes from (conf
file or snippet) ? Does libini provide that info?
Libini does not provide that info. I was thinking about creating a
tool (not sure if Python or C, I think Python will be easier for
this) that would be called sss_showconf and it would print
the actual configuration to stdout. With
$ sss_showconf -s
or
$ sss_showconf --show-source
it would label each line with prefix that would say, where this line
comes from. I think this would be easy to do in Python. We could
start working on the tool once the merging is finished.