-
Notifications
You must be signed in to change notification settings - Fork 829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloud-init update renders secondary addresses to be incompatible with standard tools #2842
Comments
Launchpad user Ryan Harper(raharper) wrote on 2017-03-23T21:54:32.954982+00:00 The network config in the previous bug used DHCP on v4 and v6; it appears this instance has a different network config injected. Can you attach the network configuration? As a workaround, you can include a nameserver configuration
Or also include the dns-nameservers attribute in the second subnet configuration. This will render dns-nameservers entry under lo Given the above config, it looks like the ifupdown resolveconf hooks are not multi-iface-stanza aware. |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-23T22:27:18.460358+00:00 The following is the network_config: That was extracted from /var/lib/cloud/obj.pkl. |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-24T17:29:33.828255+00:00 Changing the cloud-metadata won't work in this case, since the the code for the DigitalOcean metadata source is assigning the Nameservers to the primary interface. Also, adding the DNS resolvers to the loopback interfaces doesn't work because the loopback interface is already up before the definition is added. |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-25T04:11:03.062777+00:00 Patch submitted to Cloud-init via: |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-26T04:02:22.452809+00:00 The patch in comment #4 moves the revolvers to the loopback interface; resolve conf picks it up. |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-27T17:56:03.196354+00:00 I would like to nominate this bug for the Xenial, Yakkety and Zesty branches as well. |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-27T21:40:14.809199+00:00 So while my patch for the DigitalOcean datasource fixes this usecase, the rendering of additional addresses actually breaks all the "if*" tools for secondary addresses and even IPv6. Consider: root@utl-ubuntu-16-04-x64-50307: |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-27T21:42:07.799594+00:00 Additionally, "ifconfig" no longer shows secondary addresses. Notice that root@utl-ubuntu-16-04-x64-50307:~# ifconfig eth0 |
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-28T15:07:36.476197+00:00 I've withdrawn my PR for the DigitalOcean specific fix after an offline conversation. |
This bug was originally filed in Launchpad as LP: #1675571
Launchpad details
Launchpad user Ben Howard(darkmuggle-deactivatedaccount) wrote on 2017-03-23T21:38:47.277484+00:00
The change of how cloud-init renders /etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as expected:
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
This file is generated from information provided by
the datasource. Changes to it will not persist across an instance.
To disable cloud-init's network configuration capabilities, write a file
/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
network: {config: disabled}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet. The second definition of eth0 has no nameserver and therefore overrides the definition.
The text was updated successfully, but these errors were encountered: