Remove machine-id during image build and exit

[anderbubble]

No description provided.

[Copilot]

Pull Request Overview

This PR ensures that machine-id files are removed during the container build process and that the cleanup script is invoked in each distribution’s Containerfile.

• Added rm -f /etc/machine-id /var/lib/dbus/machine-id to all container_exit.sh scripts
• Updated each Containerfile to run /etc/warewulf/container_exit.sh after copying it

Reviewed Changes

Copilot reviewed 26 out of 26 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tumbleweed/container_exit.sh	added removal of machine-id
tumbleweed/Containerfile	invoke container_exit.sh
rockylinux-9/container_exit.sh	added removal of machine-id
rockylinux-9/Containerfile-vault	invoke container_exit.sh
rockylinux-9/Containerfile-fixed	invoke container_exit.sh
rockylinux-9/Containerfile	invoke container_exit.sh
rockylinux-8/container_exit.sh	added removal of machine-id
rockylinux-8/Containerfile-vault	invoke container_exit.sh
rockylinux-8/Containerfile-fixed	invoke container_exit.sh
rockylinux-8/Containerfile	invoke container_exit.sh
leap/container_exit.sh	added removal of machine-id
leap/Containerfile.15	invoke container_exit.sh
leap/Containerfile	invoke container_exit.sh
examples/rhel-9/container_exit.sh	added removal of machine-id
examples/rhel-9/Containerfile	invoke container_exit.sh
debian/container_exit.sh	added removal of machine-id
debian/Containerfile-12.0	invoke container_exit.sh
debian/Containerfile	invoke container_exit.sh
almalinux-9/container_exit.sh	added removal of machine-id
almalinux-9/Containerfile-vault	invoke container_exit.sh
almalinux-9/Containerfile-fixed	invoke container_exit.sh
almalinux-9/Containerfile	invoke container_exit.sh
almalinux-8/container_exit.sh	added removal of machine-id
almalinux-8/Containerfile-vault	invoke container_exit.sh
almalinux-8/Containerfile-fixed	invoke container_exit.sh
almalinux-8/Containerfile	invoke container_exit.sh

[Copilot]

The script may not have execute permissions after COPY. Consider adding chmod +x /etc/warewulf/container_exit.sh before running it or invoke it explicitly with a shell (sh /etc/warewulf/container_exit.sh).

Suggested change

	RUN /etc/warewulf/container_exit.sh
	RUN chmod +x /etc/warewulf/container_exit.sh \
	&& /etc/warewulf/container_exit.sh

[Copilot]

[nitpick] Consider adding a shebang (e.g., #!/usr/bin/env bash) at the top of this script to ensure it's executed with the intended shell when run directly.

[middelkoopt]

Double check the uninitialized method - otherwise approved.

[middelkoopt]

This is how I do it on Debian/Ubuntu, there was a reason but I don't recall. This should be tested before pushed. Not sure if my Debian/Ubuntu virtual cluster still works.

echo "uninitialized" > /etc/machine-id && \
rm -v /var/lib/dbus/machine-id

[middelkoopt]

Booted a Debian:12.0 node and it worked fine.

[anderbubble]

Here's the guidance from the manpage:

       For operating system images which are created once and used on multiple
       machines, for example for containers or in the cloud, /etc/machine-id
       should be either missing or an empty file in the generic file system
       image (the difference between the two options is described under "First
       Boot Semantics" below). An ID will be generated during boot and saved
       to this file if possible. Having an empty file in place is useful
       because it allows a temporary file to be bind-mounted over the real
       file, in case the image is used read-only.

It sounds like systemd writes "uninitialized" to the file temporarily during first boot, but I haven't found guidance to do it for images. Unless you can find a reason to do it, I recommend we remove it (or put an empty file there) for our images.

[middelkoopt]

I vote remove

[mslacken]

The whole machine-id is looming below the surface for long time and doesn't come to the surface as for nearly all tests we are doing are on virtual machines. There systemd will detect that's it's running on a VM and extract the id from the hypervisor. So the machine id doesn't change between reboots for them,
On physical hardware, it will the same for all nodes, if it's extracted from node image or change every time if it's not defined there.
The only solution is to have in node database* so that we have a full control over it.

[*] And not as a resource as this something which is really important and is uniq for the node, so that the rest api could use it as logical identification.

[anderbubble]

The whole machine-id is looming below the surface for long time and doesn't come to the surface as for nearly all tests we are doing are on virtual machines. There systemd will detect that's it's running on a VM and extract the id from the hypervisor. So the machine id doesn't change between reboots for them, On physical hardware, it will the same for all nodes, if it's extracted from node image or change every time if it's not defined there. The only solution is to have in node database* so that we have a full control over it.

[*] And not as a resource as this something which is really important and is uniq for the node, so that the rest api could use it as logical identification.

@mslacken I don't think we really need to care about this. The only reason it's coming up now is because dracut builds initfs images under a machine-id-based path if it exists, and then warewulfd can't find it.