* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)? - Not since sssd-1.15.0-4.fc26. Starting with that build, if a configuration doesn't exist, sssd falls back to configuration that serves the contents of local files (/etc/passwd, /etc/group) so that the system can take advantage of the fast in-memory cache (see https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers) * Does the service listen on a network socket for connections originating on a separate physical or virtual machine? - no * Is the service non-persistent (i.e. run once at startup and exit)? - no * What is the exact name (or names) of the systemd unit files to be enabled? - sssd.service * Is this request for all Fedora deliverables or only for some Editions (list them)? - all
It doesn't support socket activation? How hard would it be to add?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > It doesn't support socket activation? How hard would it be to add? Yes and no. SSSD is actually a set of deamons. There are 'responders' that are contacted when a client library (such as the nss_sss nsswitch module or the pam_sss PAM module) need to perform an action. Those can be socket activated since the last upstram version (1.15). But these 'responders' resolve data from 'providers' that actually talk to a remote server or mirror data from /etc/passwd or /etc/group. And the path between providers and responders is not ready for socket activation yet, but instead, the providers are started on sssd service startup..sorry. Hopefully it would be in the next version. btw you are right that it might make sense to ask for the sockets like sssd-nss or sssd-pam to be activated as well and I'd like them to, but at the moment, we still have two bugs that might hit our users: - https://github.com/SSSD/sssd/pull/143 - https://github.com/SSSD/sssd/pull/146 I'm quite confident we would fix both this week since there are patches pending and on review, but I would prefer to ask for those sockets to be activated (if an approval for those is needed?) once we merge those patches.
(In reply to Jakub Hrozek from comment #2) > btw you are right that it might make sense to ask for the sockets like > sssd-nss or sssd-pam to be activated as well and I'd like them to, but at > the moment, we still have two bugs that might hit our users: > - https://github.com/SSSD/sssd/pull/143 > - https://github.com/SSSD/sssd/pull/146 > > I'm quite confident we would fix both this week since there are patches > pending and on review, but I would prefer to ask for those sockets to be > activated (if an approval for those is needed?) once we merge those patches. Yes, approval for any new preset is required. If they're ready before this BZ is completed, just add them here and I'll amend my PRs: * https://pagure.io/fedora-release/pull-request/77 (master) * https://pagure.io/fedora-release/pull-request/76 (F26)
Merged upstream.
(In reply to Jakub Hrozek from comment #2) [snip] Thanks for the detailed answer. > but I would prefer to ask for those sockets to be activated (if an approval for those is needed?) once we merge those patches. Sounds reasonable. (This kind of change is something that's certainly allowed before Beta, so it seems better to wait until upstream support is finalized.)