SOLVED duplicate hostnames are inseparable
In the web interface, clients that have the same host name have operations applied to all of them. This makes them impossible to separate, ultimately resulting in having to remove all hosts and then re-add them.
For example, I had a box “username1” (referred to as boxA) that I had deployed with FOG. However, after imaging, I realized I needed to use different hardware for this specific user and created a new host (referred to as boxB), with a different MAC, but the same hostname “username1”. Both boxA and boxB imaged correctly and seemed to function fine (e.g. both seemed to grab their respective Windows keys); however, I was unable to change the name of boxA without it also changing the name of boxB, i.e. renaming boxA from “username1” to “undeployed” ended up having both boxA and boxB with username “undeployed”.
I did not do further testing to see what would happen if I changed additional settings on these hosts, but presumably changes would be applied to both.
The only way I found to fix the situation was to delete one host (e.g. boxA) which would result in BOTH hosts being deleted (i.e. boxA and boxB) and then re-adding them with different names.
@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.
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.
@mrayzies I think you’d only have to remove the additional mac, and allow that other host to use it. Thats it.
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.
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 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.
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.
Wayne Workman last edited by
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.
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.
Wayne Workman last edited by Wayne Workman
@mrayzies I’ve reproduced what you’ve described, thank you for giving the steps.
A few questions.
Why are you copying MAC addresses from one registered computer to another?
Are you using USB to Ethernet adapters, or Dock to Ethernet adapters, or trading network cards?
I’m in no way placing any blame, I’m just trying to figure out what’s going on and why you’re using fog the way you are so that we can better understand and maybe figure out how to better support it / fix it.
So I don’t believe this to be the way I originally got in this state, but here are steps to reproduce the end state:
- select host
- copy MAC
- select different host
- paste MAC and click update
Host list will now show duplicate hosts.
Wayne Workman last edited by Wayne Workman
Using Fog 5824 (the cloud number),
When I tried to create a new host using the web interface with a host-name that is already registered, I get an error and it won’t let me proceed.
After deleting one of my computers from the DB, and then trying to do a full registration via the boot menu using a host-name that is already registered, I’m presented with a similar error, saying the host-name is already taken and the registration will not allow me to proceed with that name.
I’m not saying the issue you are experiencing isn’t real - I’m sure you’re having some sort of issue. But I’ve tried to reproduce it and I could not, so could you please describe exactly how to reproduce the issue, or try a later version of FOG?