Could you describe in greater detail how you would use this feature? Are you looking for the ability to store configuration for different domains in separate configuration files? Or are you looking for the ability to set defaults for your domains in the master sssd.conf and add overrides or addons in another file? Or something else entirely?

Fields changed

component: SSSD => INI Parser
keywords: include configuration sssd.conf =>
milestone: SSSD 1.9.0 => NEEDS_TRIAGE

Hi,
Both scenarios you described are interesting.
I was thinking more about the former: the possibility to split configuration based on a logic grouping of directives. A file per domain is a good example of what I was intending/asking.

Your second scenario, the possibility to overwrite directives already specified, is also a lot interesting and would give me a lot of flexibility I was not yet thinking at the moment.
I was not asking this, but I think it would be a good feature enhancement.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11 beta

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=790113

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=790113 790113]

This was requested again by a different user - https://fedorahosted.org/pipermail/sssd-devel/2012-March/009043.html

I think we need to divide this into two tickets. There really are two different requests going on here.

The original request for this ticket was "the possibility to split configuration based on a logic grouping of directives. A file per domain is a good example of what I was intending/asking."

However, the request made in the email thread was more like my second question. He wants the ability to set up the configuration centrally, but be able to merge "override" values into it from a secondary local file.

I think we probably need to account for both cases, but they deserve separate tickets. I've opened ticket #1264 to track this.

blocking: => 1264

Fields changed

proposed_priority: => Nice to have

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD 1.11 beta => SSSD 1.10 beta

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

cc: marco.pizzoli@gmail.com => marco.pizzoli@gmail.com, Michael.Gliwinski@henderson-group.com
changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
review: => 0

There is actually no plan to support "include" semantics in ding-libs used by sssd to read INI files. Rather SSSD can potentially merge different configs coming from different files. Ding-libs supports that. It is only the question of defining the rules and using the merge capabilities of ding-libs.

Putting up to NEEDS_TRIAGE so we can discuss the priority on the next meeting.

Fields changed

milestone: SSSD 1.13 beta => NEEDS_TRIAGE

Fields changed

keywords: => localaccounts

The #include option is not something we want to do. The reasons for that are:
- With "include" option you need to specify what you include i.e. you need to modify sssd.conf first. We think that the feature should not require explicit include statement because it somewhat defeats the purpose of being able to augment the SSSD configuration without changing main config file.
- Include option would be a spacial option that parser would have to recognize in the format that is different from everything else. It is sort of a completely new construct grammar wise.

We created a new ticket #2247 that supersedes this one.

resolution: => wontfix
status: new => closed

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Fields changed

design: => https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
mark: => 0
sensitive: => 0

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/2207

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.