On 18/07/17 15:26, Stephen Gallagher wrote:
On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes <t...@compton.nu
<mailto:t...@compton.nu>> wrote:
Well none of my newly upgraded F26 machines appear to be running it ;-)
I said "default". So for fresh installs this is the case.
Yes my laptop, which had been installed with F26, was indeed running it.
It appears that whatever enabled it (anaconda?) did so by manually
editing nsswitch.conf however, so running "authconfig --updateall" to
rebuild the configuration would have disabled it.
> 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).
I never really bothered with sssd because I understood it's purpose to
be caching network users for disconnected use and I as I don't use
network users anywhere, let alone on machines that need to continue
working when disconnected, it didn't seem worth learning about.
I have now tried enabling it on another machine and we'll see how that
goes...
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
