CC mzidek who works on INI the most these days.

Michal, what do you think?

owner: somebody => mzidek

Sorry instead of CC I assigned the ticket :) Nonetheless, I'm interested in Michal's opinion :)

Hi Robbie and Jakub!

You are correct that it is not currently possible to control merging of snippets in this way. However I would prefer to not include this in SSSD.

If something like this is considered useful by other SSSD team members, then I would propose to NOT add the mark "" on the value side, but on the option name side, preferably at the beginning of the line so that it stands out in the config file and does not interfere with the value (where "" can already have special meaning for the application). So for example:

*foo = bar[[BR]]
foo = baz

The value will be bar. AFAIK "*" is not allowed for option names so this change should be backward compatible with older config files (I would need to check in code to be sure, but in worst case we would pick another character).

Now, to why I do not think this is good idea. IMHO we should have as little rules for merging as possible so that they are easy to understand and do not cause much confusion. We also called the snippets "override snippets" in the past, because they have the power to override previous configuration. Now we would basically add an exception to that rule.

The only use case where I think this would be useful is when the admin is not sure if adding an option to config file will not be overridden by an already existing snippet file. In that case I would prefer to enhance sssctl tool to print current configuration (we already plan this) so that admin can check with sssctl if SSSD has desired configuration after he/she made changes in config file/snippets. We can later enhance this to also print (for each config option) an information about origin (sssd.conf or snippet name) so that admins know what files they should modify.

That being said, maybe it would make sense for other projects outside SSSD, in which case a merging flag could be added to INI and we would simply not use that flag in SSSD.

Michal

I think this was a request to add the functionality into INI from the start (I suspect Robbie is coming from GSSProxy/Kerberos direction, not SSSD).

I know, I just wanted to state my opinion about SSSD and this feature explicitly before someone proposes to use it :)

If Robbie believes that GSSProxy will benefit from this feature, I will not be against its inclusion in libini.

Regarding collisions current merging code has 4 modes. Detect - when collisions detected and reported. Error - when any collision results in error. Preserve - when what is already read is treated as final. Overwrite - when each next duplicate value over writes the previous one.

Snippets are supposed to be merged to a main configuration file. An application needs to decide what is more important: the main file or the snippets. That really depends on the application. So before we add new functionality it would be great to understand what we are trying to express and can it be expressed by something we already have.

Robbie can use share a usage scenario please?

Fields changed

cc: => lslebodn

Replying to [comment:6 dpal]:

Snippets are supposed to be merged to a main configuration file. An application needs to decide what is more important: the main file or the snippets. That really depends on the application. So before we add new functionality it would be great to understand what we are trying to express and can it be expressed by something we already have.

Robbie can use share a usage scenario please?

There's a specific value of the kdc.conf that crypto-policies wants to control but can't due to the way the configuration layer currently works. Upstream has stated that "the handling of config options that can be set either per-realm or globally badly needs refactoring, but it's a nontrivial effort" and that they've had interest in moving to a config library (such as Heimdal's), but that they have not had time and it would require changes to the library.

I opened this ticket to see if we'd be interested in such a feature independent of krb5. I doubt that krb5 will consider any library that would require breaking backward compat in the config files. But, it sounds like that libini doesn't want this feature unless it's for sure going to be used. So this ticket should probably be closed WONTFIX or similar.

It would not be so complicated to add 5th mode for collision merging and enable it only in krb5.

But there might be other issues with parsing current version of krb5.conf with libini_config.

e.g.

[realms]
 EXAMPLE.COM = {
  kdc = kerberos.example.com
  admin_server = kerberos.example.com
 }

It's not pure key value.

About closing - I wouldn't take our previous replies as 'we don't want to implement this'. If there is a use-case and if there is a chance that other projects might use INI, then I think we should go for it..

Replying to [comment:9 lslebodn]:

But there might be other issues with parsing current version of krb5.conf with libini_config.

e.g.
{{{
[realms]
EXAMPLE.COM = {
kdc = kerberos.example.com
admin_server = kerberos.example.com
}
}}}

It's not pure key value.

This is a good point. Thanks Lukas!

Hi Robbie and others,

based on the above discussion, I am closing this as WONTFIX. Thanks for everyone's input. Also feel free to reopen the ticket if you think something like this should be implemented.

Michal

resolution: => wontfix
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4141

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.