On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I guess the lesson here is the nsswitch.conf change should be clarified in the proposal.
OK, I've just added it at the end of this part here:
"systemd-libs currently has [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede5... a %post scriplet] to enable nss-myhostname and nss-systemd by either (a) modifying authselect's user-nsswitch.conf template, if authselect is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We will work with the systemd maintainers to enable nss-resolve here as well by adding `resolve [!UNAVAIL=return]` to the hosts line."
Then the instructions in the change proposal for disabling systemd-resolved say:
"Modify /etc/authselect/user-nsswitch.conf and remove resolve [!UNAVAIL=return] from the hosts line. Run authselect apply-changes. (If you have disabled authselect, then edit /etc/nsswitch.conf directly.)"
I guess I should delete that from the proposal, since it's not needed?
I'm not sure what the best path option here is. The path of least resistance would be to simply leave /etc/resolv.conf out of this change. nss-resolve doesn't care, and the effect is only on things which don't use the nss stack, or read /etc/resolv.conf for other purposes.
NetworkManager only enables its systemd-resolved backend if /etc/resolv.conf is symlinked appropriately. So that needs to happen.
I didn't consider cases where systemd is not running because Fedora hasn't supported booting without systemd in about a decade. But I guess the problem here is for containers where systemd is not running inside the container, but is running on the host system? I hadn't considered this scenario. What do Ubuntu containers do? I guess those are not all broken. :)