maas writes in /etc/machine-id for custom boot sources

[Alexander Balderson]

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://askubuntu.com/questions/1126037/netplan-generates-the-same-mac-address-for-bridges-on-two-different-machines for more info.

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-machine-id-setup.service.

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/maas/common/maas/boot-resources/current/ubuntu/amd64/ga-18.04/bionic/stable and /etc/machine-id had a value.

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.

[Lee Trager (ltrager)]

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.

[Ryan Harper (raharper)]

> 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/maas/common/maas/boot-resources/current/ubuntu/amd64/ga-18.04/bionic/stable and /etc/machine-id had a value.

Can you describe (2) in more detail, how are you hosting it, how/where are mounting it?

I'll say the expectation is that the squashfs image booted should *never* have a value in /etc/machine-id.

Curtin does not currently (nor historically) touch /etc/machine-id ; we copy what's written there on boot (which should be unique since it's empty in the squashfs filesystem in the cloud-image case).

So it sounds like something in (2) is causing the squashfs image served by maas to have a value in /etc/machine-id and we need to figure out how that got there.

[Ryan Harper (raharper)]

I'm marking this invalid for curtin; curtin does not manipulate /etc/machine-id and known good images (images.maas.io) deploy with unique machine-ids.

Please re-open if there's new information indicating that curtin should be doing something it's not.

[Lee Trager (ltrager)]

I have verified that the SqaushFS images on images.maas.io contain only a blank /etc/machine-id. I have also deployed 3 different machines and they all have a different /etc/machine-id.

The command to generate images seems correct but we don't support Ubuntu images that do not come from images.maas.io. Please use the documented mirroring process[1].

[1] https://maas.io/docs/snap/2.9/ui/local-image-mirror

[Launchpad Janitor (janitor)]

[Expired for MAAS because there has been no activity for 60 days.]