Description of problem:
Please see the discussion in
Ian came up with a patch
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. remove sssd caches (simulating a fresh system)
3. attempt to mount an autofs map w/o restarting either autofs or sssd
no maps were cached
autofs would retry, sssd would return the maps, shares would be mounted
SSSD autofs client should return a connection error in case no master map can be fetched from LDAP due to back end problems (as opposed to the map being simply absent from LDAP)
*** Bug 1335489 has been marked as a duplicate of this bug. ***
Reproposing to 7.4 for capacity reasons.
I think the symptom of this issue (no maps on boot with fresh cache) was fixed in this commit - https://pagure.io/SSSD/sssd/c/d4063e9a21a4e203bee7e0a0144fa8cabb14cc46?branch=master although in a different manner than originally proposed it seems.
Unfortunately I cannot use sss/db on tmpfs until this is fixed.
(In reply to Orion Poplawski from comment #14)
> I think the symptom of this issue (no maps on boot with fresh cache) was
> fixed in this commit -
> d4063e9a21a4e203bee7e0a0144fa8cabb14cc46?branch=master although in a
> different manner than originally proposed it seems.
> Unfortunately I cannot use sss/db on tmpfs until this is fixed.
Not sure what you mean by "sss/db on tmpfs" but you might be
able to use a workaround that will be in autofs with RHEL-7.4.
Note that we still need to fix this in sss because autofs
still needs a way to distinguish between "map does not
exist" and "map not yet available" rather than delay/retry
logic that will get triggered even when a map really doesn't
Thank you Ian for your explanation. I think all mentioned cases can be addressed.
I agree that we should move this to 8.3 to be on the safe side.