yahoo-eng-team team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

There are at least 3 ways to fix this:
a.) lxd templates can write /etc/hostname as they write /var/lib/cloud/data/seed/nocloud/meta-data
    then, when the system does a dhcp on its first boot, it will have the /etc/hostname that lxd thinks it should

b.) cloud-init can read the hostname from meta-data and set it before the dhcp.
   This is only really possible recently in cloud-init, but it is now possible.

c.) lxd can control dnsmasq better

'a' and 'b' have the requirement that they container continue to behave,
and if a container changes its /etc/hostname and dhcps again, it will
then possibly have a new hostname.  Basically, that puts the container
in charge of declaring its hostname that will appear in dns.  That
brittle .  The failure you see here is fallout of that system being
brittle.

if LXD says a system's name is 'cloudy-weather' and something in the
container writes 'sunny-day' to /etc/hostname, a subsequent reboot would
apparently change the dns entry for that system.  Essentially, you're
allowing a api by which a container can change its desired hostname by
metadata in a dhcp request.  That seems an odd api at best.

It also means that if another system was already named 'sunny-day', then
you have a collision and a misbehaving system can actually do some harm.

In my head, ultimately the only fix is 'c'.

either 'a' or 'b' will improve the situation, but not fix it.

** Also affects: cloud-init
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1600766

Title:
  initial dhcp has default hostname of ubuntu

Status in cloud-init:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  When using the normal lxd-bridge, using a dnsmasq instance for dhcp,
  the initial dhcp is always the hostname 'ubuntu', and this is recorded
  in the dnsmasq's dhcp leases file.

  Presumably the dhcp is done before the container's hostname is set. A
  restart or dhcp renew seems to put the correct container name in the
  leases file.

  This is a problem when using the dnsmasq for local dns resolving for
  *.lxd, which is the standard way of doing host dns for containers, as
  new containers are not dns addressable without a restart or renew.

  Is there anyway get the correct hostname in the initial dhcp? Or maybe
  renew after setting the hostname?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1600766/+subscriptions