search

fleetdm / fleet

Open-source platform for IT, security, and infrastructure teams. (Linux, macOS, Chrome, Windows, cloud, data center)
https://fleetdm.com
Other
2.7k stars 384 forks source link

Can't manage software for Intel and Apple Silicon Macs #20249

Open spokanemac opened 1 week ago

spokanemac commented 1 week ago

Fleet version: Fleet 4.53.1 • Go go1.22.4<!-- Copy this from the "My account" page in the Fleet UI, or run fleetctl --version -->

Web browser and operating system: Arc Version 1.49.1 (51495) Chromium Engine Version 126.0.6478.127

💥  Actual behavior

Software title already exists. 20240708_110249_Dogfood Dashboard@2x

🧑‍💻  Steps to reproduce

  1. Upload Chrome for Intel Macs
  2. Upload Chrome for Apple Silicon Macs

🕯️ More info (optional)

We are running into the architecture issue because Mike's laptop is still running Intel. His is the only one. We could try to get him upgraded to arm64, but it's probably better for us to leave him on Intel so we have a real device to dogfood against and can feel the pain of managing both.

🛠️ To fix

Related: https://github.com/fleetdm/confidential/issues/6916

nonpunctual commented 1 week ago

Please see the script I posted in this comment for the .dmg install logic @spokanemac is referring to: https://github.com/fleetdm/fleet/issues/18865#issuecomment-2207323202

marko-lisica commented 1 week ago

Hey @spokanemac, heads up, I converted this bug to a feature request. This is expected behavior since we don't distinguish installer architecture for macOS and Windows apps.

spokanemac commented 5 days ago

@marko-lisica I understand, but this is blocking my dogfooding of Fleet. This is a failure in the design of this feature. We need to be able to differentiate not only between architectures but also between versions.

cc: @noahtalerman @lukeheath

noahtalerman commented 5 days ago

Hey @spokanemac! Sorry you're running into this.

Upload Chrome MSI for Intel (using Web UI: Software page > Add software) Upload Chrome MSI for ARM

I'm trying to understand the problem a bit more. Are we (Fleet) managing Windows workstations w/ ARM? Or is this for virtual machines (Windows) that run on macOS w/ ARM?

lukeheath commented 5 days ago

@spokanemac I spoke with Noah and he said that right now the best approach is to have different teams for arm64 and intel devices. Not ideal, but it does allow us to upload both installers. But, it sounds like you're pointing out something else that's blocking, which is needing to have multiple versions. I'm wondering why we'd want multiple versions of software, instead of just the latest version. Can you help me understand?

spokanemac commented 5 days ago

@noahtalerman Windows on an ARM VM is one example. We will also see this from the MDM test setups. I can recreate this for macOS apps that have Intel and AppleSilicon specific installers. (Zoom, WedEx are examples, but more exist as AppBundles that need repackaging.)

@lukeheath Multiple verison example might be 1Password 7 and 1Password 8. As an example, we may standardize on 7, but allow a self-service to 8. This isn't currently possible (but is exactly what I do with Munki).

lukeheath commented 5 days ago

@spokanemac Thanks for the info. That indeed sounds like something new we haven't considred yet. @noahtalerman What do you think? Should we triage as a bug since it's blocking normal dogfooding? (i.e. can't have 1Password 7 and 8).

noahtalerman commented 4 days ago

I spoke with Noah and he said that right now the best approach is to have different teams for arm64 and intel devices.

@spokanemac and @spokanemac wait! I'm can't remember saying this...could be forgetting 🙃

I'm not convinced we need to break out different teams yet.

The problem we're trying to solve is dogfooding right?

Do we need to update software on Windows ARM VMs and MDM test setups? Aren't these in our "Compliance exclusions" team? (documented as best practice here)

If we don't, maybe we start with focusing on only contributor workstations? Then the question I have is do we have any Windows on ARM contributor workstations?

noahtalerman commented 4 days ago

What do you think? Should we triage as a bug since it's blocking normal dogfooding? (i.e. can't have 1Password 7 and 8).

