On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes tom@compton.nu wrote:
On 18/07/17 15:12, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom@compton.nu mailto:tom@compton.nu> wrote:
On 18/07/17 14:48, Jaroslav Reznik wrote: > The default profile set will contain the following profiles: > > Local users + SSSD -- local users and remote users are handled by sssd > Local users + SSSD + Fingerprint -- same as above but also pam_fprintd > is enabled > Local users + winbind -- local users are handled by files and
remote
> users by winbind > Local users + winbind + Fingerprint -- same as above but also > pam_fprintd is enabled No "local only" profiles for people that don't need sssd? What is the effect of this on configurations that haven't been using sssd at all? Is everything going to suddenly start blocking/timing
out
on being unable to talk to it?
Starting with F26, the default configuration is for all setups to be using SSSD. See https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
Well none of my newly upgraded F26 machines appear to be running it ;-)
I said "default". So for fresh installs this is the case.
This is actually advantageous, since the previous behavior was that all access to local users previously had to hit the disk (unless nscd was manually configured). If SSSD isn't responding, nsswitch will fail back to the old behavior fairly quickly.
I normally disabled nscd as well because the caching was just way too annoying...
SSSD's caching is a lot more reliable for local users than nscd, as it monitors all of the relevant files with inotify and will immediately flush its cache anytime a change occurs to those files. It also does a full cache when this happens, rather than on-demand, so the only time there should ever be a lag here is on a request the instant between when a change is made on the disk and SSSD reloads it (during this time, SSSD just doesn't cache at all and passes the request on to nss_files.so to answer straight from the disk).
Also, the SSSD cache in use isn't strictly dependent on the SSSD daemon running; if SSSD was to crash and be in the middle of restarting, the memory-mapped fast cache will continue on independently. So in theory, there really shouldn't be any downside to this change (and I encourage you to tweak your upgraded boxes to use the new configuration).