Whether or not /e/n/i supports something correctly or just happens to
work by sheer luck has no bearing on what is technically correct and
sensical -- let's abstract this, what we need to concern ourselves with
here is netplan, cloud-init and maas.

In the network world, it is absolutely true that DNS nameservers only
make sense on a per-interface basis: nothing guarantees that a
"globally-set" nameserver of 8.8.8.8 is reachable through all
interfaces. It just happens to be that way on 99% of systems because
they only connect to one network, through one interface.

So, in light of the nameserver setting in MaaS under Settings being
unspecified, there's /no other way/ but to either set the nameserver
globally or try to guess the right interface (either by which is
connected to MaaS, or which gets the default gateway, or which matches
subnets). None of the detection options I could come up with strike me
as particularly solid and foolproof.

Next steps for netplan strike me as being to add support for global
nameservers even if it's silly; we shouldn't expect users to have to
have the level of knowledge of networking to know to set it up on a
particular interface when it will work correctly as "global" for 99% of
cases.

In MaaS, my opinion is that every effort should be taken to allow
network administrators to set things up correctly -- nothing guarantees
that the systems deployed will remain accessible to MaaS, or that it
will be their main interface to the network. Only allowing global DNS is
brittle at best, and breaks at least what *I* have been taught were best
practices, to have a separate "public" network from the authenticated
"private" side where monitoring and/or deployment happens. Maybe I'm
just the one who's particular in doing this.

I'm not sure what next steps are for cloud-init -- given a valid
configuration, I assumed it should just pass it through to netplan if
it's v2.

I'll take care of the "global DNS" implementation in netplan.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  ------

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # 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}
  network:
      version: 2
      ethernets:
          enp0s25:
              match:
                  macaddress: b8:ae:ed:7d:17:d2
              mtu: 1500
              nameservers:
                  addresses:
                  - 10.90.90.1
                  search:
                  - maaslab
                  - maas
              set-name: enp0s25
      bridges:
          br0:
              addresses:
              - 10.90.90.3/24
              gateway4: 10.90.90.1
              interfaces:
              - enp0s25
              parameters:
                  forward-delay: 15
                  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =============================
  Xenial
  ==============================

  ubuntu@node05:~$ 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
      dns-nameservers 10.90.90.1
      dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
      address 10.90.90.162/24
      gateway 10.90.90.1
      mtu 1500
  ubuntu@node05:~$ 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 10.90.90.1
  search maaslab maas

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750884/+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