Add reliable identification of unique client systems

[Sebastian-Roth]

So far FOG used to identify clients via MAC address. Though MACs are pretty much unique all over the world we see more and more people using shared USB NICs to clone systems. This needs addressing.

First we added System UUID as an identifier but those turned out to be pretty much unreliable.

[Sebastian-Roth]

Working towards a way to identify unique client systems reliably we need to combine the information we have. Though I don't think it's wise to add another field to the DB. Better if we just add the logic to the PHP code to use different identifiers - one after the other in case we still get too many results from the DB.

[Sebastian-Roth]

Nevertheless IMHO this means that we have to give up on MAC address being a unique identifier in the DB - which will be a major change. Therefore I started a new branch called unique-identifier to work on this subject.

[astrugatch]

I am running into this exact issue. My work around has been to issue usb NICs to individual machines, but this is just that, a work around. If you need testers for this feature please let me know.

[Sebastian-Roth]

We had a long and intensive discussion on this topic and thought that essentially the hard disk is what makes a client a client from the FOG point of view. So I came up with some code to read HDD serial and WWN from the disk firmware. Adding that code to iPXE turned out to be a dead end as there is no disk driver/subsystem in iPXE yet and it would have been a huge task.

I then decided to go back to what we have, UUID, System Serial Number and Mainboard Serial Number. This should be good enough to uniquely identify most machines. Anyhow it's heaps better than what we have right now.

One big step is done. Added most of the code to identify hosts into the FOG PHP code and the FOS scripts. So this will be ready to test fairly soon.

[Sebastian-Roth]

People might be able to change their system UUID in some cases:
https://forums.mydigitallife.net/threads/bios-tools.529/page-19
https://kb.stonegroup.co.uk/how-to-change-the-dmi-information-a-stone-asus-based-system_357.html
https://kb.stonegroup.co.uk/how-to-change-the-dmi-information-on-a-stone-intel-nuc-system_412.html

[Sebastian-Roth]

We need to keep in mind that the MAC address is also used in other places in FOG, e.g. in /images/dev/<MAC_WITHOUT_COLON> - code ref1. Not sure if we need to change that as well. There should not be a conflict as uploads are not as frequent and parallel as deploys are.

[astrugatch]

I have a shipment of machines that just came in with 3 spares so I can do some testing. I can spin up a new FOG instance with another branch if needed.

[danielbmiller]

A couple of things I have come across inventorying machines where I work (small public university, ~3000 units to date, hodgepodge of manufacturers and system configurations):

• Serial numbers are not universally unique
  Prime examples of this are unset serial number fields (as discussed in the forums) but I have seen small companies that use literal serial numbers to identify their machines.

• Serial numbers are not necessarily unique within a company
  I have run across companies that reuse/recycle serial numbers (Dell and IBM / Lenovo come to mind). Instances have been few and far between and it has been quite a while since I have encountered one, but it is a thing.

Because of these issues, I have had to get things down to a model + serial number arrangement to (mostly) assure a unique identity. For those that don't have programmatically accessible serial numbers I have resorted to manual entry, and for those that just don't have a serial number period, I have been known to create an arbitrary serial numbers and grab a sharpie. Thinking about things, it would probably make sense to start using asset tags for the latter.

With this in mind along with the other issues brought up in the forums, it seems like using all the available information for the static components (what defines a host) might be useful. With this many values in play, programmatically choosing one is an option, or could take them all at once. I'm not very familiar with iPXE, but if a cryptographic hash function is available to the init environment, running a string of those values through that would capture the uniqueness without needing to decide which identifier to use or having to keep track of multiple values. Wouldn't be without it's downsides (troubleshooting and reliably reproducing the identifier in the client come to mind), but could potentially result in more robust identifiers.

Just another spitball to consider.

[astrugatch]

I think danielbmiller is on the right track. A hash of a 2 or more readable fields may be the best move. This way you can get away with one being the same across models without getting the same identifier. MAC address should still NOT be one of the pieces used since this is the item that is no longer consistent on units that ship without ethernet ports.