[Bug 1745463] Re: Disabling systemd-resolved breaks dhclient resolvconf integration
Dimitri John Ledkov
launchpad at surgut.co.uk
Wed Apr 11 16:26:24 UTC 2018
May I backtrack a bit, and ask how is this system configured? And is it
a desktop or a server configuration? Is it a fresh install or an
upgrade?
Specifically, what I am confused about is how the networking is
configured and where /etc/resolv.conf is pointing at.
I see that NetworkManager and ifupdown were mentioned. Do you have both
of these configured and try to manage a) networking b) /etc/resolv.conf?
And what are the steps to reproduce this? Ideally with something simple
and reproducible like a lxd container launched with $ lxd launch ubuntu-
daily:artful test-container
Note that overriding make_resolv_conf() is a good thing, and it should
not at all be used. None of our network configuration tools rely on
make_resolv_conf() which is an extremely bad interface that writes out a
static file and looses information, as it assumes that there is only
ever one interface and one dhcp. Hence you will notice that everything
(networkd+resolved, ifupdown+resolvconf, networkmanager) overridee
make_resolv_conf.
I'm not quite sure what was done to your system, but resolvconf can be
used to managed the /etc/resolv.conf and that is integrated with
resolved. You will notice that resolved stub nameserver is pulled into
resolvconf config, and thus resolvconf can own /etc/resolv.conf which is
what happens on upgrades.
Please update the bug description on how to reproduce the problem you
are seeing, without ranting or jumping to conclusions, or trying to make
any unnecessary changes, because it is hard to understand what you are
trying to achieve, which may have been made worse with unnecessary
workarounds.
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Changed in: resolvconf (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1745463
Title:
Disabling systemd-resolved breaks dhclient resolvconf integration
Status in resolvconf package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Invalid
Bug description:
To reproduce, mask resolved:
sudo systemctl mask systemd-resolved.service
...then disable network-manager for ifupdown interfaces:
$cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
dns=default
rc-manager=resolvconf
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no
...and reboot.
You'll note that resolvconf integration with dhclient is now broken.
Interfaces listed in /etc/network/interfaces or
/etc/network/interfaces.d/* will not provide DNS configuration in
/etc/resolv.conf and /run/resolvconf/interfaces/.
This is because /etc/dhcp/dhclient-enter-hooks.d/resolvconf defines
"make_resolv_conf()" as a valid function for the BOUND case, but
/etc/dhcp/dhclient-enter-hooks.d/resolved undefines it (who's nasty
now, eh?) even though resolved is masked.
The file existence check in the beginning of /etc/dhcp/dhclient-enter-
hooks.d/resolved should be more thorough, i.e. it should ensure that
resolved is enabled, rather than simply look for the existence of
/lib/systemd/systemd-resolved. This works for me:
-if [ -x /lib/systemd/systemd-resolved ] ; then
+if [ -x /lib/systemd/systemd-resolved ] && systemctl -q is-enabled systemd-resolved ; then
Arguably, /etc/dhcp/dhclient-enter-hooks.d/resolvconf should implement
a similar check, looking for /run/resolvconf/enable-updates as a
condition for meddling with DNS settings. If desired, I'll file a
separate bug for that package.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1745463/+subscriptions
More information about the foundations-bugs
mailing list