Learn more about these different git repos.
Other Git URLs
Setting ad_hostname to the fqdn and then running sssd with a sufficiently high debug level shows the commands that are sent to nsupdate. Changing ad_hostname to just the hostname (without domain) yields the following nsupdate-related log lines (timestamps stripped) which are materially different from the successful version:
[sssd[be[my_domain.com]]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error [sssd[be[my_domain.com]]] [nsupdate_get_addrs_done] (0x0040): Could not resolve address for this machine, error [5]: Input/output error, resolver returned: [11]: Could not contact DNS servers [sssd[be[my_domain.com]]] [nsupdate_get_addrs_done] (0x0040): nsupdate_get_addrs_done failed: [5]: [Input/output error] [sssd[be[my_domain.com]]] [sdap_dyndns_dns_addrs_done] (0x0040): Could not receive list of current addresses [5]: Input/output error
This described behaviour is not necessarily wrong, however when ad_hostname is not set, sssd internally sets to to the hostname without fqdn (I'm assuming that sssd to obtains the hostname from /etc/hostname, or via one of the APIs that does effectively the same, e.g., gethostbyname, which is supposed to return just the hostname unless explicitly told to return the fqdn). After that, the behaviour described above happens. In other words, this bug should perhaps request that when ad_hostname isn't set explicitly, it then gets set to the fqdn.
Either way, the obvious workaround is to specify ad_hostname = fqdn .
I think this is kindof expected. We try to resolve the ad_hostname to learn the "current" IP addresses so that we can do a diff and see if it's even necessary to spawn nsupdate.
I may not be correctly understanding something here, but it seems incorrect behaviour. Here's a test that, imo, demonstrates that:
If I remove the machine in question from DNS, and then restart sssd, then when I have ad_hostname set to the fqdn, it'll add the machine to DNS. On the other hand, when I either have ad_hostname no set or set to just the machine name, then there is no call to nsupdate (even DNS resolution fails, as it should).
Replying to [comment:2 bpflanz]:
I may not be correctly understanding something here, but it seems incorrect behaviour. Here's a test that, imo, demonstrates that: If I remove the machine in question from DNS, and then restart sssd, then when I have ad_hostname set to the fqdn, it'll add the machine to DNS. On the other hand, when I either have ad_hostname no set or set to just the machine name, then there is no call to nsupdate (even DNS resolution fails, as it should).
If ad_hostname is not set, then it defaults to the machine's hostname as reported by gethostname(). If it's set to a non-FQDN, then DNS updates will not work, sorry. (Actually I kindof also expect Kerberos to not work, but I haven't tested that at all).
resolution: => invalid status: new => closed
According to the man page, gethostname(2) should return just the hostname. To get the FQDN you should then call gethostbyname(2), passing it the result from gethostname(2).
As such, this remains a bug, because sssd seems to be expecting gethostname(2) to return the FQDN, despite this contradicting the documentation.
For reference, see man hostname: http://unixhelp.ed.ac.uk/CGI/man-cgi?hostname
Fields changed
resolution: invalid => status: closed => reopened
Our bind/nsupdate expert is kindly looking into whether we can remove the diff altogether, removing the need to resolve the hostname. If we could remove the diff functionality, then we could just always send the nsupdate message.
But still,the hostname /must/ be FQDN, period. Consider the use-case of a newly enrolled client, maybe an image in the cloud that must self-register. In that case, there's nothing to ask DNS about..(also, we can't use the gethostbyname/getaddrinfo calls as they are synchronous anyway...)
So we're not implementing the 'canonicalization' of the hostname, sorry. We might remove the diffing of address records to simplify the nsupdate even further.
resolution: => wontfix status: reopened => closed
Metadata Update from @bpflanz: - Issue set to the milestone: NEEDS_TRIAGE
Just ran into this issue today and read the discussion here https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/QHBRCO2JR36PT5F4ZPZNGUHCEE5E4G42/.
I am very disappointed (maybe confused) that we can't at least have an option (opt-in) that allows us to tell SSSD canonicalize the hostname. Now we have to hardcode hostnames in all our SSSD conf. Sad day for computing.
Or even an option which defines which method to use to get the hostname, gethostname() [default] or gethostbyname().
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3607
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.