On Tue, 2016-03-22 at 15:15 +0100, Michal Židek wrote: > On 03/22/2016 02:46 PM, Lukas Slebodnik wrote: > > On (22/03/16 14:30), Michal Židek wrote: > >> On 03/22/2016 12:29 PM, 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.
What's the rational behind 'snippets vs main conf' makes snippet a winner ? > >>> 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. > >>> > > Another, way how to ignore snippet is to ignore > > any file which start with dot ".". > > "hiddent files". It would avoid adding suffix to every file. > > > > BTW logrotate and crond do the same > > /etc/logrotate.d/ > > /etc/cron.d/ logrotate also adds .old in var/log, in general you should not have .conf files in conf.d if you do not want them used. Ignoring .something files should always be true as it makes it hard to understand what is going on if you just do ls and can't see a snippet. > >>> 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 do not remember the lib_iniconfig API. > > But it might be already solved there. It is, question though: do you want to allow to override anything in a snippet ? At some point I had the idea the snippet would only allow to define/override a single domain and the snippet name would have to be domain_NAME.conf, but that may be overly restrictive given today we are adding stuff like secrets which has a different way to deal with section names. > >>> 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. > >>> > >>> Michal > >> > >> I forgot to notice one more thing. > >> > >> There can be conflicts in configuration > >> among the snippets in /etc/sssd/conf.d directory. > >> IMO the best thing to do in this situation is > >> to end with an error. Defining priorities among > >> the snippets could cause situations where people > >> will write difficult to debug configurations. > >> > > In most, project you use numbers in the begining of files. > > It guarantee the order and last value win. It's current behaviour > > in sssd.conf. > > So should we rely on alphabetical order? I personally > think it will add a little chaos to the configuration > but maybe not. > > If we decide to rely on alphabetical order it may > be nice to have a tool that will print the actual > configuration in stdout skipping all the overriden options. > This may be good for troubleshooting SSSD. We need an order so that admins can understand why a conflict happened, alphabetical is as good as any. > > > > We can also provide something like "systemctl cat name.service" > > or we can even save parsed/merged.. configuration with > > ini_config_save_as. > > > > What do you think? > > It sounds good to me. The condition for a conf file could be: > (ends with '.conf') and (does not start with '.') > everything else will be ignored. > > > > > BTW you might also look into gssproxy how they implemented it. > > They already uses this feature from lib_iniconfig IIRC. We do, indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
