On 22 Mar 2016, at 16:19, Michal Židek <mzidek(a)redhat.com>
wrote:
On 03/22/2016 03:29 PM, Sumit Bose wrote:
> On Tue, Mar 22, 2016 at 12:29:39PM +0100, Michal Židek 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).
>>
>> Of course sssd will have an cli option to
>> use alternative directory for snippets (similar
>> to what we use for config file now).
>>
>> Could it be implemented this way?
>> Any comments are welcome.
>
> How will this interact with the python configuration API? If some
> application will use the API to change the configuration the result will
> be written to sssd.conf. But if there is a config snippets which sets
> the same value the change via the config API is overridden which I guess
> is unexpected by the application using the config API.
Would it be possible in this case for configAPI to load the resulting config file even
with include files and if the value is different from the one set. then raise an
exception? Maybe the admin could then pass a flag to configAPI to force-override the
override?
>
> bye,
> Sumit
>
Good question. I was not thinking about this. We
could change the config API to actually write to its
own snippet that will be always applied last.
OTOH some admins may want to really override whatever
other applications may set up using python config API.
If we decide to apply snippets in alphabetical
order as Lukas suggested, we can give the snippet to which
python API writes a name for example 990_pyapi.conf
and if the admin decides to create snippet with starting
number lower than 990 it will have lower pririty than
python config API.
We should document such behavior in the README file
that will be placed in the /etc/sssd/conf.d directory.
Hmm, this could work, except dowgrades to a version that does not support include
directory, in that case this pyapi override wouldn't be reachable..
Also, I'm not sure if this would solve the problem Sumit describes where the admin has
some (opaque) config and calls the confiAPI to change a parameter..