Bug 954275
Summary: | sssd fails connect to IPA server during boot when spanning tree is enabled in network router. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | pgustafs |
Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> |
Status: | CLOSED ERRATA | QA Contact: | Kaushik Banerjee <kbanerje> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.4 | CC: | apeetham, dpal, grajaiya, jgalipea, lnovich, lslebodn, mkosek, pbrezina |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | sssd-1.9.2-108.el6 | Doc Type: | Bug Fix |
Doc Text: |
Cause: When locating servers using SRV DNS records failed, the SSSD did not retry the SRV query even after its internal timeout passed.
Consequence: As a consequence, if server discovery failed the first time (prominently during bootup), the SSSD didn't retry this query until it was restarted or the networking status of the client changed, forcing reset of the SSSD networking status.
Fix: The SRV queries were fixed to always retry after a timeout passed
Result: The SSSD now retries SRV queries correctly even if the first resolution fails.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2013-11-21 22:17:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
pgustafs
2013-04-22 07:32:00 UTC
Upstream ticket: https://fedorahosted.org/sssd/ticket/1886 Upstream ticket: https://fedorahosted.org/sssd/ticket/1885 Fixed upstream in d3b39cf07164b23d47bbce3d6e6541b13fc895f5 To reproduce: 1. Configure the SSSD with SRV resolution followed by a real server (for example ipa_server = _srv_, ipa.example.com) 2. Start with a DNS server that can't resolve the real server 3. Attempt to get a user. This should fail and sssd should go offline. 4. Adjust the DNS so that it's able to resolve the real server but still unable to resolve the SRV query. 5. Attempt to get a user again. With the unpatched packages, this will keep failing as sssd wouldn't even try the hardcoded server at all. Make sure the second attempt is at least 30 seconds after the first user resolution. btw I just realized you may not need a DNS server at all but instead you can just put entries into /etc/hosts. I think that will make testing easier a bit. Verified and automated the bug in SSSD Version: sssd-1.9.2-128.el6.x86_64 Steps followed during verification, are mentioned in Comment 9. See the output of the beaker automation run below: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: BZ 954275 - sssd fails connect to IPA server during boot when spanning tree is enabled in network router :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Running 'cat /etc/resolv.conf > /etc/resolv.conf-bkup' (Expected 0, got 0) :: [ PASS ] :: Running '> /etc/resolv.conf' (Expected 0, got 0) :: [ PASS ] :: Running 'cat /etc/hosts > /etc/hosts-bkup' (Expected 0, got 0) :: [ PASS ] :: Running '> /etc/hosts' (Expected 0, got 0) :: [ LOG ] :: Sleeping for 5 seconds :: [ PASS ] :: User lookup is expected to fail (Expected 2, got 2) :: [ PASS ] :: Running 'sleep 40' (Expected 0, got 0) :: [ PASS ] :: Running 'cp -rvf /etc/hosts-bkup /etc/hosts' (Expected 0, got 0) :: [ PASS ] :: Running 'echo "$SERVER_IP $SERVER" >> /etc/hosts' (Expected 0, got 0) :: [ PASS ] :: Running 'sleep 40' (Expected 0, got 0) :: [ PASS ] :: User lookup should succeed (Expected 0, got 0) :: [ PASS ] :: Running 'cat /etc/resolv.conf-bkup > /etc/resolv.conf' (Expected 0, got 0) :: [ PASS ] :: Running 'cat /etc/hosts-bkup > /etc/hosts' (Expected 0, got 0) :: [ LOG ] :: Duration: 1m 30s :: [ LOG ] :: Assertions: 12 good, 0 bad :: [ PASS ] :: RESULT: BZ 954275 - sssd fails connect to IPA server during boot when spanning tree is enabled in network router Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1680.html |