On (22/03/16 15:44), Simo Sorce wrote: >On Tue, 2016-03-22 at 16:19 +0100, Michal Židek wrote: >> On 03/22/2016 03:29 PM, Sumit Bose wrote: >> > On Tue, Mar 22, 2016 at 12:29:39PM +0100, Michal Židek 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). >> >> >> >> Of course sssd will have an cli option to >> >> use alternative directory for snippets (similar >> >> to what we use for config file now). >> >> >> >> Could it be implemented this way? >> >> Any comments are welcome. >> > >> > How will this interact with the python configuration API? If some >> > application will use the API to change the configuration the result will >> > be written to sssd.conf. But if there is a config snippets which sets >> > the same value the change via the config API is overridden which I guess >> > is unexpected by the application using the config API. >> > >> > bye, >> > Sumit >> > >> >> Good question. I was not thinking about this. We >> could change the config API to actually write to its >> own snippet that will be always applied last. >> >> OTOH some admins may want to really override whatever >> other applications may set up using python config API. >> >> If we decide to apply snippets in alphabetical >> order as Lukas suggested, we can give the snippet to which >> python API writes a name for example 990_pyapi.conf >> and if the admin decides to create snippet with starting >> number lower than 990 it will have lower pririty than >> python config API. >> >> We should document such behavior in the README file >> that will be placed in the /etc/sssd/conf.d directory. > >If you make sssd.conf always win over snippets then you do not need to >change anything, though. > If you make sssd.conf always win then you will not be able to override there anything. An int's not usual in other projects.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
