Bug 2257197
| Summary: | Default authselect profiles break `hostname --fqdn` | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Scott Shambarger <scott-fedora> |
| Component: | authselect | Assignee: | Pavel Březina <pbrezina> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 42 | CC: | bugzilla, debarshir, mcatanza, mosvald, pbrezina, pemensik, zbyszek, zjedrzej |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | authselect-1.5.0-4.fc40 authselect-1.5.0-4.fc41 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-06-08 15:41:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2291062 | ||
| Bug Blocks: | |||
|
Description
Scott Shambarger
2024-01-07 21:49:38 UTC
Thank you for the thorough analyses. I will need to refresh memories on the changes in host configuration before going forward but your logic seem sound. Do I understand it correctly, that you have hostname set to a shortname and expect `hostname --fqdn` to look up the domain via DNS reverse lookup? (In reply to Pavel Březina from comment #1) > Do I understand it correctly, that you have hostname set to a shortname and > expect `hostname --fqdn` to look up the domain via DNS reverse lookup? Correct... since the domain may change for each network I put the machine on, I can't just statically set it in /etc/hosts (which would trump the DNS lookup anyway, and appropriate for static domains). The behavior documented (and in the code) for hostname(1) is it uses getaddrinfo(3), and --fqdn then returns the ai_canonname field (which is the "exact copy of the value returned by the name resolution function.") It looks like there is some chicken and egg problem and we are moving myhostname back and forth. See: https://bugzilla.redhat.com/show_bug.cgi?id=2052269 Michael, can you look into it please? Hm, Scott says nss-mdns will never attempt to resolve a hostname that does not end in .local. But if that's true, then why did I report bug #1943199? We had a scramble to move nss-myhostname ahead of nss-mdns4_minimal and I'm pretty sure we would not have done that had it not been to avoid a real problem. However, in bug #1943199 I did not leave any concrete reference pointing to evidence of such a problem. If Scott is right, then it should be safe to move nss-myhostname. I think. Still, I have a strong suspicion that something will break, because it's unlikely that we did bug #1943199 without good reason. So I suppose my position is: it's OK to try this, but we should expect that we'll likely need to revert if it goes wrong. Previously that would have been extremely fragile and inconvenient, because several different packages were updating this line in sed scripts, but now that authselect enforces configuration consistency and only authselect owns this file, it should be much safer to try and see how it goes, right? We can try the change and revert back if it breaks? I would (a) make this change only in rawhide/F40 and not in stable Fedoras, and (b) mail devel.org so people have a heads-up and know to look out for problems. ----------------------------------------------------------------------------------- We all agree that nss-myhostname should ideally move. The goal configuration is surely still this: hosts: files resolve [!UNAVAIL=return] myhostname mdns4_minimal [NOTFOUND=return] dns and that would surely fix `hostname --fqdn`. But we theoretically cannot adopt that configuration because we never properly fixed bug #1867830. That is, although systemd-resolved is supposed to support mDNS resolution, it does not (or did not) work in practice. So nss-mdns4_minimal has to come before nss-resolve. This is strange and confusing; I don't understand why users report that systemd-resolved is unable to handle mDNS. And it looks like we never reported an upstream bug for that, either. Maybe that has been fixed in the past few years? Maybe we should give it another try? At least, we should surely have an upstream bug report. I don't use mDNS, though; it would be helpful if somebody who does could try and see what happens. The current configuration is: hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns The configuration proposed by Scott is: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns which should be OK provided that mdns4_minimal truly does not attempt to resolve the local hostname unless it ends in .local. Created mailing list thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PKWW4EQGBSJO7CLVBHLOF4E56GOUPOTH/ (In reply to Michael Catanzaro from comment #4) > Hm, Scott says nss-mdns will never attempt to resolve a hostname that does > not end in .local. But if that's true, then why did I report bug #1943199? mdns4_minimal is documented to restrict itself to resolving ".local" and "169.254.x.x" (see it's README.md) - my limited testing of it confirms it's doing that...so if it resolves any hostname without .local, that's a bug :) Keeping mdns4_minimal before resolve is, sadly, still necessary as systemd-resolved in "MulticastDNS=resolve" mode acts as a full querier (not as one-shot, RFC6762, 5.1, which IMHO would be better), and therefore binds to port 5353, conflicting with avahi-daemon (see bug #1867830). mDNS is therefore disabled for systemd-resolved in Fedora by default to allow avahi-daemon to work out of the box, with mdns4_minimal providing that piece of the resolver puzzle. > Still, I have a strong suspicion that something will break, because it's > unlikely that we did bug #1943199 without good reason. So I suppose my I agree that the rollout should be on rawhide/F40 to shake out any problems (like mdns4_minimal not behaving correctly), the last thing we want to do is break DNS :D OK, my suggestion is to (a) wait until Monday to see if anybody on devel@ can remember any reason not to do this, then (b) try the configuration proposed by Scott and see how it goes: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns The problem is myhostname plugin always takes over reverse addresses queries, in order to save queries to DNS itself. But that is exactly what we want here. Those problems arise, because myhostname and resolve nss plugins synthetize something themselves, without using network to obtain that information. That is exactly desired here. I have made quick test with avahi-daemon running and nss-mdns installed. # for IP in $(hostname -I); do for H in files myhostname mdns4_minimal resolve dns; do echo $IP, $H:; getent hosts -s $H $IP; done; done 10.0.184.204, files: 10.0.184.204, myhostname: 10.0.184.204 vm-10-0-184-204 10.0.184.204, mdns4_minimal: 10.0.184.204, resolve: 10.0.184.204 vm-10-0-184-204.hosted.upshift.rdu2.redhat.com 10.0.184.204, dns: 10.0.184.204 vm-10-0-184-204.hosted.upshift.rdu2.redhat.com 2620:52:0:bb:f816:3eff:fece:cbd, files: 2620:52:0:bb:f816:3eff:fece:cbd, myhostname: 2620:52:0:bb:f816:3eff:fece:cbd vm-10-0-184-204 fe80::f816:3eff:fece:cbd vm-10-0-184-204 2620:52:0:bb:f816:3eff:fece:cbd, mdns4_minimal: 2620:52:0:bb:f816:3eff:fece:cbd, resolve: 2620:52:0:bb:f816:3eff:fece:cbd vm-10-0-184-204 vm-10-0-184-204.local 2620:52:0:bb:f816:3eff:fece:cbd, dns: 2620:52:0:bb:f816:3eff:fece:cbd vm-10-0-184-204 As you can see, resolve and dns both return correct answers. Not sure why mdns plugin is blamed, it does not have anything to do with it. What breaks the call is myhostname plugin. Because it takes over the address query and does not let it follow to expected resolve or dns plugin. # getent hosts 10.0.184.204
10.0.184.204 vm-10-0-184-204.hosted.upshift.rdu2.redhat.com
# hostname
vm-10-0-184-204
# hostnamectl
Static hostname: vm-10-0-184-204
Icon name: computer-vm
Chassis: vm 🖴
Machine ID: 19d1aa51d8e44d56b5f4c26be6ab8ec0
Boot ID: 83367a9a8d004d97b16b71dbb2bde3c5
Virtualization: kvm
Operating System: Fedora Linux 40 (Rawhide Prerelease)
CPE OS Name: cpe:/o:fedoraproject:fedora:40
OS Support End: Tue 2025-05-13
OS Support Remaining: 1y 3month 1d
Kernel: Linux 6.8.0-0.rc0.20240112git70d201a40823.5.fc40.x86_64
Architecture: x86-64
Hardware Vendor: Red Hat
Hardware Model: OpenStack Compute
Firmware Version: 1.14.0-1.module+el8.4.0+8855+a9e237a9
Firmware Date: Tue 2014-04-01
Firmware Age: 9y 10month 1w 3d
# hostname --fqdn
vm-10-0-184-204
# hostname -A
vm-10-0-184-204.hosted.upshift.rdu2.redhat.com vm-10-0-184-204
# grep hosts: /etc/nsswitch.conf && hostname -A hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns #hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns vm-10-0-184-204 vm-10-0-184-204 # grep hosts: /etc/nsswitch.conf && hostname -A #hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns vm-10-0-184-204.hosted.upshift.rdu2.redhat.com vm-10-0-184-204 The question is what we should ask is, why is myhostname plugin interfering and offering relative alias only. In any case, it seems hostname --fqdn does not work with relative hostnames to get qualified domain. --all-fqdns parameter helps with that, unless myhostname prevents actual reverse lookup over network. # grep hosts: /etc/nsswitch.conf && hostname -A && hostname -f #hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns vm-10-0-184-204.hosted.upshift.rdu2.redhat.com vm-10-0-184-204 vm-10-0-184-204 # grep hosts: /etc/nsswitch.conf && hostname -A && hostname -f hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns #hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns vm-10-0-184-204 vm-10-0-184-204 vm-10-0-184-204 Martin Osvald is hostname maintainer, maybe he can comment what should be preferred variant in this case? It seems to me we may want to query NM for primary connection domain name directly, if there is some. In any case, I would prefer to pass all reverse queries to DNS and maybe use myhostname for reverse lookups as a fallback only if dns and resolve plugins did not offer anything. We don't want DNS to be able to hijack the local hostname, though. So nss-myhostname should always come before nss-dns. I'm still waiting for Osvald's reply, but I will do this change and build today so it gets to Fedora 40 beta release. We will revert/change it if needed. FEDORA-2024-ea70186dec (authselect-1.5.0-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ea70186dec FEDORA-2024-9e4e773ca9 (authselect-1.5.0-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-9e4e773ca9 FEDORA-2024-9e4e773ca9 (authselect-1.5.0-4.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2024-ea70186dec (authselect-1.5.0-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days (In reply to Michael Catanzaro from comment #7) > OK, my suggestion is to (a) wait until Monday to see if anybody on devel@ > can remember any reason not to do this, then (b) try the configuration > proposed by Scott and see how it goes: > > hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] > myhostname dns Looks like this change negatively impacted local host name look-ups when using virtual private networks (or VPNs): https://bugzilla.redhat.com/show_bug.cgi?id=2291062 https://discussion.fedoraproject.org/t/dnf-and-firefox-take-extreemly-long-to-start-when-vpn-active-on-f40/114604/3 So it looks like with current binaries, we can have one or the other. I can revert the change in authselect, but it will just reintroduce this issue. So it would be great if maintainers of resolved and myhostname can sit together and find a solution. One problem with systemd-resolved is it does not try to direct reverse address queries to correct interface servers. Similar to route table, it may want to send VPN directed addresses to VPN servers. But it does no try to do that AFAIK, only forward domain queries are directed correctly. But in case of hostname -f, that is not necessary. For hostname -A it is necessary when myhostname is not used first. But what hostname -f actually does is using all domain and search clauses in /etc/resolv.conf and attempting to do relative hostname query. Search domains are appended in specified order. First positive response terminates search over domains and provides full hostname in command "time getent -s dns ahosts $HOSTNAME" output. A more verbose DNS only search can be archieved by "dig +search $HOSTNAME" command from bind-utils. This makes only sense when there are some search clauses or domain clause in /etc/resolv.conf. For this to be fast, it requires cached responses even for negative responses (no such name or no such record) and also resolution failures (SERVFAILs, including timeout). When even those are cached, myhostname should not be before actual network resolution. Be it resolve or dns nss plugins. Cached response should be used instead. I admit fixed nss plugin order is quite limiting in this case. Maybe we should revert this, but let's discuss in bug #2291062 to keep discussion in one place. I'm reverting this for now, see the discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=2291062#c33 Unfortunately, this breaks hostname -fqdn again, but there are more users affected by the timeout. This is reverted in * rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2024-02a5688338 * F41: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7f0d7c65b * F40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7caacc700 This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42. This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27. Fedora Linux 42 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. |