Hide Forgot
Description of problem: Please see the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1101782 Ian came up with a patch Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. remove sssd caches (simulating a fresh system) 2. reboot 3. attempt to mount an autofs map w/o restarting either autofs or sssd Actual results: no maps were cached Expected results: autofs would retry, sssd would return the maps, shares would be mounted Additional info: 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)
Upstream ticket: https://fedorahosted.org/sssd/ticket/2371
*** 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 - > 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. 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 exist.