Not a big deal but this could come up at some point

  1. last year

    When you image macbook air's you need to use a lightning bolt to Ethernet adapter as they do not have Ethernet ports. That being said, Clonedeploy looks at the hardware address of the Ethernet adapater as the primary MAC address. So I would imagine in bulk this could cause an issue with the client list within Clonedeploy having duplicate mac addresses for different clients? Maybe there is a way por it to pull the airport mac address instead as that is unique?

    I dropped this for a bit, but came back to it in the last few days. I finally fixed the issue with MacBook Airs. This fix assumes that all devices have a Wi-Fi network port. I feel this is a pretty safe assumption in 2017 even with older Apple devices. This also assumes that identifying a device by Wi-Fi mac address as opposed to ethernet mac address does not adversely effect how CloneDeploy treats the device.

    I checked to see that the osx_task_list script looks at all mac addresses on a given device before determining if a task has been assigned to that device. Since this is the case CloneDeploy should check for active tasks for Wi-Fi as well as ethernet which means that it should not matter which mac is the primary identifier.

    Next I went back to the osx_register script and changed the entry in line 9 to

    mac=$(networksetup -listallhardwareports | grep -A 3 "Wi-Fi" | grep "Ethernet Address:" | cut -d " " -f 3)

    This will now choose the Wi-Fi network port as the primary mac address when registering a new device. So far in testing it has worked properly.

  2. clonedeploy

    21 Nov 2016 Administrator

    Yes, this also true for many pc's now that don't come with onboard nic's. This is definitely something that needs addressed and I am still deciding on the best way to handle this. Thanks for the feedback.

  3. I think I've figured out a way to deal with this issue: If my intuition is correct this information is pulled into CloneDeploy using the osx_register script. If you changed the mac entry from

    networksetup -listallhardwareports | grep "Ethernet Address:" | cut -d " " -f 3 | head -n1

    to

    ifconfig | grep ether | cut -c 8-24 | head -n1

    That way it would always pull en0 which is the ethernet port on any device with one and it's the wi-fi address on devices that do not have an ethernet port (MacBook Airs). I'm going to try and edit that line to see if this helps with our (I work with striderida1) environment.

  4. clonedeploy

    29 Dec 2016 Administrator

    Did it help. I am planning a new computer id method. Basically right now the mac is the identifier for the computer, limiting the system to only unique mac addresses. A future release will probably use a combination of mac and serial number or uuid, or something along those lines, allowing the same mac to be reused.

  5. I dropped this for a bit, but came back to it in the last few days. I finally fixed the issue with MacBook Airs. This fix assumes that all devices have a Wi-Fi network port. I feel this is a pretty safe assumption in 2017 even with older Apple devices. This also assumes that identifying a device by Wi-Fi mac address as opposed to ethernet mac address does not adversely effect how CloneDeploy treats the device.

    I checked to see that the osx_task_list script looks at all mac addresses on a given device before determining if a task has been assigned to that device. Since this is the case CloneDeploy should check for active tasks for Wi-Fi as well as ethernet which means that it should not matter which mac is the primary identifier.

    Next I went back to the osx_register script and changed the entry in line 9 to

    mac=$(networksetup -listallhardwareports | grep -A 3 "Wi-Fi" | grep "Ethernet Address:" | cut -d " " -f 3)

    This will now choose the Wi-Fi network port as the primary mac address when registering a new device. So far in testing it has worked properly.

 

or Sign Up to reply!