maas writes in /etc/machine-id for custom boot sources
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Expired
|
Undecided
|
Unassigned | ||
curtin |
Invalid
|
Undecided
|
Unassigned |
Bug Description
When maas syncs images from a custom source; it does something while importing the image resulting in /etc/machine-id getting a written in value. This results in all machines of the same distro to have the same machine-id. One reason why this is a problem is that Bionic uses /etc/machine-id as the seed when generating mac addresses for bridges. If there are two or more machines with similar configuration and similar bridging; those bridges end up with the same mac address. See https:/
Steps to reproduce:
Originally this was done with maas 2.8 deb, but was also tested with maas 2.9 snap. The tests were done mostly on a bionic VM but were also tested on a focal maas host.
1) am image was built using the maas-image-builder, the script/commands to do so are attached. The image can be mounted and it can be seem that /etc/machine-id is empty on the built squashfs. This is the correct behavior as seen by the manpage of systemd-
2) host the images somewhere, and point a maas to use that image source. Sync the images. Once the images have been synced, mounting the squashfs at /var/snap/
From here, when deploying machines with maas, or workloads with juju, interfaces and bridges created in /etc/netplan (on Bionic) result in the same mac address on multiple systems.
Similarly syncing images from the stable image repo, and mounting the same squashfs shows that /etc/machine-id is empty.
It seems like the correct behavior is to not set the machine-id in /etc/machine-id. It's possible that a command maas is running to prepare the image is running systemd-firstboot or something else which configures the machine-id. It could be while maas is trying to determine the OS type of the image.
This came up while testing cloud-init proposed. Generally we want to test large complicated workloads deployed via juju and maas, however the duplicate machine ID blocked us from being able to test Bionic workloads because adding bridges in /etc/netplan resulted in all the systems getting the same mac address.
lp:maas-images imports all Ubuntu SquashFS images from cloud-images. ubuntu. com. It does not change that image at all, the hashes for SquashFS match between cloud-images. ubuntu. com and images.maas.io.
On deployment MAAS boots the machine into the ephemeral environment. That is the version of Ubuntu you wish to deploy. Curtin performs the actual installation and it simply copies the root filesystem already in memory which is the mounted SquashFS image.
If /etc/machine-id needs to be updated Curtin is what should be doing it.