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..
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?