|Summary:||nss-myhostname must come before nss-mdns4_minimal in /etc/nsswitch.conf|
|Product:||[Fedora] Fedora||Reporter:||Michael Catanzaro <mcatanza>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||34||CC:||fedoraproject, filbranden, flepied, kasong, lnykryn, msekleta, robert, ssahani, s, systemd-maint, yuwatana, zbyszek|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2021-04-04 00:19:18 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Michael Catanzaro 2021-03-25 14:53:29 UTC
We should reorder our NSS hosts configuration in /etc/nsswitch.conf. Our ideal configuration would look like this: hosts: files resolve [!UNAVAIL=return] myhostname mdns4_minimal [NOTFOUND=return] dns because nss-resolve is designed to obsolete both nss-myhostname and nss-mdns4_minimal, so they should ideally only be used if systemd-resolved is not running. But we cannot actually do that due to bug #1867830, which we never solved properly. Instead, we currently have this, with nss-mdns4_minimal ahead of nss-resolve in order to keep mDNS working: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns But this is not good because it results in attempting to resolve the local hostname via mDNS. Instead, as long as we have to keep nss-mdns4_minimal ahead of nss-resolve, we should have moved nss-myhostname as well: hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns This mistake is sad because our configuration is a fragile mess of RPM scriplets. We need to fix scriptlets in our systemd and avahi packaging. We need to ensure the scriptlets can nicely handle upgrades from the previous configuration. Finally, we need to fix authselect upstream. This is all a huge pain. The only thing we don't need to do is edit the glibc package's nsswitch.conf, because I believe it is unused in practice since authselect clobbers it. WARNING WARNING WARNING: our /etc/nsswitch.conf is managed by authselect. Do not edit it directly. Instead, edit /etc/authselect/user-nsswitch.conf as root and then run 'sudo authselect apply changes'.
Comment 1 Zbigniew Jędrzejewski-Szmek 2021-03-26 18:30:40 UTC
https://src.fedoraproject.org/rpms/systemd/c/310b8e6c9508c4f35f24c50b3dde8d463e1321ed I tested a few scenarios, and it seems to work fine, but I didn't build it yet.
Comment 2 Michael Catanzaro 2021-03-26 19:25:05 UTC
Thanks! Do we want to change authselect too? Or just ignore it and say that the systemd packaging now owns this line? Finally, I found in the nss-mdns packaging: https://src.fedoraproject.org/rpms/nss-mdns/c/85219c1c7443ed50fbaed11546b7e33772a71390?branch=rawhide There you actually predicted that we really wanted hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns, and we just failed to implement it that way unfortunately. :( I guess no changes are required there?
Comment 3 Zbigniew Jędrzejewski-Szmek 2021-03-26 19:30:45 UTC
Thanks for digging up the refs. > authselect Dunno. If we can get away with ignoring it, I'd do that. > Finally, I found in the nss-mdns packaging: https://src.fedoraproject.org/rpms/nss-mdns/c/85219c1c7443ed50fbaed11546b7e33772a71390?branch=rawhide Seems it needs adjusting too: $ grep hosts /var/tmp/img2/etc/nsswitch.conf hosts: files myhostname resolve [!UNAVAIL=return] dns $ sed ' /^hosts:/ !b /\<mdns\(4\|6\)\?\(_minimal\)\?\>/ b s/\<files\([[:blank:]]\+\)/files\1mdns4_minimal [NOTFOUND=return] /g ' /var/tmp/img2/etc/nsswitch.conf|grep hosts hosts: files mdns4_minimal [NOTFOUND=return] myhostname resolve [!UNAVAIL=return] dns I'll submit a PR.
Comment 4 Zbigniew Jędrzejewski-Szmek 2021-03-26 19:43:03 UTC
Comment 5 Michael Catanzaro 2021-03-26 20:14:39 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > Dunno. If we can get away with ignoring it, I'd do that. It doesn't know about nss-mdns4_minimal at all. Our scriptlets are going to clobber whatever it has by default. So yeah, I think we can ignore it. That said, it's a bit sad to have configuration in authselect (and glibc itself!) that doesn't really get used due to our scriptlet massaging, but I suppose that's just how it is.
Comment 6 Fedora Update System 2021-03-31 09:16:00 UTC
FEDORA-2021-8595b30af3 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8595b30af3
Comment 7 Fedora Update System 2021-04-01 02:04:08 UTC
FEDORA-2021-8595b30af3 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8595b30af3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8595b30af3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 8 Fedora Update System 2021-04-02 00:02:39 UTC
FEDORA-2021-242ee39890 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-242ee39890
Comment 9 Fedora Update System 2021-04-02 01:35:32 UTC
FEDORA-2021-242ee39890 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-242ee39890` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-242ee39890 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 10 Fedora Update System 2021-04-03 01:28:16 UTC
FEDORA-2021-8595b30af3 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Comment 11 Fedora Update System 2021-04-04 00:19:18 UTC
FEDORA-2021-242ee39890 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.