[Bug 1689410] Re: nplan with networkd + resolvconf without resolved, results in no DNS resolution
Dimitri John Ledkov
launchpad at surgut.co.uk
Tue May 9 14:20:17 UTC 2017
<rharper> slangasek: xnox: re DNS for netplan/networkd ; on xenial , there is a unit watch placed on /run/systemd/netif/state which will trigger a call to systemd-network-resolvconf-update.service, which exec's some shell code to extract any DNS values from networkd state and the respective interfaces and invokes resolvconf program ;
<xnox> rharper, hm, that's what i was thinking should be happening.... I did not notice such watch. Where is it exactly, and does one have to activate it manually?
* xnox commented to the same effect on the bug i filed, that it seemed to me that networkd <-> resolvconf integration was non existant.
<rharper> you do not have to activate it manually; /lib/systemd/system/resovlconf.service.wants/systemd-networkd-resolvconf-update.path is the trigger for /lib/systemd/system/systemd-networkd-resolconf-update.service
<xnox> ./resolvconf.service.wants/systemd-networkd-resolvconf-update.path
<rharper> xnox: you probably want to add a symlink to /lib/systemd/system/systemd-networkd-wait-online.service in /etc/systemd/system/network-online.target.wants
<rharper> which bug?
<xnox> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1689410
<mup> Bug #1689410: nplan with networkd + resolvconf without resolved, results in no DNS resolution <xenial> <ifupdown (Ubuntu):New> <nplan (Ubuntu):New> <resolvconf (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1689410>
<xnox> 30 seconds is a long time to get DNS settings right
<xnox> for some reason, my /run/systemd/netif/state had DNS, yet i did not have namespace resolution =(
<xnox> but i may have stopped resolvconf =(
<xnox> and hence ConditionPathExists=/run/resolvconf/enable-updates was not satisfied.
<xnox> thus a bug in my image.
<rharper> I can look at the bug, but it doesn't take 30 seconds when things are configured properly or things like network via cloud-init early would fail to resolve the snappy store, etc;
<xnox> yeah, things did fail to resolve snappy store, ubuntu ntp, etc.
<xnox> the bug is not very descriptive.
<rharper> right, I think if you add the systemd-networkd-wait-online link to the network-online.target.wants
<rharper> that should ensure it runs at the right time.
<xnox> nplan does that out of the box.
<rharper> only if 1) you have yaml in /etc/netplan/
<rharper> cloud-init invokes netplan generate
<xnox> but on first boot we are doing it half way during the boot (as cloud-init is running) thus it may not be part of the initial transaction.
<rharper> but since that's not called by a systemd-generator, it does not add the link
<xnox> .... cloud-init generates yaml into /etc/netplan.
<xnox> (when i force network generator to netplan, as I have in my xenial image, when experimenting to use nplan by default for this cloud)
<rharper> it does create the yaml and call generate, but it's not sufficient to create the symlink IIRC due to the code in netplan which doesn't generate the symlinks in /run if it;s not invoked as a genartor
<xnox> (via cloud.cfg.d)
<xnox> ah, fun.
<rharper> no
<rharper> this was not fun in any sense of the words
<rharper> I've picked this apart too many times; we've got the set of changes needed documented and staged for ubuntu-core
<xnox> so i had symlinks in originally; then i removed them, because i noticed that nplan generates them; but did not realise that it's /sometimes/ generates, rather than always.
<rharper> so this isn't new ground
<rharper> but it's not landed in xenial for cloud-init proper due to not wanting to foist networkd onto xenial users at this time
<rharper> (well, not new to me at least)
<xnox> right.
<xnox> based on the above, i think i need to do a retest of my nplan based cloud image.
** Changed in: resolvconf (Ubuntu)
Status: New => Incomplete
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Dimitri John Ledkov (xnox)
** Changed in: nplan (Ubuntu)
Status: New => Incomplete
** Changed in: nplan (Ubuntu)
Status: Incomplete => Invalid
** Changed in: ifupdown (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1689410
Title:
nplan with networkd + resolvconf without resolved, results in no DNS
resolution
Status in ifupdown package in Ubuntu:
Invalid
Status in nplan package in Ubuntu:
Invalid
Status in resolvconf package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Incomplete
Bug description:
if nplan yaml specifies nameservers which are passed onto networkd,
they will never take effect on systems that do not use systemd-
resolved.
This is because there is no integration between nplan and resolvconf,
either directly; via networkd; via NetworkManager.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1689410/+subscriptions
More information about the foundations-bugs
mailing list