Open ppc6446 opened 3 years ago
@paususe FMPOV this should get some priority, specially because we are adding Amazon Linux support and (as I documented on the PR for the doc) Amazon Linux does not regenerate the machine-id during the first boot (as I told, to me this looks like a bug on the Amazon Linux AMI, as the AMI for openSUSE 15.2 does regenerate it).
Some ideas, but maybe implementation is not trivial
Please take into account that having same machine id and different minion id is valid usecase when you are renaming a client (e.g. fqdn changed and minion id followed).
I added these lines to my bootstrap so that when a client is registered it has a fresh uuid. Probably a better way to do it, but this was the best solution I could find.
rm -f /etc/machine-id rm -f /var/lib/dbus/machine-id dbus-uuidgen --ensure systemd-machine-id-setup
I can confirm this issue. Seems like there might be another issue related to the official CentOS 7 Generic Cloud images (https://cloud.centos.org/centos/7/images/) where the machine-id being persistent/duplicate on each instance. I think this is affecting AWS and OpenStack instances and very likely other platforms where cloud-init is used.
Adding another System to Uyuni created from the same image seems to partially replace the previous existing System, but some information such as the hostname does not seem to update, only the IP address and salt-minion information gets updated/replaced. I agree that there should be some duplicate machine-id check in the bootstrapping function (with an optional override just in case)
Could this test function be used during the bootstrapping function? I'm not a Java developer and haven't really digged deep into the source code of Uyuni, so I could be looking at the wrong place in the second link.
RegisterMinionActionTest (has a duplicate machine-id check, not used anywhere else though?) https://github.com/uyuni-project/uyuni/blob/master/java/code/src/com/suse/manager/reactor/test/RegisterMinionActionTest.java#L415-L462
AbstractMinionBootstrapper (only checks for duplicate minion ids) https://github.com/uyuni-project/uyuni/blob/master/java/code/src/com/suse/manager/webui/controllers/utils/AbstractMinionBootstrapper.java#L291-L318
@admd What are your thoughts about this one. Currently it is working as designed ( see https://bugzilla.suse.com/show_bug.cgi?id=1183437 ), but I understand the frustration when one forgot to recreate machineid and have server entries overwritten on bootstrap.
Possible duplicate https://github.com/uyuni-project/uyuni/issues/4229
Additional Information
When a system that was cloned from another system or a VM template, /etc/machine_id and various other files can collide with already-registered systems. This can cause behavior such as the original system disappearing from the Uyuni WebUI
Version of Uyuni Server and Proxy (if used)
` Information for package Uyuni-Server-release:
Repository : uyuni-server-stable Name : Uyuni-Server-release Version : 2021.02-116.3.uyuni Arch : x86_64 Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni Support Level : Level 3 Installed Size : 1.4 KiB Installed : Yes Status : up-to-date Source package : Uyuni-Server-release-2021.02-116.3.uyuni.src Summary : Uyuni Server Description : Uyuni lets you efficiently manage physical, virtual, and cloud-based Linux systems. It provides automated and cost-effective configuration and software management, asset management, and system provisioning. `
Details about issue
Creating new versions of the common system identity files would probably be best handled in the customization tools on the platforms doing the cloning, but by default, Uyuni registration should exit with an error when duplicate machine_id, minion_id or other identity files are detected rather than registering a duplicate client.
It may be appropriate to have a checkbox in the WebUI registration and a variable in bootstrap.sh to optionally generate new /etc/machine_id et al files and new salt minion keys.
The identity files involved are listed on this page -
https://www.uyuni-project.org/uyuni-docs/uyuni/administration/tshoot-registerclones.html