mirror of
https://github.com/fleetdm/fleet
synced 2026-05-06 06:48:54 +00:00
149cd9daca
This change is deceptively simple but helps us choose the right one in cases like #29042 where there are multiple enrollments in the registry. In this case the customer seems to have been using something like co-management(though even using their MDM we have not repro'd internally) which leads to 2 registry keys in the registry with a UPN node. I believe the way some MDM services handle unenroll can also leave the registry keys in this state. Either way, because of this, and the fact that we have a LIMIT 1 in the query, we were, in 50% of the cases where we had multiple keys, returning the less useful of the nodes from the query and because no Server URL was coming back we were treating it as if the host was not MDM enrolled and thus, not unenrolling it, and leading to enrollment failing. With this change we'll return the proper registry key which should allow us to, in the case of migration, properly unenroll the host and even in the case where a customer isn't using Fleet MDM will allow us to display the correct information from the registry. # Checklist for submitter If some of the following don't apply, delete the relevant line. <!-- Note that API documentation changes are now addressed by the product design team. --> - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [x] Manual QA for all new/changed functionality |
||
|---|---|---|
| .. | ||
| adr | ||
| architecture | ||
| assets | ||
| getting-started | ||
| guides | ||
| product-groups | ||
| reference | ||
| research | ||
| responsibilities | ||
| workflows | ||
| README.md | ||
Fleet Contributor Documentation
Welcome to the Fleet contributor documentation! This documentation is designed to help you contribute to the Fleet project.
Documentation structure
The documentation is organized into the following sections:
- Getting Started - Setup, building, and testing Fleet
- Guides - How-to guides for common tasks
- Architecture - High-level architecture documentation
- Product Groups - Documentation for specific product groups
- Workflows - Development workflows
- Reference - API reference, configuration, etc.
- ADRs - Architectural Decision Records
- Research - Research documents for product groups
- Responsibilities - Responsibility documents for product groups
Product groups
Fleet is organized into three main product groups:
- MDM - Mobile Device Management
- Orchestration - Device orchestration using osquery
- Software - Software inventory, vulnerability management, and software installation
Contributing
If you're new to Fleet, we recommend starting with the Getting Started section to set up your development environment.
Once you're set up, you can explore the Guides section to learn how to contribute to specific areas of the project.
Architectural Decision Records (ADRs)
We use Architectural Decision Records to document significant architectural decisions. If you're making a significant architectural change, please create an ADR to document your decision.