| Line 20: | Line 20: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1357418 #1357418] | ||
== Detailed Description == | == Detailed Description == | ||
Revision as of 07:42, 18 July 2016
SSSD fast cache for local users
Summary
Enable resolving all users through the sss NSS modules for better performance.
Owner
- Name: Stephen Gallagher and Jakub Hrozek
- Email: sgallagh@redhat.com, jhrozek@redhat.com
- Release notes owner:
Current status
Detailed Description
SSSD ships with a very fast memory cache for a couple of releases now. However, using this cache conflicts with nscd's caching and nscd has been disabled by default. That degrades performance, because every user or group lookup must open the local files.
This change proposes leveraging a new "files" provider SSSD will ship in the next version in order to resolve also users from the local files. That way, the "sss" NSS module can be configured before the files module in nsswitch.conf and the system could leverage sss_nss caching for both local and remote users.
The upstream design of the files provider can be found at: https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider
Below is a mini-FAQ that lists the most common questions we've received so far:
- Q: Does SSSD take over /etc/passwd and /etc/files?
- A: No. SSSD just monitors them with inotify and copies the records into its cache.
- Q: Does SSSD need to be running all the time now? What if it crashes?
- A: SSSD needs to be running in order to benefit from this functionality. However, the nss_sss module is built in such a way that even if sssd is not running, nss_sss should fail over to nss_files pretty quickly (we'll quantify "pretty quickly" in a more scientific fashion soon)
- Q: Do I need to configure SSSD now?
- A: No, we'll ship a default configuration.
Benefit to Fedora
User and group resolution in Fedora will be much faster, thanks to the fast cache provided by SSSD.
Scope
- Proposal owners: Jakub Hrozek and Stephen Gallagher work on the design and coding
- Other developers: The SSSD upstream will participate in code review of the change
- Release engineering: None required
- Policies and guidelines: None needed
- Trademark approval: None needed
Upgrade/compatibility impact
N/A (not a System Wide Change)
How To Test
Test by running getent passwd/getent group/id from the command line or library calls such as getpw*/getgr* from a program.
User Experience
Improved performance of user and group lookups in the default installation of Fedora.
Dependencies
The glibc release that ships the default nsswitch.conf will have to conflict with an sssd version that didn't provide the files provider yet. This has been discussed with the glibc maintainers and approved.
Contingency Plan
- Contingency mechanism: Because this change is enabled or disabled by setting the order of NSS modules in nsswitch.conf, the only change we'd have to do is to revert the order back to files sss in libc and remove the conflicts.
- Contingency deadline: Before the Beta
- Blocks release? No
- Blocks product? product
Documentation
The upstream design is at https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider