Bug 1113639 - autofs: return a connection failure until maps have been fetched [NEEDINFO]
Summary: autofs: return a connection failure until maps have been fetched
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: pre-dev-freeze
: 8.1
Assignee: Pavel Březina
QA Contact: Niranjan Mallapadi Raghavender
URL:
Whiteboard: sync-to-jira
: 1335489 (view as bug list)
Depends On:
Blocks: 1689138 1101782 1679810
TreeView+ depends on / blocked
 
Reported: 2014-06-26 14:22 UTC by Jakub Hrozek
Modified: 2020-05-02 19:14 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
pbrezina: needinfo? (ikent)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github SSSD sssd issues 3413 None open autofs: return a connection failure until maps have been fetched 2020-05-18 08:42:02 UTC
Github SSSD sssd issues 5081 None closed autofs: return a connection failure until maps have been fetched 2020-05-18 08:42:02 UTC

Description Jakub Hrozek 2014-06-26 14:22:30 UTC
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)

Comment 2 Jakub Hrozek 2014-06-27 15:36:42 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2371

Comment 5 Jakub Hrozek 2016-05-15 15:00:01 UTC
*** Bug 1335489 has been marked as a duplicate of this bug. ***

Comment 6 Jakub Hrozek 2016-05-15 15:01:48 UTC
Reproposing to 7.4 for capacity reasons.

Comment 14 Orion Poplawski 2017-04-13 16:46:55 UTC
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.

Comment 15 Ian Kent 2017-04-14 04:34:36 UTC
(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.

Comment 31 Pavel Březina 2019-11-19 13:07:34 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/4120

Comment 39 Pavel Březina 2020-01-06 13:02:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.