On Tue, Mar 22, 2016 at 04:19:48PM +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.
I think we haven't agreed how to solve this.. And I'm not sure I like the lowest-priority override approach, because then overrides would not work for anyone using the configAPI (which is even authconfig..). So I would actually just explain in the configAPI documentation that it modifies the main config file, not the snippets and the admin should choose one or the other. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
