Bug #4490
closedNon-unique machine UUID mess up collected inventory
Description
I have run into issue today when adding a new machine into Rudder unexpectedly modified another already present machine.
To make the long story short, I've tracked it down to the MACHINEID being the same for two hosts.
I have run the command below to see if I have any more problems:
# grep MACHINEID *| sed 's@^.*<MACHINEID>\(.*\)</MACHINEID>@\1@'| sort | uniq -c 1 00000000-0000-0000-0000-0025906CFD30 2 00020003-0004-0005-0006-000700080009 1 080020FF-FFFF-FFFF-FFFF-466D3D282100 1 080020FF-FFFF-FFFF-FFFF-AA7D8D4F1400 1 080020FF-FFFF-FFFF-FFFF-BE82A5282100 1 17079865-5D68-3894-B0C4-019B018772E0 1 34303732-3334-5553-4D37-313830344D54 1 34313431-3039-5553-4537-34314E35475A 1 34313830-3434-4D58-3237-323730303155 1 44454C4C-3200-1038-8044-C6C04F594631 1 44454C4C-3600-1044-8030-B8C04F383731 1 44454C4C-3800-1058-8059-B8C04F533731 1 44454C4C-4800-1046-8043-C6C04F594631 1 44454C4C-4A00-1052-8034-C8C04F594631 1 44454C4C-4A00-1052-8034-CAC04F594631 1 44454C4C-4B00-1052-8034-B1C04F594631 1 44454C4C-4B00-1052-8034-B2C04F594631 1 44454C4C-4B00-1052-8034-B3C04F594631 1 44454C4C-4B00-1052-8034-B4C04F594631 1 44454C4C-5200-105A-8036-B6C04F594631 1 48384441-3852-0030-4860-003048605394 1 4C4C4544-0032-3810-8048-B1C04F585131 1 4C4C4544-0032-4210-8044-B1C04F585131 1 4C4C4544-0052-4810-8032-B4C04F514C31 1 4EBA5B8C-271D-3308-B60B-D45681B13811 1 53D19F64-D663-A017-8922-0030487E057E 1 53D19F64-D663-A017-8922-0030487E0582 1 53D19F64-D663-A017-8922-0030487E0AF0 1 53D19F64-D663-A017-8922-0030487E0AF2 1 53D19F64-D663-A017-8922-0030487E0AF4 1 53D19F64-D663-A017-8922-0030487E0AF6 1 53D19F64-D663-A017-8922-0030487E22C4 1 53D19F64-D663-A017-8922-0030487E22C6 1 53D19F64-D663-A017-8922-0030487E22CA 1 564D637E-F530-2F47-F1CC-57816DE0977E 2 /dev/mem: Operation not permitted 1 Not Present 1 Not Settable
As you can see, the UUID 00020003-0004-0005-0006-000700080009 is found twice. And indeed, dmidecode -s system-uuid generates the same value on two hosts (Supermicro servers). This problem is not new, see
- https://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg06484.html
- http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006250
- https://pthree.org/2012/06/15/libvirt-tyan-motherboards-and-uuid/
I have currently 40 hosts loaded and 39 entries in LDAP - so for the last three outstanders at the end rudder was able to automatically generate a new UUID for the cases when UUID is really missing.
I think the UUID should be checked for uniqueness at the time the new inventory is about to be accepted, and the user should be warned or given a choice to either use the old entry (can't imagine what would be the reason for this) or generate a new random one (or if there is a way to ensure that this is indeed a new host do this automatically).
My understanding is that the new value then should somehow persist with the host data, so processing inventory updates would find a proper entry automatically.