I've verified zesty with the script that is attached.
Output is shown here.


** Attachment added: "verification log of zesty"
   
https://bugs.launchpad.net/maas/+bug/1711760/+attachment/5023065/+files/zesty.log

** Tags removed: verification-needed verification-needed-zesty
** Tags added: verification-done verification-donezesty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
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 Committed

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 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1711760/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to