@lukeheath and @spokanemac thanks for rasing this! I think no need to track a bug.

@marko-lisica I think let's make sure we solve this "version floor" problem (7 is required but 8 is offered in self-service) as part of these stories in the current design sprint:

For #19551, my first thought is that w/ an option to automatically install software, @spokanemac can add 1Password 8 and write a pre-install query that checks for anything below version 7. So, Fleet installs 1Password 8 on hosts that are below 7 but leaves hosts with 7 and above alone.

For #18865, Fleet can do the above for the user: add 1Password 8 and write the pre-install query.

spokanemac commented 4 days ago

@noahtalerman My dogfooding is also any other admin trying to use Fleet for software deployment and self-service.

I am doing my best to replicate how I currently deploy software using other tools (munki and installomator). It shouldn't matter if we have a need at the present moment, we will have a need soon. Also, it's a non-starter for admins if out of the gate, we're having to work around Fleet's shortcomings.

The baseline for me is support for multiple architectures, multiple versions, AppBundles and DMGs (without repackaging).

noahtalerman commented 4 days ago

@spokanemac we definitely want to solve 1 package for each arch. Plan to to work on an improvement.

Regarding our Fleet organization problem (I can't manage software on Windows ARM) I'm trying to understand if we're dogfooding managing Windows ARM machines and Windows VMs.

If we are managing Windows ARM machines and Windows VMs, then it makes sense to use a solution like Luke suggested and break out a separate team.

If we can wait to manage these machines (move them to the "Compliance exclusions"), then I think we can wait for the product solution (1 package for each arch).

Note that the best practice is changing in real time as we learn! So, apologies if I'm coming back with a lot of questions. I'm trying to learn from you :)

cc @lukeheath @marko-lisica

lukeheath commented 4 days ago

@noahtalerman We are running into the architecture issue because Mike's laptop is still running Intel. His is the only one. We could try to get him upgraded to arm64, but it's probably better for us to leave him on Intel so we have a real device to dogfood against and can feel the pain of managing both.

The problem we're having right now with dogfooding is that we need to be able to upload software installers for both arm64 and intel architectures, but Fleet won't let us because it recognizes them both as the same program, even though their architectures are different. When I told you about this blocker, you told me the best practice was to have an intel and arm64 team so you could upload both software installers. Did I misunderstand?

noahtalerman commented 4 days ago

Hey @lukeheath!

I didn't realize that Mike being on Intel was the problem. I updated this issue description to reflect this instead of managing Windows on ARM.

I think the plan of breaking out a separate "Workstations (Intel)" team makes sense.

When I told you about this blocker, you told me the best practice was to have an intel and arm64 team so you could upload both software installers. Did I misunderstand?

I probably told you this and forgot! That's happening a lot...sorry about that.

cc @spokanemac

noahtalerman commented 4 days ago

@lukeheath I think we can turn this issue into the dogfooding solution: new team.

I can file a separate issue for the product solution: one software for each architecture (Intel and Apple Silicon)

lukeheath commented 4 days ago

@noahtalerman

I didn't realize that Mike being on Intel was the problem. I updated this issue description to reflect this instead of managing Windows on ARM.

I believe what I'm talking about with intel and arm64 is the same core problem JD is running into here. Basically, different types of the same software not being supported (different version numbers, architectures, etc.) Is that correct @spokanemac?

I think the plan of breaking out a separate "Workstations (Intel)" team makes sense.

This makes sense to me for the immediate dogfooding solution. It's not ideal of course, as we'd prefer to keep all workstations together, but it works while we wait for the product improvement. This is a good experience for us, because it's often what we ask our customers to do (use a non-ideal workaround while we build the more ideal feature.)

Glad to hear adding support for multiple architectures in the same team is on the roadmap.

I probably told you this and forgot! That's happening a lot...sorry about that.

No worries! Your fielding a lot of questions every day.