fleetdm
Upload multiple custom packages to a software title on one team
-
customer-gispenGong snippet: https://us-65885.app.gong.io/call?id=7975473241084299217&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1124%2C%22to%22%3A1435%7D%5D -
customer-olympus- Slack message: https://fleetdm.slack.com/archives/C04U4B1J40Y/p1738337330306439 -
prospect-nuptel- Slack message: I'm running into this with GlobalProtect: https://github.com/fleetdm/fleet/issues/20834. I need to be able to upload two different versions of the same GP client, one UI, and the other CLI. Is there a workaround, or will this be fixed soon? - @noahtalerman: olympus requested this because they want to install different packages for Ubuntu 22 vs Ubuntu 24 that have the same package identifier and is blocked from uploading.
- @noahtalerman: In the interim olympus could create two teams: "Ubuntu 22" and "Ubuntu 24"
- @noahtalerman: In the interim olympus could re-package the package so that it has a different identifier (whatever Fleet is using to match software titles).
- @noahtalerman: Eventually Fleet could allow the user to add the same package, for different OS versions, to the same team.
- @noahtalerman: nuptel requested this because they want to install different packages, GlobalProtect client, one UI, and the other CLI, that have the same package identifier and is blocked from uploading.
- @allenhouchins: Brock was trying to install Google Chrome on a Windows VM on an Apple Silicon Mac to troubleshoot Windows software installs for a Fleet customer. So, I wanted to add Google Chrome for Windows Arm to "Compliance exclusions" but we already have Google Chrome for Windows x86 on that team.
- @noahtalerman: User requested this because we (Fleet) manage software for Intel and Apple Silicon Macs. We can safely assume that our customers are required to do the same for at least 2 years (see below)
- @allenhouchins: There are certain states that require hardware warranty for 7 years (CA for example). CA is the longest I've heard of. As an organization it doesn't make sense to support hardware that beyond warranty. Thus, we can hypothesize that Intel Macs will be phased out at most organizations whenever the macOS that supports Intel is beyond this threshold. November 2020 was the first M1. So, sometime around 2027 is when Intel might be phased out.
- @allenhouchins: We can use the supported operating systems to dictate the supported hardware for macOS. Apple makes it easy to know which OS is supported on which hardware. Might be harder on Windows and Linux.
- @noahtalerman: In the interim the user can create a "Workstations - ARM" and "Workstations - Intel" team and add the packages to each.
- @noahtalerman: Eventually the user could add the same app for Intel and ARM workstations to the same team.
User stories:
- https://github.com/fleetdm/fleet/issues/28108
@allenhouchins skipped this one during unpacking the why because, as a prospect request, it doesn't meet prioritization criteria: https://fleetdm.com/handbook/company/product-groups#criteria-for-prioritization.
@noahtalerman putting back in our queue as we have a customer tied to this request now (customer-olympus)
Problem
Admins need to be able to upload two different versions of the same GlobalProtect client, one UI, and the other CLI.
This extends into being able to manage multiple versions of the same software title too where I need to keep a certain group of devices on a specific version while being able to update all other devices.
What have you tried?
N/A
Potential solutions
Allow admins to upload software that shares the same identifier to a team.
What is the expected workflow as a result of your proposal?
Admins can upload multiple copies of the same software to a team.
Running into this with dogfood. I need to be able to scope an x86 vs ARM version of software installers to Windows and Linux devices:
https://github.com/fleetdm/fleet/tree/main/it-and-security/lib/windows/software https://github.com/fleetdm/fleet/tree/main/it-and-security/lib/linux/software
Re-adding product tag to discuss again.
From the duplicate issue here:
Problem
Fleet currently allows only one installer per software title per team. This limitation creates challenges for organizations managing environments with:
- Multiple Linux distributions (e.g., Debian, Fedora, openSUSE)
- Different package managers (e.g., deb, rpm via yum, zypper)
- Varying CPU architectures (e.g., x86_64, ARM)
When an organization needs to deploy the same software (e.g., CrowdStrike) across different environments, the current system does not allow uploading multiple packages or install scripts under a single software title. Fleet will return an error like “software already exists” when trying to upload another binary for the same software title, even if it’s a different format or target architecture.
What have you tried?
The customer has created the following workaround:
- Create separate teams in Fleet for each combination of distro/package manager (e.g., one team for yum, one for zypper, another for deb).
- Managed install scripts and software uploads within these isolated teams.
- Plans to create even more teams as ARM-based devices begin appearing.
While this workaround functions, it creates significant overhead and leads to:
- Fragmented configuration and oversight across teams
- Duplication of software titles and logic
- Harder to maintain consistency or audit what’s installed across the fleet
Potential solutions
Here are a few possible directions to resolve this issue:
- Multi-installer Support per Software Title •Allow users to define multiple binaries and install scripts under a single software title. •Each installer would be scoped by OS, package manager, and architecture (e.g., debian-x86, fedora-arm, ubuntu-x86, etc.).
- Automatic Installer Matching •Fleet determines the right installer at deployment time using host metadata: •Platform/Distro •Architecture •Package Manager •Selects and runs the appropriate installer from the software title’s pool.
- Installer Rules UI/Config •Allow users to define rules or conditions within the software title config (e.g., “if platform = debian and arch = arm64, use Installer A”).
- Enhanced Label or Query-Based Targeting •Allow installer targeting by custom labels or query logic if multiple binaries were allowed.
What is the expected workflow as a result of your proposal?
-
Single software title management
- Admin creates one software title, e.g., CrowdStrike Sensor
-
Attach multiple installers
- Upload multiple installers files with associated install scripts.
-
crowdstrike.debfor Debian-based -
crowdstrike.rpmfor RHEL/Fedora -
crowdstrike.zypper.rpmfor openSUSE - ARM versions for each
-
- Upload multiple installers files with associated install scripts.
-
Fleet auto-selects installer
- Based on each host's metadata, Fleet automatically picks the correct installer/script to deploy
-
Unified reporting
- All install data (success/failure) tracked under the same software title, regardless of platform or arch
-
Simplified team management
- Fewer (or no) duplicate teams required just to handle install permutations
@allenhouchins:
prospect-fountainran into the situation where they want to upload different Microsoft apps for their Apple devices but Microsoft bundles their AutoUpdate app in every package so any Microsoft app uploaded after the first one, gets rejected.@noahtalerman: First added Word, Powerpoint, Outlook, Excel, Autoupdate. All are custom packages. Then, they tried to add Windows App (Remote Desktop alternative) and saw the above error.
@allenhouchins can you please track a bug for this?
We think the error fountain is seeing is expected. But, they're confused because the name of the software is incorrect (that's the bug). It should be "Windows app" and not "Microsoft Autoupdate"
@allenhouchins @noahtalerman Created #31306 for the specific Windows App bug. Agreed that us extracting metadata as MS AutoUpdate, and then having conflicts due to seeing multiple apps uploaded with that extracted metadata (my guess is that other MS apps have similar issues, even though we fixed Company Portal), is a different issue than this one. If we can get that bug triaged quickly enough it could land in the 4.73 dev sprint and I can run with it, building on tweaks I've done in 4.72 (which unfortunately didn't fix this particular metadata extraction issue).
The ARM64 vs x86_64 thing happens for Macs too, if you have software that provides different pkgs based on arch (common in security software installs). You can't add both as it says it already exists.
Addingcustomer-numa to this issue.
You can't have two versions of an installer at the same time, like Firefox 130 vs 131, or two builds of the same software for different versions of an OS, like a Windows 10 or 11 build.
Some vendors use the same installer name/id for different products, in this case RealVNC calling both their server and viewer installers "RealVNC."
Slack thread: https://fleetdm.slack.com/archives/C075T40SYB1/p1756934038068459
We have a community request for this feature as well.
This feels like a miss because, for example, we use ProSeries and we have like 7 years of installers. We have to have the correct year for each one cause the IRS tax code for that year is bundled so when opening previous year tax returns.
https://osquery.slack.com/archives/C01DXJL16D8/p1761591540250619
In case the above gets cut off due to Slack archiving: https://chat.osquery.io/t/32622567/new-question-looking-through-the-maintained-apps-and-wonderi#59d6b73e-5cb5-4314-8e15-9438e1473fd9
