On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <tom@xxxxxxxxxx> wrote:
On 18/07/17 15:12, Stephen Gallagher wrote:
>
>
> On Tue, Jul 18, 2017 at 10:00 AM Tom Hughes <tom@xxxxxxxxxx
> <mailto:tom@xxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
