On 03/22/2016 12:29 PM, 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.
Michal
I forgot to notice one more thing.
There can be conflicts in configuration
among the snippets in /etc/sssd/conf.d directory.
IMO the best thing to do in this situation is
to end with an error. Defining priorities among
the snippets could cause situations where people
will write difficult to debug configurations.
Michal