On 03/23/2016 11:02 AM, Lukas Slebodnik wrote:
On (23/03/16 10:53), Michal Židek wrote:
On 03/22/2016 09:10 PM, Jakub Hrozek wrote:
On 22 Mar 2016, at 12:29, Michal Židek <mzi...@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
or sssctl config :-)
That is another option :)
It looks like we implement config file merging on two places
python-sssdconfig and libini. I do not like it but we probably cannot avoid it.
Therefore it would be good to add test that both implementation will result
in the same "result". I would prefer to do it with libini_config
because sssd daemon will use it.
* dump config with libini_config (ini_config_save_as)
* dump config from python-sssdconfig + import with libini and
save ini_config_save_as.
Yes, such test makes sense.
But Jakub wanted to know if there is a way to provide
info about where the option comes from (sssd.conf or which snippet).
libini_config currently can not do that and I think it will be easier
to do it in Python.
The result shoudl be equivalent. IIRC libini will not dump duplicates
because we use last match win.
Or try to use different test.
LS
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
