#1828 [RFE] Tool to display current configuration
Closed: wontfix 4 years ago by pbrezina. Opened 11 years ago by rcritten.

It would be nice to have a tool like Samba's testparm command to display the current configuration. The ad and ipa providers hide a lot of complexity by pre-defining a lot of default attributes, but you don't necessarily know exactly what sssd is going to do because a lot of configuration isn't shown in the config file.

sgallagh suggested that this should be easily accessible via the python bindings.


I looked into this today, and it's really not as easy as it sounds. The SSSDConfig API isn't built to show the internal defaults, it's really only designed for handling manual configuration and overrides.

There are a couple problems here:
1) The SSSDConfig API data files do not have the defaults for all entries. We would have to mirror the contents of the various ldap_opt type files (as well as all of the places that we only list the default in the source and manpage). Fixing this would pretty much require completing ticket #1386.

2) Not all options have pure defaults. We have multiple examples of options whose default is to use the value of another option (which may or may not have been set). For example, {{{ldap_user_search_base}}} defaults to the value of {{{ldap_search_base}}}, which may or may not have been set. Furthermore, {{{ldap_search_base}}} defaults to the value detected from the RootDSE at connection time, which we cannot know ahead of time in a tool. Other examples include the {{{ipa_domain}}} option which automatically sets the default for {{{krb5_realm}}} and {{{dns_discovery_domain}}}.

In short, I'm inclined to say that this ticket is unsolvable as a tool, though we can (and should) do a better job of reporting every configuration value in the debug logs at {{{SSSDBG_CONF_SETTINGS}}} when it is initially determined by the code. This way an admin can at least view the debug logs to get this information.

blockedby: => 1386
cc: => chudson@redhat.com, sgallagh
component: SSSD => sss_tools

What about an option to sssd itself to say "read the config, get things set up, but instead of forking off the daemons just print the config and quit"?

Still won't work for the reasons above. Some of the defaults differ based on the value of other options, which provider it is, etc. Furthermore, we have options that may not be configured until we read the RootDSE.

We can add internal sbus calls to query the various backends, but I do
not know if the work needed is justified for now.

How about a log level that logs the config on startup.

The use case for this, unlike Samba, isn't "let me test the configuration" it is more "what the heck is the configuration being used since there are a lot of defaults". So I think having any way to see what all the options are is acceptable.

We already log the options on startup but as Stephen said above, we should make sure these logs use a predictable log level. Currently it's a mix of what seemed like a good idea at the time.

IMO the right solution would be to keep an object in memory that would reflect currently resolved configuration. I should be built dynamically as things are read from config DB resolved. Then this object should be queried by the tool probably over SBUS.

Some work. Probably a good candidate for a thesis.

Fields changed

cc: chudson@redhat.com, sgallagh => chudson@redhat.com, sgallagh, chudson

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12 beta
rhbz: => todo

Under this ticket we should provide a way to report all domain information statically and dynamically configured for SSSD.

changelog: =>
review: => 0

Fields changed

keywords: => Status

Fields changed

blockedby: 1386 => #1386

Pavel plans on working on a status utility, at least some of the information could be exposed over D-Bus.

mark: => 0
owner: somebody => preichl
sensitive: => 0

Fields changed

owner: preichl => pbrezina

We have the sssctl tool, but this functionality is not implemented yet.

milestone: SSSD 1.14 beta => NEEDS_TRIAGE

The sssctl tool already can do a lot of things, like displaying the servers that were discovered or displaying the cache entry timestamps. This functionality, however, is not implemented yet and should be implemented in one of the next releases.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.16 beta

Fields changed

milestone: SSSD Future releases (no date set yet) => SSSD 1.15.3

Metadata Update from @rcritten:
- Issue assigned to pbrezina
- Issue marked as depending on: #1386
- Issue set to the milestone: SSSD 1.15.3

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: None
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.15.3)

7 years ago

Metadata Update from @jhrozek:
- Custom field blocking adjusted to 1386
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: cleanup-future

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue untagged with: cleanup-future
- Issue set to the milestone: SSSD Future releases (no date set yet) (was: SSSD 1.15.4)

6 years ago

Metadata Update from @pbrezina:
- Assignee reset

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: Canditate to close, bugzilla

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

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

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.

Login to comment on this ticket.

Metadata