[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
This bug was fixed in the package resolvconf - 1.79ubuntu4.1 --- resolvconf (1.79ubuntu4.1) zesty-proposed; urgency=medium * support reading dns information written by initramfs. (LP: #1711760) -- Scott MoserFri, 08 Dec 2017 14:47:54 -0500 ** Changed in: resolvconf (Ubuntu Zesty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Released Status in resolvconf package in Ubuntu: Won't Fix Status in resolvconf source package in Trusty: Fix Released Status in resolvconf source package in Xenial: Fix Released Status in resolvconf source package in Zesty: Fix Released Bug 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
** Also affects: resolvconf (Ubuntu Zesty) Importance: Undecided Status: New ** Changed in: resolvconf (Ubuntu Zesty) Status: New => Triaged ** Changed in: resolvconf (Ubuntu Zesty) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Released Status in resolvconf package in Ubuntu: Won't Fix Status in resolvconf source package in Trusty: Fix Released Status in resolvconf source package in Xenial: Fix Released Status in resolvconf source package in Zesty: Triaged Bug 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
This bug was fixed in the package resolvconf - 1.69ubuntu1.3 --- resolvconf (1.69ubuntu1.3) trusty-proposed; urgency=medium * Fix bad shell syntax in newly added /lib/resolvconf/net-interface-handler (LP: #1711760) resolvconf (1.69ubuntu1.2) trusty-proposed; urgency=medium * support reading dns information written by initramfs. (LP: #1711760) -- Scott MoserWed, 08 Nov 2017 15:47:00 -0500 ** Changed in: resolvconf (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Released Status in resolvconf package in Ubuntu: Won't Fix Status in resolvconf source package in Trusty: Fix Released Status in resolvconf source package in Xenial: Fix Released Bug 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
** Also affects: resolvconf (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: resolvconf (Ubuntu Trusty) Status: New => Confirmed ** Changed in: resolvconf (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: resolvconf (Ubuntu Trusty) Importance: Medium => High ** Description changed: === 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. + 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
** Changed in: maas Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Released Status in resolvconf package in Ubuntu: Won't Fix Status in resolvconf source package in Xenial: Fix Released Bug 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
This bug was fixed in the package resolvconf - 1.78ubuntu5 --- resolvconf (1.78ubuntu5) xenial; urgency=medium * support reading dns information written by initramfs. (LP: #1711760) -- Scott MoserMon, 23 Oct 2017 12:44:53 -0400 ** Changed in: resolvconf (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Committed Status in resolvconf package in Ubuntu: Won't Fix Status in resolvconf source package in Xenial: Fix Released Bug 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
I updated some state on the tasks. As justification, this fix is in resolvconf, so I dropped cloud-init. I had added it thinking it might need integration, but it did not. Also marked the 'ubuntu' task as "won't fix". The problem did not currently exist in Artful, and the solution provided in resolvconf is not relevant there as resolvconf is not used in Artful. ** No longer affects: cloud-init (Ubuntu) ** No longer affects: cloud-init (Ubuntu Xenial) ** Changed in: resolvconf (Ubuntu Xenial) Status: New => Confirmed ** Changed in: resolvconf (Ubuntu) Status: In Progress => Won't Fix ** Changed in: resolvconf (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Committed Status in resolvconf package in Ubuntu: Won't Fix Status in resolvconf source package in Xenial: Confirmed Bug 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
[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
** Also affects: resolvconf (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1711760 Title: [2.3] resolv.conf is not set (during commissioning or testing) Status in MAAS: Fix Committed Status in cloud-init package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: In Progress Status in cloud-init source package in Xenial: New Status in resolvconf source package in Xenial: New Bug 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