On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <t...@compton.nu> wrote: > On 18/07/17 15:12, Stephen Gallagher wrote: > > > > > > On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <t...@compton.nu > > <mailto:t...@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).
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
