On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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/bb79fb73875f8e71841a1ee8e...
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. :)