> 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.. > 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? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
