On Tue, Apr 01, 2014 at 11:51:23PM -0400, Dmitri Pal wrote: > On 04/01/2014 05:26 AM, Sumit Bose wrote: > >On Fri, Mar 28, 2014 at 09:08:33PM -0400, Dmitri Pal wrote: > >>Hello, > >> > >>Please review: > >>https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge > >I would like to start with a few general comments. > > > >About .merge.conf. I think the name has to contain the name of the > >original config file, because there might be multiple different config > >files in the same directory. I you really want to keep the '.' at the > >beginning I would suggest .<conf_file_name>.merge.conf . But I would > >suggest to drop the '.' because the merging rules are part of the > >configuration and should not be hidden. > Dot at the beginning just to differentiate that it is a service file > rather than the main config file. > > I am not sure you understood the approach I took. The assumption is
yes, I'm sorry, I didn't read carefully enough. I was under the assumption that the .merge.conf will be on the same level as the main config file and not in the config sub-directory. > that in a directory can be only snippets related to one main file. > For example it is expected that in /etc/sssd.d directory there will > be snippets of SSSD and not any other file. > I also find it wrong that different applications have access to the > same directory. This way they can step on each other. > Instead I suggest that if we have application X and application Y > augmenting SSSD config they will create sub directories under > /etc/sssd.d > /etc/sssd.d/X > /etc/sssd.d/Y > and put their snippets into these sub-directories. It is expected > that they can have augmentation to different sections of the main > file but only one declaration file. This is why I do not see a > reason to add a name to the file. I see. You should add this to the 'Proposed convention' section of the design page. Having sub-directories per application makes it easier to install the .merge.conf and the file with the config snippets. > > > > > >Additional I could imagine that people would like to have the merging > >rules in the master config file, e.g. in special sections like > >[__section_name_MERGE_RULES__]. > > This is covered by the rules. > The main application actually dictates whether overwrite is allowed > or not. It either allows it or not and snippets declare whether they > would want to overwrite if the application allows overwrites. How does the application dictates it? Only by the source code or can this be modified by the main config file as well? > I am not ready to go to the complexity of SSSD saying: you can > augment one section but not another. This is going too far. > This can be a future RFE if someone asks about it in future. > > > >I think currently most application which support having parts of the > >configuration in separate files use the following scheme. They have a > >central config file, e.g. /conf_path/app.conf, at a hardcoded > >(changeable with command line options) place and a directory > >/conf_path/add.d. What the application reads as configuration can be > >seen as the result of > > > >cat /conf_path/app.conf /conf_path/add.d/* > > This is a very bad merge logic. It is last in wins. INI supports > this merge logic as one of options but it is not default and I do > not think it should be. no, there is no merge logic at all, see the two conditions below. > > > > > >I would suggest to add this scheme as a default mode if no merge config > >file is available with the following conditions: > >- all files must start with a valid section header, i.e. each file has > > to be valid ini file > >- duplicated section names are not allowed, i.e. no merging of any kind > > will be done > > > I do not like the current approach. > IMO current approach is too primitive and insecure (and thus wrong). > The whole point is to prevent applications from stepping on each > other and updating main config file when they are not entitled to. It is primitive, but why it is insecure? With the two conditions above the main config file cannot be updated, only new sections can be added, and applications cannot step on each other, because duplicated section names will lead to an error. My point is not about merging but supporting what imo is currently the main use case for a directory with config snippets. I think this might help the adoption by other projects if they see that libini provides a simple interface for their current use case. Later on they will learn about the more advanced features and will use them it they make sense for their project. > > > > >I think this will cover the majority of use cases without defining the > >merging rules explicitly. And it would be possible to do this with the > >current API, i.e. applications must be only linked against the new > >version of libini to make use of configuration files in > >/conf_path/add.d/*. > > This is not that simple. They would have to change anyways so it is > not a design goal to try to convert these applications. > IMO providing a clear merge logic and discretion is the key. > It makes sense for our security related applications, it is much > more important to satisfy their needs than to make a generic > library. > > From the SELinux POV it would be better to force applications that > try to add to augment main config file to create sub directories > under "mainfile".d. Do I understand correctly that the config snippets shall not only be created at install time, but modified by the application itself at runtime? Or do you mean the user level that e.g. a user with the SELinux role appXadm_r is allowed to edit files in a special directory related to application X? How shall the file-system permission look like for the directory, config snippets and .merge.conf file? Can you add some examples, either generic or specific for SSSD or gssproxy, which show the main config file, config snippets and .merge.conf first and then the resulting combined configuration? They can be re-used later in unit tests as well. bye, Sumit > > > So bottom line, I mostly disagree that what you propose to solve is > a design goal. > > Thanks > Dmitri > > > > >bye, > >Sumit > > > >>-- > >>Thank you, > >>Dmitri Pal > >> > >>Sr. Engineering Manager for IdM portfolio > >>Red Hat Inc. > >> > >> > >>------------------------------- > >>Looking to carve out IT costs? > >>www.redhat.com/carveoutcosts/ > >> > >> > >> > >>_______________________________________________ > >>sssd-devel mailing list > >>sssd-devel@lists.fedorahosted.org > >>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > >_______________________________________________ > >sssd-devel mailing list > >sssd-devel@lists.fedorahosted.org > >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > > > -- > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
