On Wed, Jan 27, 2016 at 09:17:09AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On 01/27/2016 05:27 AM, Jakub Hrozek wrote:
> On Wed, Jan 27, 2016 at 09:43:21AM +0000, John Hodrien wrote:
>> On Wed, 27 Jan 2016, Jakub Hrozek wrote:
>>> I'm glad it helped. FWIW, we're considering adding a nosync option
>>> the cache as well at some point, which should have the same
>>> performance effect as using tmpfs except the cache would be persistent
>>> (otoh, if sssd was killed during the transaction, the cache might got
>>> corrupt..which is why always sync by default)
>> Sounds like a great option to add. If you can't sanity check it, just
>> deleting it if you don't know that it's been cleanly written may work?
> Yes, that might be one idea, write some 'canary' on shutdown and start
> fresh if the canary was not there.
> Coming up in 1.14..
The problem is that when the cache is deleted, it's not just losing the remote
data. The cache also maintains the cached credentials, so it would break in
the following common scenario:
Yes, but the majority of users who require this speed up require it for
use on the IPA server itself for example.
Road warrior is out at a customer site and forgets their power cable. By
unfortunate chance, the battery runs out while the cache is being written to
(for any of a thousand reasons). Once the machine is plugged back in and
powered on, SSSD starts up and sees that the cache canary is missing, so it
deletes the cache and starts anew. Now the user cannot log in because their
cached credentials are no longer there (and since they're sitting in a hotel
somewhere far from a direct hookup to their company network, they can't get
This... would not be a good thing.
Now, I can certainly see an argument for having such a nosync (or deferred
sync) option for machines that are expected to always be connected to the
identity network (and as such are using SSSD mostly for performance and
surviving the occasional outage hiccup). But I'd say that such an option, if
added, should be VERY carefully documented to explain all of the things that
could go wrong.
btw the other thing we've been talking about is only do write the entry
when it actually changes. Most of the time, when we refresh the entry
from the server, nothing changes. The idea would be to write only the
dataExpireTimestamp and other stampts to a separate ldb file that would
be in nosync mode. Only write the data with full sync if something
actually changes. That way, if we lose the nosync database, we'd only
> As an aside, there are plenty of other things that can go wrong when the cache
> is deleted, including manual overrides from the sss_override command as well
> as ID ranges if any of them had hash collisions or were using the autorid
> compat mode.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> -----END PGP SIGNATURE-----
> sssd-users mailing list