Bug 867864
Summary: | realm join command works but uses incorrect DNS name for dynamic DNS update | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stijn Hoop <stijn> |
Component: | realmd | Assignee: | Stef Walter <stefw> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | jhrozek, stefw, yaneti |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-05-13 15:01:59 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
Stijn Hoop
2012-10-18 13:01:37 UTC
Interesting. We need to solve host names better, possibly changing the local host name when joining an AD domain, the same way AD does on Windows. In Fedora 19 sssd takes care of updating the domain with the right DNS host name. So I think we can mark this as fixed. (In reply to comment #2) > In Fedora 19 sssd takes care of updating the domain with the right DNS host > name. So I think we can mark this as fixed. Just to make sure -- the SSSD would use the host name configured with ad_hostname directive, falling back to machine's host name. Does realmd configure ad_hostname with a meaningful value? It didn't on the test machine I just checked, but that was F-18... Also, the SSSD would only update the hostname after going online for the first time. So the sequence could be: * realm join -- joins the machine w/o updating the DNS entry * machine is idle and neither NSS nor PAM requests are made * the SSSD starts offline, so until the first periodical DNS refresh, there would be no update at all. This could be mitigated by the SSSD forcing the first refresh after startup (or after initial configuration?) no matter the refresh interval. (In reply to comment #3) > This could be mitigated by the SSSD forcing the first refresh after startup > (or after initial configuration?) no matter the refresh interval. I think there needs to be a generic mechanism to tell SSSD its starting up for a domain for the first time since it was (re)configured, and to perform the various actions it needs to do at that point. For example: * DNS updates * (future) GPO machine policy pull etc. (In reply to comment #4) > (In reply to comment #3) > > This could be mitigated by the SSSD forcing the first refresh after startup > > (or after initial configuration?) no matter the refresh interval. > > I think there needs to be a generic mechanism to tell SSSD its starting up > for a domain for the first time since it was (re)configured, and to perform > the various actions it needs to do at that point. For example: > > * DNS updates > * (future) GPO machine policy pull > etc. This is a very good idea, but a totally generic mechanism is out of scope for 1.10, I'm afraid. But I think it would make sense for DNS updates and we could squeeze that change to 1.10 very easily. So I'm going to create two upstream RFEs - one for a generic mechanism for providers to register callbacks that would be invoked if the SSSD is reconfigured and one for enabling the DNS updates after the first startup. Thank you for taking the time to brainstorm about the issue, Stef! (In reply to comment #5) > So I'm going to create two upstream RFEs - one for a generic mechanism for > providers to register callbacks that would be invoked if the SSSD is > reconfigured https://fedorahosted.org/sssd/ticket/1925 >and one for enabling the DNS updates after the first startup. https://fedorahosted.org/sssd/ticket/1926 |