Bug 1943199

Summary:	nss-myhostname must come before nss-mdns4_minimal in /etc/nsswitch.conf
Product:	[Fedora] Fedora	Reporter:	Michael Catanzaro <mcatanza>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	34	CC:	fedoraproject, filbranden, flepied, kasong, lnykryn, msekleta, robert, ssahani, s, systemd-maint, yuwatana, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-04-04 00:19:18 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 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

https://src.fedoraproject.org/rpms/nss-mdns/pull-request/5

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.