1

Generally, it seems, the idea with conf.d-style directories is to allow a very modular, drop-in method to add features or configurations. With SSSD, specifically, it would seem logical to add further domains to configuration files under /etc/sssd/conf.d/ (RHEL). The domains directive in the [sssd] section of the configuration defines which domains will actually be used.

The 'man' pages for SSSD state that conflicting values of a given section/parameter will take the value of the last value based on an alphabetical sorting of the configuration files. Therefore, it isn't really possible to just deploy a new domain configuration without consideration for the existing configuration because, if the new configuration file contained an [sssd]/domains configuration directive containing only the name of the domain in the same file then that may be the only domain that gets configured.

It seems most likely that one would still need to modify the [sssd] section of sssd.conf when deploying further configurations to conf.d. This seems like the solution to me but I wanted to query the community to see if there are other, more clever, solutions.

1

You're right that defining domains is not well defined. What we plan on doing for (one of) the next version(s) is to make the domains= parameter optional. That way, any defined domain section would automatically be enabled and you could just drop domains and control their order by names of the snippets that include the domains.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.