| 2017-08-18 23:09:42 |
Andres Rodriguez |
bug |
|
|
added bug |
| 2017-08-18 23:09:51 |
Andres Rodriguez |
bug task added |
|
cloud-init (Ubuntu) |
|
| 2017-08-18 23:10:11 |
Andres Rodriguez |
description |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF |
|
| 2017-08-18 23:11:38 |
Andres Rodriguez |
description |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/ |
|
| 2017-08-18 23:12:23 |
Andres Rodriguez |
bug task added |
|
isc-dhcp (Ubuntu) |
|
| 2017-08-18 23:12:45 |
Andres Rodriguez |
bug task deleted |
isc-dhcp (Ubuntu) |
|
|
| 2017-08-18 23:12:49 |
Andres Rodriguez |
maas: milestone |
|
2.3.0 |
|
| 2017-08-18 23:14:08 |
ybaumy |
bug |
|
|
added subscriber ybaumy |
| 2017-08-21 19:26:30 |
Ryan Harper |
cloud-init (Ubuntu): status |
New |
Incomplete |
|
| 2017-08-21 19:32:26 |
Andres Rodriguez |
cloud-init (Ubuntu): status |
Incomplete |
New |
|
| 2017-08-25 16:09:05 |
Lee Trager |
summary |
[2.3] resolv.conf is not set (during commissioning) |
[2.3] resolv.conf is not set (during commissioning or testing) |
|
| 2017-08-26 00:47:58 |
Lee Trager |
attachment added |
|
log.tar.xz https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4938963/+files/log.tar.xz |
|
| 2017-08-28 22:39:46 |
Lee Trager |
attachment added |
|
run.tar.xz https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4940470/+files/run.tar.xz |
|
| 2017-08-29 18:19:59 |
Lee Trager |
maas: importance |
Undecided |
Critical |
|
| 2017-08-29 18:20:05 |
Lee Trager |
maas: status |
New |
Confirmed |
|
| 2017-08-29 18:29:25 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
| 2017-08-29 18:29:28 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-08-31 16:49:56 |
Scott Moser |
description |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/ |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration |
|
| 2017-09-18 15:00:39 |
David Britton |
cloud-init (Ubuntu): importance |
Medium |
High |
|
| 2017-09-20 02:52:33 |
Scott Moser |
bug task added |
|
initramfs-tools (Ubuntu) |
|
| 2017-10-04 01:31:12 |
Scott Moser |
initramfs-tools (Ubuntu): status |
New |
In Progress |
|
| 2017-10-04 01:31:16 |
Scott Moser |
initramfs-tools (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-10-04 01:31:19 |
Scott Moser |
initramfs-tools (Ubuntu): assignee |
|
Scott Moser (smoser) |
|
| 2017-10-04 01:31:44 |
Scott Moser |
attachment added |
|
lp-1711760 script to aid in testing https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4961827/+files/lp-1711760-test |
|
| 2017-10-04 01:34:24 |
Scott Moser |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/resolvconf/+git/resolvconf/+merge/331759 |
|
| 2017-10-04 01:39:22 |
Scott Moser |
bug task deleted |
initramfs-tools (Ubuntu) |
|
|
| 2017-10-04 01:39:33 |
Scott Moser |
bug task added |
|
resolvconf (Ubuntu) |
|
| 2017-10-04 01:39:39 |
Scott Moser |
resolvconf (Ubuntu): status |
New |
In Progress |
|
| 2017-10-04 01:39:41 |
Scott Moser |
resolvconf (Ubuntu): importance |
Undecided |
Medium |
|
| 2017-10-06 18:57:59 |
Andres Rodriguez |
maas: milestone |
2.3.0 |
2.3.0beta2 |
|
| 2017-10-06 19:12:35 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/331968 |
|
| 2017-10-06 19:29:23 |
Andres Rodriguez |
maas: assignee |
|
Andres Rodriguez (andreserl) |
|
| 2017-10-06 19:29:25 |
Andres Rodriguez |
maas: status |
Confirmed |
In Progress |
|
| 2017-10-06 20:36:59 |
MAAS Lander |
maas: status |
In Progress |
Fix Committed |
|
| 2017-10-10 14:57:59 |
Scott Moser |
attachment added |
|
lp-1711760-test.sh: script to aid in testing https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4966752/+files/lp-1711760-test.sh |
|
| 2017-10-10 16:00:09 |
Scott Moser |
description |
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case. MAAS 2.3 uses this for
the installation environment and also the rescue environment.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
b.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
c.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration |
|
| 2017-10-10 16:34:08 |
Scott Moser |
attachment added |
|
lp-1711760-test.sh: script to aid in testing default to proposed https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4966838/+files/lp-1711760-test.sh |
|
| 2017-10-10 16:34:25 |
Scott Moser |
attachment removed |
lp-1711760 script to aid in testing https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4961827/+files/lp-1711760-test |
|
|
| 2017-10-10 16:34:29 |
Scott Moser |
attachment removed |
lp-1711760-test.sh: script to aid in testing https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4966752/+files/lp-1711760-test.sh |
|
|
| 2017-10-11 20:58:10 |
Andres Rodriguez |
maas: status |
Fix Committed |
Fix Released |
|
| 2017-10-17 02:30:55 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/332330 |
|
| 2017-10-17 03:03:18 |
MAAS Lander |
maas: status |
Fix Released |
Fix Committed |
|
| 2017-10-25 12:50:55 |
Chris J Arges |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-10-25 12:50:55 |
Chris J Arges |
bug task added |
|
resolvconf (Ubuntu Xenial) |
|
| 2017-10-25 12:50:55 |
Chris J Arges |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
| 2017-10-25 13:06:19 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case. MAAS 2.3 uses this for
the installation environment and also the rescue environment.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
b.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
c.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case. MAAS 2.3 uses this for
the installation environment and also the rescue environment.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration |
|
| 2017-10-25 13:24:35 |
Scott Moser |
bug task deleted |
cloud-init (Ubuntu) |
|
|
| 2017-10-25 13:24:42 |
Scott Moser |
bug task deleted |
cloud-init (Ubuntu Xenial) |
|
|
| 2017-10-25 13:24:50 |
Scott Moser |
resolvconf (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-10-25 13:24:59 |
Scott Moser |
resolvconf (Ubuntu): status |
In Progress |
Won't Fix |
|
| 2017-10-25 13:25:02 |
Scott Moser |
resolvconf (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2017-10-26 13:35:39 |
Andres Rodriguez |
resolvconf (Ubuntu Xenial): importance |
Medium |
Critical |
|
| 2017-10-26 21:42:35 |
Dean Henrichsmeyer |
bug |
|
|
added subscriber Canonical Field High |
| 2017-10-27 13:16:04 |
Robie Basak |
resolvconf (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2017-10-27 13:16:06 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-10-27 13:16:09 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2017-10-27 13:16:14 |
Robie Basak |
tags |
|
verification-needed verification-needed-xenial |
|
| 2017-10-27 21:05:34 |
Scott Moser |
attachment added |
|
my.log: log of running lp-1711760-test.sh https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4998243/+files/my.log |
|
| 2017-10-27 21:06:23 |
Scott Moser |
attachment added |
|
updated recreate script that supports running in 'control' mode (to show no harm is done) https://bugs.launchpad.net/maas/+bug/1711760/+attachment/4998244/+files/lp-1711760-test.sh |
|
| 2017-10-31 19:55:11 |
Andres Rodriguez |
tags |
verification-needed verification-needed-xenial |
verification-done verification-done-xenial |
|
| 2017-11-06 21:14:35 |
Launchpad Janitor |
resolvconf (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-11-06 21:14:38 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-11-06 22:02:35 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case. MAAS 2.3 uses this for
the installation environment and also the rescue environment.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case. MAAS 2.3 uses this for
the installation environment and also the rescue environment.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1730512: dns does not work in maas ephermer 14.04 system booted with rooturl. |
|
| 2017-11-07 15:25:13 |
Andres Rodriguez |
maas: status |
Fix Committed |
Fix Released |
|
| 2017-11-07 17:55:37 |
Scott Moser |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-11-07 17:55:37 |
Scott Moser |
bug task added |
|
resolvconf (Ubuntu Trusty) |
|
| 2017-11-07 17:55:47 |
Scott Moser |
resolvconf (Ubuntu Trusty): status |
New |
Confirmed |
|
| 2017-11-07 17:55:52 |
Scott Moser |
resolvconf (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2017-11-07 17:56:00 |
Scott Moser |
resolvconf (Ubuntu Trusty): importance |
Medium |
High |
|
| 2017-11-07 17:58:50 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case. MAAS 2.3 uses this for
the installation environment and also the rescue environment.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1730512: dns does not work in maas ephermer 14.04 system booted with rooturl. |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case.
MAAS 2.3 uses this for the installation environment and also the rescue
environment. In most cases the 14.04 specific fix will only apply
to installation as 16.04 is most likely to be used in rescue mode.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
trusty uses 'running-in-container' to determine this.
xenial uses 'systemd-detect-virt'
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1730512: dns does not work in maas ephermer 14.04 system booted with rooturl. |
|
| 2017-11-07 20:15:50 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/resolvconf/+git/resolvconf/+merge/333337 |
|
| 2017-11-07 20:28:31 |
Scott Moser |
attachment added |
|
lp-1711760-test.sh: works for xenial or trusty https://bugs.launchpad.net/maas/+bug/1711760/+attachment/5005575/+files/lp-1711760-test.sh |
|
| 2017-11-08 02:30:50 |
Scott Moser |
resolvconf (Ubuntu Trusty): status |
Confirmed |
In Progress |
|
| 2017-11-08 02:30:54 |
Scott Moser |
resolvconf (Ubuntu Trusty): assignee |
|
Scott Moser (smoser) |
|
| 2017-11-08 02:30:57 |
Scott Moser |
resolvconf (Ubuntu Xenial): assignee |
|
Scott Moser (smoser) |
|
| 2017-11-08 17:10:49 |
Robie Basak |
resolvconf (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-11-08 17:10:53 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-11-08 17:10:56 |
Robie Basak |
tags |
verification-done verification-done-xenial |
verification-done-xenial verification-needed verification-needed-trusty |
|
| 2017-11-08 20:57:00 |
Scott Moser |
tags |
verification-done-xenial verification-needed verification-needed-trusty |
verification-done-xenial verification-failed verification-failed-trusty |
|
| 2017-11-08 21:19:07 |
Scott Moser |
attachment added |
|
one more try at reproduce script. https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760/+attachment/5006069/+files/lp-1711760-test.sh |
|
| 2017-11-09 19:52:43 |
Brian Murray |
tags |
verification-done-xenial verification-failed verification-failed-trusty |
verification-done-xenial verification-needed verification-needed-trusty |
|
| 2017-11-09 23:01:30 |
Scott Moser |
attachment added |
|
final version of recreate script https://bugs.launchpad.net/maas/+bug/1711760/+attachment/5006685/+files/lp-1711760-test.sh |
|
| 2017-11-09 23:02:11 |
Scott Moser |
attachment added |
|
output of running script with comments showing fix. https://bugs.launchpad.net/maas/+bug/1711760/+attachment/5006686/+files/verify-trusty-lp-1711760.txt |
|
| 2017-11-09 23:02:41 |
Scott Moser |
tags |
verification-done-xenial verification-needed verification-needed-trusty |
verification-done verification-done-trusty verification-done-xenial |
|
| 2017-11-10 01:33:48 |
Scott Moser |
attachment removed |
lp-1711760-test.sh: script to aid in testing default to proposed https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760/+attachment/4966838/+files/lp-1711760-test.sh |
|
|
| 2017-11-10 01:33:57 |
Scott Moser |
attachment removed |
updated recreate script that supports running in 'control' mode (to show no harm is done) https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760/+attachment/4998244/+files/lp-1711760-test.sh |
|
|
| 2017-11-10 01:34:04 |
Scott Moser |
attachment removed |
lp-1711760-test.sh: works for xenial or trusty https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760/+attachment/5005575/+files/lp-1711760-test.sh |
|
|
| 2017-11-10 01:34:08 |
Scott Moser |
attachment removed |
one more try at reproduce script. https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760/+attachment/5006069/+files/lp-1711760-test.sh |
|
|
| 2017-11-20 17:11:05 |
Launchpad Janitor |
resolvconf (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2017-11-29 19:11:58 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case.
MAAS 2.3 uses this for the installation environment and also the rescue
environment. In most cases the 14.04 specific fix will only apply
to installation as 16.04 is most likely to be used in rescue mode.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
trusty uses 'running-in-container' to determine this.
xenial uses 'systemd-detect-virt'
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1730512: dns does not work in maas ephermer 14.04 system booted with rooturl. |
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/squashfs' use case.
MAAS 2.3 uses this for the installation environment and also the rescue
environment. In most cases the 14.04 specific fix will only apply
to installation as 16.04 is most likely to be used in rescue mode.
[Test Case]
There are two tests for this.
a.) local/non-MAAS test
Download the test case attached.
Run it and follow the instructions.
Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
without the fix there would be no data in /etc/resolv.conf. With the
fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'
b.) MAAS test.
For the full maas test, you need to build a image stream for maas
with the fix included in the squashfs image and then import that
stream to maas and use the rescue environment and verify dns.
This process is beyond the scope of the SRU template, but is
described partially in
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README
[Regression Potential]
Regression potential should be very low. There are gates in the code
to make sure that this code is inactive other than when it is explicitly
enabled.
net-interface-handler will exit without doing anything unless:
a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
and these files have non-empty values for a variable mentioned above.
(These files are written by the initramfs code when 'ip=' is seen).
b.) this is not a container.
trusty uses 'running-in-container' to determine this.
xenial uses 'systemd-detect-virt'
c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
if open-iscsi has written this file due to open-iscsi root, then it
will handle this functionality. resolvconf will get out of the way.
d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
This lowers the scope of changes in runtime to cases with where either the
new flag is seen or cloud-config-url is passed. The MAAS use case will
contain this flag.
[Other Info]
=== End SRU Template ===
Using MAAS 2.3, during commissioning (and likely in the rest of the ephemeral environment) we have noticed that resolv.conf is not set with the DNS server.
That said, during the commissioning process, MAAS does not send any metadata to cloud-init to configure the network, rather, we expect the image to boot from the network via DHCP. So, cloud-init writes:
ubuntu@manual:~$ 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
# control-manual ens3
iface ens3 inet dhcp
broadcast 192.168.122.255
dns-nameservers 192.168.122.2
gateway 192.168.122.1
netmask 255.255.255.0
Which correctly includes the DNS server. However:
ubuntu@manual:~$ ping google.com
ping: unknown host google.com
If restart the interfacE:
ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
ifdown: interface ens3 not configured
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens3/52:54:00:ea:57:31
Sending on LPF/ens3/52:54:00:ea:57:31
Sending on Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 (xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.
ubuntu@manual:~$ 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
nameserver 192.168.122.2
search maas
ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms
As such, this either seems like a bug in Ubuntu, or caused by cloud-init when writing e/n/i.d/50-cloud-init.cfg
ubuntu@manual:~$ dpkg -l | grep cloud-init
ii cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 all Init scripts for cloud instances
ii cloud-initramfs-copymods 0.27ubuntu1.4 all copy initramfs modules into root filesystem for later use
ii cloud-initramfs-dyn-netconf 0.27ubuntu1.4 all write a network interface file in /run for BOOTIF
ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
http://paste.ubuntu.com/25342740/
Related bugs:
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1730512: dns does not work in maas ephermer 14.04 system booted with rooturl.
* bug 1735225: root=http:.. should automatically enable 'rc-initrd-dns' feature |
|
| 2017-12-08 19:43:43 |
Scott Moser |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-12-08 19:43:43 |
Scott Moser |
bug task added |
|
resolvconf (Ubuntu Zesty) |
|
| 2017-12-08 19:43:55 |
Scott Moser |
resolvconf (Ubuntu Zesty): status |
New |
Triaged |
|
| 2017-12-08 19:43:59 |
Scott Moser |
resolvconf (Ubuntu Zesty): importance |
Undecided |
Medium |
|
| 2017-12-14 21:31:18 |
Brian Murray |
resolvconf (Ubuntu Zesty): status |
Triaged |
Fix Committed |
|
| 2017-12-14 21:31:26 |
Brian Murray |
tags |
verification-done verification-done-trusty verification-done-xenial |
verification-done-trusty verification-done-xenial verification-needed verification-needed-zesty |
|
| 2017-12-15 13:09:29 |
paz |
bug |
|
|
added subscriber paz |
| 2017-12-15 15:47:35 |
Scott Moser |
attachment added |
|
verification log of zesty https://bugs.launchpad.net/maas/+bug/1711760/+attachment/5023065/+files/zesty.log |
|
| 2017-12-15 15:47:57 |
Scott Moser |
tags |
verification-done-trusty verification-done-xenial verification-needed verification-needed-zesty |
verification-done verification-done-trusty verification-done-xenial verification-donezesty |
|
| 2017-12-21 17:04:07 |
Scott Moser |
tags |
verification-done verification-done-trusty verification-done-xenial verification-donezesty |
verification-done verification-done-trusty verification-done-xenial verification-done-zesty |
|
| 2017-12-21 17:04:14 |
Scott Moser |
tags |
verification-done verification-done-trusty verification-done-xenial verification-done-zesty |
verification-done-trusty verification-done-xenial verification-done-zesty |
|
| 2018-01-02 10:59:44 |
Launchpad Janitor |
resolvconf (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
