duplicate hostnames are inseparable

[mrayzies]

@Wayne-Workman

As I said, I’m like 99.9% certain that this was not how I originally got into this situation; however, I have been unable to get back to it in some sane way.

I agree that copying MAC addresses is strange and it is not something I would do otherwise.

If I figure out how I got to this in a sane way, I will let you know.

[mrayzies]

As a side affect of this, the original host names of the machines that become duplicates remain registered in the database. Thus even though they don’t show up in the web interface, you can’t reuse those hostnames unless you delete from the database.

[Wayne Workman]

@mrayzies said:

As a side affect of this, the original host names of the machines that become duplicates remain registered in the database. Thus even though they don’t show up in the web interface, you can’t reuse those hostnames unless you delete from the database.

@Developers

[mrayzies]

With the help of a co-worker, I figured out a reasonable way to get into this situation!

Imagine you have “host1” with MAC address “de:ad:be:ef:00:01” in FOG. You queue up the task but the host never downloads it. When you examine it, you notice that host claims it is unregistered and after just a little bit of poking, you realize that some yahoo labeled it incorrectly and the MAC address is actually “de:ad:be:ef:00:02”. You hop back into the web interface, pull up “host1” and edit the MAC address to the correct value. However, once you save after having done that, you will end up with 2 host1’s: one will have the correct MAC, one will have the incorrect MAC. From then on operations (like delete) will get applied to both of them (as I noted above).

I don’t think you would run into this issue if you tried to register from the FOG client because it would inform you at that time the hostname you wanted was already in use. But I am not 100% sure on this.

[Tom Elliott]

@mrayzies I’ve added some code in an attempt to ensure mac’s can’t just be stolen. Only problem is if you edit the mac, it wouldn’t create two host1’s, rather 2 primary macs associated to host1. However, editing shouldn’t create a second primary, it should remove the old and/or move it to an additional.

I don’t know what the right course of action would be though, and could use some input on how you (the community) would prefer to see it.

[Tom Elliott]

Made an executive decision and have the old primary mac (if changed) become and additional mac. This is because I don’t like the idea of relying on a “primary” mac, and none of stuff really care if it is primary or not. There’s just too much code that uses it for validation and I don’t want to try, for now, to rewrite it all. The stuff that relies on it is display (GUI) stuff, and the host validation. Validation is simple, but all the other stuff is way too much I think.

[mrayzies]

If I have read your response correctly, editing the primary MAC will now result in that newly entered MAC ending up as an additional MAC for the same host?

While that prevents the duplicate host issue which is my primary concern; it is still not ideal as that means I will have to manually delete the host and re-add to fix the issue. This is not the end of the world and if the cost to changing this behavior is as high as you say, then I’ll live with it.

[Tom Elliott]

@mrayzies I think you’d only have to remove the additional mac, and allow that other host to use it. Thats it.

[mrayzies]

@Tom-Elliott

I must have misunderstood your response – I thought you were saying the original MAC would still be the primary MAC of the host ?

If the original MAC becomes an additional MAC, then yes, just removing it and creating a new host is simple and a fine solution.

[Tom Elliott]

@mrayzies THat’s exactly what it is. If you update a host’s primary mac, the update is the primary, and the original primary becomes an additional mac.