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 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.
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.
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.
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.
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.
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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
--
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.