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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1600766
Title:
initial dhcp has default hostname of ubuntu
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1600766/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
