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 :-)
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. 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
