> On 23 Mar 2016, at 11:11, Michal Židek <mzi...@redhat.com> wrote: > > 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 :) >
I would prefer sssctl config, too. >> >> 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. btw I don't think the ability to see which config comes from which file is a blocker, just a nice to have. Would libini at least let admin know that it's processing some include file? I'm just concerned about admins banging their heads against the wall when they configured foo=bar in sssd.conf yet sssd would keep using foo=baz :) > >> >> 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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
