## Issue
Resolves#50528.
## Description
On the My device > Self-service page, with a category selected and a
search query typed, the "Install all" button previously ignored the
search: it counted (and queued) every uninstalled item in the category,
including software the search had filtered out.
This PR scopes the button — count *and* install target — to the visible
subset:
- **Backend:** `POST /device/{token}/software/install_all` now accepts a
`query` param. It's threaded through
`SelfServiceInstallAllSoftwareTitles` → `GetSoftwareTitlesForInstallAll`
→ `opts.ListOptions.MatchQuery` on `ListHostSoftware`, reusing the same
LIKE-on-`software_titles.name` semantics as the self-service list
endpoint.
- **Frontend:** new `filterSoftwareByQuery` helper layers on top of the
category filter to drive `uninstalledCount` / `hasInProgress` and the
value sent to install_all. Empty queries are stripped so the API isn't
called with `?query=`.
`display_name` matching is deliberately out of scope — the search filter
across BE list, desktop table, and mobile filter is all raw-`name`-only
today, so broadening install_all alone would re-introduce a similar
mismatch. Filed as a follow-up: #50750.
## Screen recording
In recording:
- (FE fix) showing that the UI is filtering out install all count to be
only what's on the screen
- (BE fix) showing that the call to the API only queues up the install
all for the installers shown on the screen when clicked
https://github.com/user-attachments/assets/aaae3d29-dccf-484d-910f-67ca335bf0e8
## Testing
- FE unit tests: `filterSoftwareByQuery` helper, `SelfServiceCard`
count-with-query + POST-with-query, `InstallAllInCategoryButton` prop
forwarding.
- BE unit test: EE service forwards the match query to the datastore.
- BE datastore test: query, category+query, empty-match cases.
- BE integration test: new "scopes to the query parameter when provided"
subtest in `TestInstallAllSelfServiceSoftware`.
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* “Install all” now respects the active self-service search query.
* Counts, progress indicators, and installation requests now reflect
only software matching the current search and category filters.
* Empty or whitespace-only searches continue to include all software in
the selected category.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Resolves#45414
- Added Adobe plugins to software inventory: Fleet now detects Adobe Creative Cloud plugins (CEP and UXP extensions) on macOS and Windows hosts and lists them on the Software page and host details with the software type "Plugin (Adobe)", including version and host count.
- Adobe plugins are excluded from vulnerability scanning, so no vulnerabilities are reported for them. No vulnerability data source maps an Adobe CEP or UXP extension to a CVE; Adobe files CVEs against the host application (Photoshop, Acrobat, and so on), which Fleet already scans.
Removed outdated sections from the REST API documentation. We're not
consistently adding new ones like "Vulnerabilities" and I don't think
the website uses these.
Co-authored-by: Rachael Shaw <r@rachael.wtf>
**Related issue:** N/A
## Summary
Fleet's "Host vitals" label type already supports matching on a custom
host vital's exact value (in addition to the existing IdP-based
criteria), but this wasn't documented anywhere outside the custom host
vitals guide (see companion PR #50660). Adds that coverage across the
remaining references:
- `articles/managing-labels-in-fleet.md`: the "Host vitals" label type
bullet only listed the two IdP criteria; now also mentions custom host
vitals, and notes the type is exact-match only.
- `docs/Configuration/yaml-files.md`:
- Adds a `custom_host_vital` example to the labels GitOps reference,
alongside the existing IdP example.
- Adds a new `## custom_host_vitals` section documenting the top-level
GitOps key used to define vitals in the first place (referenced by the
labels criteria above), which had no reference-doc coverage at all.
Calls out that, unlike `labels`, omitting the key entirely deletes every
existing custom host vital rather than leaving them intact.
- `docs/REST API/rest-api.md`:
- The `criteria` parameter table was missing `custom_host_vital` as a
valid `vital` value and missing `custom_host_vital_id` entirely — added
both.
- None of the 6 registered custom host vitals endpoints (list, create,
update, delete, set a host's value, and the spec/replace-all endpoint
GitOps uses) had reference entries at all. Adds a full "Custom host
vitals" section following the existing "Custom variables" section's
format, including the same destructive replace-all behavior called out
in the YAML reference above.
# Checklist for submitter
- [ ] QA'd all new/changed functionality manually
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#50551
Two published pages still describe pre-4.84 behavior, telling users that
GitOps mode doesn't restrict label editing in the UI. Since 4.84 that's
only true when the labels exception is enabled. This PR corrects both
pages and documents the exceptions framework.
**`docs/Configuration/yaml-files.md`**
- `labels` section: rewrote the note around the two exception states.
Beyond the sentence the issue flagged, the premise it rested on was also
stale: the note said omitting the `labels` key leaves existing labels
intact. Since #42191, `computeLabelChanges`
(`cmd/fleetctl/fleetctl/gitops.go:947`) branches on
`len(specifiedLabels) == 0`, so omitting the key deletes every custom
label in that scope unless the labels exception is enabled. Its own
tests name this behavior ("labels omitted removes all regular labels
when not excepted"). The note now spells out both states and fixes a
`label` / `labels` typo.
- `gitops` section: added a note that exceptions can't be set in YAML.
`Client.DoGitOps` strips the `exceptions` key defensively
(`server/service/client.go:726`), so this was worth stating explicitly.
**`articles/gitops-mode.md`**
- Added an "Exceptions" section covering the three exception types, what
an exception does to both the UI and `fleetctl gitops`, and the enroll
secrets default. Upgrade behavior is left to the release notes. It notes
that exceptions affect `fleetctl gitops` whether or not GitOps mode is
on, since neither the apply-path check nor `computeLabelChanges` reads
`gitops_mode_enabled`.
- "Still available" no longer lists "Add and edit labels"
unconditionally. It now points at the exceptions section for labels,
software, and enroll secrets.
Behavior the docs now match:
- UI gating is `GitOpsModeTooltipWrapper` with `entityType="labels"`
(`frontend/pages/labels/components/LabelForm/LabelForm.tsx:172`,
`NewLabelPage.tsx:676`, `HostsFilterBlock.tsx:223`). `useGitOpsMode`
treats an enabled exception as GitOps mode being off for that entity.
- Apply-path enforcement is in `server/service/client.go:2219-2242`
(premium only).
- Defaults: `server/fleet/app.go:1216` for new installs, migration
`20260323144117_AddGitOpsExceptionsToAppConfig.go` for upgrades.
The backend is unchanged and was already correct. `ModifyLabel` applies
no GitOps check, and the per-host label endpoints stay available
regardless of GitOps mode or exception state, so this PR is docs-only.
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
Not applicable: documentation-only change, no product behavior change.
## Testing
- [x] QA'd all new/changed functionality manually
Verified the described behavior against the UI gating, the `fleetctl
gitops` apply path, and the exception defaults in code (references
above).
Adds scripts for Windows and Ubuntu that checks the health of all fleetd
components and collects logs and recent events into a timestamped
archive for support and troubleshooting.
These have been used by multiple customers now, and has simplified the
collection of logs from multiple locations while including events that
can assist with troubleshooting. Adding to solutions for wider use.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#49655
Documentation-only change. No server behavior changes.
## What's happening
On a personally-owned work profile (BYOD), Android applies the biometric
values of `keyguardDisabledFeatures` to the work profile lock. By
default the end user has one lock for both the work profile and the host
("Use one lock"), so there is no separate work profile lock to restrict,
and Android restricts the host's lock instead. Fingerprint and face
unlock turn off for the whole host, including the end user's personal
apps.
This is documented Android behavior, per
[`setKeyguardDisabledFeatures`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#setKeyguardDisabledFeatures(android.content.ComponentName,%20int)):
> `KEYGUARD_DISABLE_FINGERPRINT`, `KEYGUARD_DISABLE_FACE` or
`KEYGUARD_DISABLE_IRIS` which affects the managed profile challenge if
there is one, **or the parent user otherwise**.
Fleet never sets `keyguardDisabledFeatures` itself. Fleet's default
Android policy sets only `StatusReportingSettings`, and admin-authored
AMAPI policy is passed through as-is. The reason this still lands on
Fleet is that the profile in the bug report is byte-for-byte the example
Fleet publishes at
`docs/solutions/android/configuration-profiles/disable-face-and-biometrics-unlock.json`,
with no note about the BYOD side effect.
## What changed
- `articles/custom-os-settings.md`: new "Biometric unlock on
personally-owned (BYOD) hosts" subsection under "Special Android
behavior", covering the behavior and the configuration that scopes the
restriction to work.
- `docs/solutions/android/configuration-profiles/README.md`: entries for
the biometrics profile (carrying the caveat) and for the new example.
-
`docs/solutions/android/configuration-profiles/require-separate-work-profile-lock.json`:
new example using `passwordScope: SCOPE_PROFILE` and
`unifiedLockSettings: REQUIRE_SEPARATE_WORK_LOCK`.
The remedy needs no Fleet change: `passwordPolicies` is already in the
Android policy field mask
(`server/mdm/android/service/androidmgmt/policy_field_mask_test.go`), so
Fleet already delivers it.
## Testing
- [ ] QA'd all new/changed functionality manually
Docs-only, so no automated tests were added. Verification done:
- Both the new example profile and the combined snippet in the guide
decode into the real `androidmanagement.Policy` struct with
`DisallowUnknownFields`, confirming every key and nesting level matches
the AMAPI schema Fleet ships.
- The documented status flow (`USER_ACTION` non-compliance on
`passwordPolicies` marks the profile "Failed", then "Verified" once the
end user sets the work lock) is confirmed against
`server/mdm/android/service/pubsub_test.go`.
**Not yet verified on hardware.** I have not run the repro on a physical
BYOD Android host. Before merge, this is worth confirming:
1. On a BYOD Android host with fingerprint unlock configured and a work
profile enrolled, apply `disable-face-and-biometrics-unlock.json`.
Confirm fingerprint disappears as an unlock method device-wide.
2. Add the `passwordPolicies` block from
`require-separate-work-profile-lock.json` to that profile and re-upload.
Confirm Android prompts for a separate work profile lock, and that Fleet
shows the profile "Failed" with `USER_ACTION` on **Host > OS settings**
until the end user sets it.
3. After the end user sets the work lock, confirm the profile moves to
"Verified", fingerprint unlock works again on the personal side, and the
work profile still requires PIN/password.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an Android configuration profile option that requires a separate
lock for the work profile.
* Applies password policy settings specifically to the work profile
scope.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#47714
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] 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. (Will be part of another PR)
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops
- [x] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Collect and persist macOS software update device identifiers for hosts
during both manual and OTA enrollment flows.
* Added an osquery detail/query to derive the identifier from hardware
properties and upsert it into datastore.
* **Bug Fixes**
* Host deletion now also removes related Apple macOS OS update records.
* **Improved Device Recognition**
* Enhanced Mac model identifier parsing and refined Apple Silicon
detection with expanded test coverage.
* **Reliability**
* Enrollment profile delivery remains unaffected if saving the
identifier fails (errors are logged).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Removes the link to the example Prometheus config
(`tools/app/prometheus.yml`) from the reference architectures doc, since
that file is being removed in #50053.
Split out of #50053 so the docs change can be reviewed separately.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Documentation-only change; no changes file, tests, or QA needed.
Resolves#50069
Omarchy 4 ships its own /etc/os-release with ID=omarchy, where earlier
versions inherited ID=arch from Arch Linux. Since HostLinuxOSs and
HOST_LINUX_PLATFORMS gate nearly every Linux check, these hosts had
empty vitals and software inventory, were missed by linux-scoped
policies and labels, had no disk encryption or key escrow, and lost Run
script in the UI (the API was unaffected).
Add "omarchy" to HostLinuxOSs, HostNeitherDebNorRpmPackageOSs (pacman-
based), IsLUKSSupported, HOST_LINUX_PLATFORMS,
DISK_ENCRYPTION_SUPPORTED_LINUX_PLATFORMS, and the Vitals
disk-encryption tooltip. Regenerate understanding-host-vitals.md.
Aggregate Omarchy onto the "Arch Linux" / "rolling" OS inventory row,
where these hosts sat before quattro. Unlike CachyOS, Omarchy reports a
real release number rather than BUILD_ID=rolling, so the version is
pinned after parsing instead of rewriting the ingested build value.
Also add a fleetd test container, built on archlinux since Omarchy
publishes no image.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
## Summary
While working on a parser for the REST API docs, I found a number of
broken spots in the reference. This PR fixes them. They all affect human
readers too (invalid JSON in examples, missing response documentation,
broken tables).
- Fixed invalid JSON in 28 response examples (trailing commas, missing
braces, stray tokens, `...` placeholders inside JSON).
- Added missing `Default response` documentation to 6 endpoints. Status
codes and body shapes were verified against the Go handlers rather than
inferred.
- Added missing `Status:` lines to 4 response blocks. One is a
correction: `Rotate host's Recovery Lock password` was documented as
returning `204`, but the server returns `200` (its response struct has
no `Status()` override).
- Fixed 3 malformed parameter tables (wrong column counts, one missing
`In` value).
- Restored the standard request line in `Get script result`.
- Corrected the dual-key token examples (`abm_tokens`/`ab_tokens`,
`teams`/`fleets`): the nested team objects use `team_id` in legacy
containers and `fleet_id` in renamed containers on the wire, not bare
`id`.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Manual QA for all new/changed functionality
### Test plan
- Every JSON example touched by this PR was mechanically validated
(valid JSON after stripping `//` comment annotations).
- Added response blocks and status codes were checked against the Go
handlers (response structs and `Status()` methods).
- The full document was run through the parser to confirm every endpoint
section now reads cleanly.
EnrollOrbit now determines end user authentication requirements from
server policy rather than the client-supplied X-Fleet-Capabilities
header, which is treated as an informational hint.
Adds the mdm.allow_orbit_end_user_auth_bypass setting (enabled by
default) controlling whether hosts that do not complete end user
authentication may enroll into a team that requires it; set it to false
to strictly enforce end user auth. The setting also governs installers
built with fleetctl package --bypass-end-user-auth.
Make failed logins for MFA-enabled accounts return a consistent response
and timing regardless of the cause, in line with authentication best
practices. Guidance for CLI users whose client can't complete email
verification is now surfaced by fleetctl on any login failure.
Added a `user_mfa_requested` activity, recorded when valid credentials
are submitted for an MFA-enabled account and a verification email is
sent.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** N/A
# Checklist for submitter
- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
## Summary
Moves the `POST
/api/v1/fleet/device/{token}/software/install/{software_title_id}`
("Install self-service software") endpoint out of the contributor-only
API reference (`docs/Contributing/reference/api-for-contributors.md`)
and into the public REST API docs (`docs/REST API/rest-api.md`), nested
under the existing `## Software` section.
- Added `### Install self-service software` to `docs/REST
API/rest-api.md`, right after `### Uninstall software`, with a TOC entry
and a note that it uses the device's authentication token instead of the
usual Fleet API token.
- Removed the TOC entry and body section for this endpoint from
`docs/Contributing/reference/api-for-contributors.md`. Sibling
device-authenticated self-service endpoints were left in place there
since only this one endpoint was moved.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an API route allowing Fleet Desktop users to initiate
self-service software installations using a device token and software
title.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
## Summary
Documentation-only update to the SSO deployment guide
(`docs/Deploy/single-sign-on-sso.md`) to improve clarity and consistency
across the supported identity providers. No code changes.
## Changes
- **Okta**: Rewrote the setup section into clear numbered steps — app
naming/logo, SAML settings, attribute statements (including the
`displayname` expression and JIT group-to-role mapping example), and
copying the
metadata URL.
- **Consistent callback URLs**: Standardized how each IdP documents the
two callback URLs, making the distinction explicit everywhere:
- **Fleet users** → `https://<your_fleet_url>/api/v1/fleet/sso/callback`
- **End users** (MDM/end user authentication) →
`https://<your_fleet_url>/api/v1/fleet/mdm/sso/callback`
- **Google Workspace, Entra, authentik, Other IdPs**: Updated each to
use the same "depends on which connection you're configuring" callback
URL pattern, and aligned Entity ID wording.
- Cleaned up formatting/indentation and removed redundant/duplicated
instructions.
- Added a new screenshot: `docs/images/okta-sso-step-1.png`.
## Checklist for submitter
- [x] QA'd all new/changed functionality manually (previewed rendered
Markdown and images)
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
This enforces NTP on macOS devices.
The "Set date and time automatically" toggle can be verified with
`systemsetup - getusingnetworktime` (you can write a script to put the
output of that into a file, then use the `file_lines` table in a
policy), and set with `systemsetup - setusingnetworktime on` (which
could be a script automation that kicks off if a device fails the
policy).
If you want to prevent users from changing it, you can use the attached
config profile. Note that it requires setting the NTP server, but this
is most likely just the default Apple server. The `setusingnetworktime`
will work even with the Ul locked.
<img width="1458" height="320" alt="Screenshot 2026-05-14 at 08 19 28"
src="https://github.com/user-attachments/assets/22064715-1548-490c-b3e0-bde51dd26f12"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a macOS configuration profile that automatically configures
devices to use Apple’s time server.
* Included a human-readable profile name and standard configuration
metadata for easier deployment.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Clarify MDM support requirements for Windows 11 and add Linux support
details.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves #
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] 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.
- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [ ] Timeouts are implemented and retries are limited to avoid infinite
loops
- [ ] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [ ] Added/updated automated tests
- [ ] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [ ] QA'd all new/changed functionality manually
For unreleased bug fixes in a release candidate, one of:
- [ ] Confirmed that the fix is not expected to adversely impact load
test results
- [ ] Alerted the release DRI if additional load testing is needed
## Database migrations
- [ ] Checked schema for all modified table for columns that will
auto-update timestamps during migration.
- [ ] Confirmed that updating the timestamps is acceptable, and will not
cause unwanted side effects.
- [ ] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
## New Fleet configuration settings
- [ ] Setting(s) is/are explicitly excluded from GitOps
If you didn't check the box above, follow this checklist for
GitOps-enabled settings:
- [ ] Verified that the setting is exported via `fleetctl
generate-gitops`
- [ ] Verified the setting is documented in a separate PR to [the GitOps
documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485)
- [ ] Verified that the setting is cleared on the server if it is not
supplied in a YAML file (or that it is documented as being optional)
- [ ] Verified that any relevant UI is disabled when GitOps mode is
enabled
## fleetd/orbit/Fleet Desktop
- [ ] Verified compatibility with the latest released version of Fleet
(see [Must
rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md))
- [ ] If the change applies to only one platform, confirmed that
`runtime.GOOS` is used as needed to isolate changes
- [ ] Verified that fleetd runs on macOS, Linux and Windows
- [ ] Verified auto-update works from the released version of component
to the new version (see [tools/tuf/test](../tools/tuf/test/README.md))
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#43667
# Summary
Documents `setup_experience_platforms` on software packages in the
GitOps yaml reference. Field selects a `.sh` script-only package for the
macOS setup experience without disturbing its native Linux behavior.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Docs updated in `docs/Configuration/yaml-files.md` — field
description, semantics, and an example under `software.packages`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated the Apple MDM documentation for the “Rotate FileVault key”
command to provide the correct description (replacing an inaccurate
reference).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Allen Houchins <32207388+allenhouchins@users.noreply.github.com>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** #38986
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
## Testing
- [x] Confirmed the documentation diff contains only the Fleet version
update.
Reasons to delete:
- We are not using this docker image.
- It's polluting the `docker compose up` logs with errors, e.g.:
```
cadvisor-1 | E0716 17:14:28.835089 1 manager.go:1116] Failed to create existing container: /docker/9ac0ef6fad63613bf90dbfb80e4fcf7affc4a378bbf1c2680f9fa0a587db783f: failed to identify the read-write layer ID for container "9ac0ef6fad63613bf90dbfb80e4fcf7affc4a378bbf1c2680f9fa0a587db783f". - open /var/lib/docker/image/overlayfs/layerdb/mounts/9ac0ef6fad63613bf90dbfb80e4fcf7affc4a378bbf1c2680f9fa0a587db783f/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.839077 1 manager.go:1116] Failed to create existing container: /docker/891666c60086c1a695860bf5ea4a1eaf4ada94d902ee7392ddfab1bfd7ed5876: failed to identify the read-write layer ID for container "891666c60086c1a695860bf5ea4a1eaf4ada94d902ee7392ddfab1bfd7ed5876". - open /var/lib/docker/image/overlayfs/layerdb/mounts/891666c60086c1a695860bf5ea4a1eaf4ada94d902ee7392ddfab1bfd7ed5876/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.841743 1 manager.go:1116] Failed to create existing container: /docker/bbfd8df39c02cec5d4ad665f4bb23faa5fc374efd7cb1ae0ff4864474c8a1b63: failed to identify the read-write layer ID for container "bbfd8df39c02cec5d4ad665f4bb23faa5fc374efd7cb1ae0ff4864474c8a1b63". - open /var/lib/docker/image/overlayfs/layerdb/mounts/bbfd8df39c02cec5d4ad665f4bb23faa5fc374efd7cb1ae0ff4864474c8a1b63/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.844137 1 manager.go:1116] Failed to create existing container: /docker/62cad7aa07068e9ad14319a170622c4658008fd394347aa60e84f79727a03d29: failed to identify the read-write layer ID for container "62cad7aa07068e9ad14319a170622c4658008fd394347aa60e84f79727a03d29". - open /var/lib/docker/image/overlayfs/layerdb/mounts/62cad7aa07068e9ad14319a170622c4658008fd394347aa60e84f79727a03d29/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.846207 1 manager.go:1116] Failed to create existing container: /docker/6fc30f822f6ccf81a192b5d385b30f5ed02f162df1c9823774405e0517be3cfe: failed to identify the read-write layer ID for container "6fc30f822f6ccf81a192b5d385b30f5ed02f162df1c9823774405e0517be3cfe". - open /var/lib/docker/image/overlayfs/layerdb/mounts/6fc30f822f6ccf81a192b5d385b30f5ed02f162df1c9823774405e0517be3cfe/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.849253 1 manager.go:1116] Failed to create existing container: /docker/a7cec691d2ba6dc8cb8b034729957e6d9bc6dca06813953288d4430cf8d82d28: failed to identify the read-write layer ID for container "a7cec691d2ba6dc8cb8b034729957e6d9bc6dca06813953288d4430cf8d82d28". - open /var/lib/docker/image/overlayfs/layerdb/mounts/a7cec691d2ba6dc8cb8b034729957e6d9bc6dca06813953288d4430cf8d82d28/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.851095 1 manager.go:1116] Failed to create existing container: /docker/160d97ff57081d3439843b5e2fd6bea00ef3ee744de51d01be1f6c0c90dec97d: failed to identify the read-write layer ID for container "160d97ff57081d3439843b5e2fd6bea00ef3ee744de51d01be1f6c0c90dec97d". - open /var/lib/docker/image/overlayfs/layerdb/mounts/160d97ff57081d3439843b5e2fd6bea00ef3ee744de51d01be1f6c0c90dec97d/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.853019 1 manager.go:1116] Failed to create existing container: /docker/9f5f2f98be4da013911de372e808e33ae93b8f5cb2219adb681f31ee3c1497ed: failed to identify the read-write layer ID for container "9f5f2f98be4da013911de372e808e33ae93b8f5cb2219adb681f31ee3c1497ed". - open /var/lib/docker/image/overlayfs/layerdb/mounts/9f5f2f98be4da013911de372e808e33ae93b8f5cb2219adb681f31ee3c1497ed/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.854765 1 manager.go:1116] Failed to create existing container: /docker/c637f0bf6708caeec3fe3b9b610204e84b8b4529cf770c09d6ca2e82f5b681e3: failed to identify the read-write layer ID for container "c637f0bf6708caeec3fe3b9b610204e84b8b4529cf770c09d6ca2e82f5b681e3". - open /var/lib/docker/image/overlayfs/layerdb/mounts/c637f0bf6708caeec3fe3b9b610204e84b8b4529cf770c09d6ca2e82f5b681e3/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.856713 1 manager.go:1116] Failed to create existing container: /docker/74953fdfba3c534515113bedef7f17ce01a7feef27ec22000d52ff4f98a538e9: failed to identify the read-write layer ID for container "74953fdfba3c534515113bedef7f17ce01a7feef27ec22000d52ff4f98a538e9". - open /var/lib/docker/image/overlayfs/layerdb/mounts/74953fdfba3c534515113bedef7f17ce01a7feef27ec22000d52ff4f98a538e9/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.858256 1 manager.go:1116] Failed to create existing container: /docker/96e468826a675094cf686619e9560a5ed0e089bbca8f3c9c41a5d432d7e7e235: failed to identify the read-write layer ID for container "96e468826a675094cf686619e9560a5ed0e089bbca8f3c9c41a5d432d7e7e235". - open /var/lib/docker/image/overlayfs/layerdb/mounts/96e468826a675094cf686619e9560a5ed0e089bbca8f3c9c41a5d432d7e7e235/mount-id: no such file or directory
cadvisor-1 | E0716 17:14:28.859877 1 manager.go:1116] Failed to create existing container: /docker/785d4800c3249c155f6b921ef554f49851920e5d6a295e1d2ef12fb85a327935: failed to identify the read-write layer ID for container "785d4800c3249c155f6b921ef554f49851920e5d6a295e1d2ef12fb85a327935". - open /var/lib/docker/image/overlayfs/layerdb/mounts/785d4800c3249c155f6b921ef554f49851920e5d6a295e1d2ef12fb85a327935/mount-id: no such file or directory
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Removed the cAdvisor monitoring service from the Docker Compose
configuration.
* The application no longer starts cAdvisor or exposes its monitoring
endpoint by default.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#44954
# Checklist for submitter
- [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.
## Testing
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Custom Host Vitals management (create/edit/delete, search) with
copyable variable tokens and per-host values.
* Show Custom Host Vitals on host details, including role-based editing.
* Enabled Custom Host Vitals in host-vitals labels and the activity
feed.
* Extended GitOps to manage global Custom Host Vitals declaratively
(including dry-run behavior).
* Split Controls → Variables into Global Variables and Custom Host
Vitals, including routing updates.
* **Bug Fixes**
* Improved validation and expansion of Custom Host Vital references
across scripts, profiles, installers, and deployments, with clearer
failures when values are missing or invalid.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#47171
Added integration tests for the fleet-psso feature and added PSSO
functionality to our MDM test client - idea being it is so tightly
integrated into the MDM side of things on the Apple side AND we ideall
want osquery-perf to be able to exercise it(coming in the next PR)
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] 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), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops
- [x] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [x] Added/updated automated tests
- [x] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Apple Platform SSO (PSSO) support for device registration,
password login, key requests, and key exchange.
* Added a simulator/test device for exercising the full PSSO workflow
end-to-end.
* Made PSSO AASA development app IDs configurable and enhanced macOS
PSSO activity in performance testing (with new counters).
* Improved local macOS Desktop packaging/signing configurability.
* **Bug Fixes**
* Strengthened PSSO token/crypto handling, including algorithm pinning,
key ID canonicalization, encrypted assertion `typ` validation, and
replay protection.
* **Tests**
* Added extensive crypto interoperability tests (including Apple
known-answer vectors) plus new end-to-end integration coverage.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Magnus Jensen <magnus@fleetdm.com>
**Related issue:** Resolves#44348
**Base branch:** `docs-v4.86.0` (not `main`) per the docs release
process.
## What this PR does
Updates four customer-facing guides and adds a release-notes entry for
Phase 2's opt-in cert renewal feature (shipped via #45696). Frames the
marker as an opt-in enhancement: profiles without it continue to work as
in 4.85; profiles with it activate auto-renewal.
| Guide | Change |
|-------|--------|
| `connect-end-user-to-wifi-with-certificate.md` | Migrated 11 legacy
`\$FLEET_VAR_SCEP_RENEWAL_ID` refs to the preferred name; added
back-compat callout. |
| `okta-conditional-access-integration.md` | Removed "Automatic renewal
coming soon" line; added one-time upgrade-redeploy callout for existing
customers. |
| `enable-okta-verify-on-macOS-with-configuration-profile.md` | Added
marker to example profile OU; added opt-in note and CA-side
OU-preservation verification step. Coordinated with the earlier
example-profile update from #43293 already on `docs-v4.86.0`. |
| `enable-okta-verify-on-windows-using-a-scep-configuration-profile.md`
| Replaced manual-redeployment narrative with auto-renewal guidance.
Kept the policy-based expiry-monitoring SQL as an optional safeguard. |
Release-notes entry (`changes/40639-non-proxied-cert-renewal`)
consolidates Phase 2 customer-visible behavior in three bullets.
## Dependencies
The Conditional Access guide's "new setups: no extra action needed"
framing assumes #45662 (the Fleet-side template marker addition) has
landed — it has, merged into the feature branch and onward into main via
#45696.
# Checklist for submitter
- [x] Changes file added for user-visible changes
## Testing
- [x] Doc review only — no code changes
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Automatic certificate renewal is now supported for SCEP and ACME
certificates from external certificate authorities, enabled by default
for new deployments with an opt-in path for existing customers
* macOS devices with ACME-bearing configuration profiles will now
surface hardware-bound certificates in device vitals
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Rachael Shaw <r@rachael.wtf>
Co-authored-by: Marko Lisica <83164494+marko-lisica@users.noreply.github.com>
Co-authored-by: kilo-code-bot[bot] <240665456+kilo-code-bot[bot]@users.noreply.github.com>
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
Co-authored-by: melpike <79950145+melpike@users.noreply.github.com>
Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
Co-authored-by: Jordan Montgomery <elijah.jordan.montgomery@gmail.com>
Co-authored-by: Jonathan Katz <44128041+jkatz01@users.noreply.github.com>
Co-authored-by: Victor Lyuboslavsky <2685025+getvictor@users.noreply.github.com>
Co-authored-by: Magnus Jensen <magnus@fleetdm.com>
Co-authored-by: RachelElysia <71795832+RachelElysia@users.noreply.github.com>
Co-authored-by: Scott Gress <scottmgress@gmail.com>
- @noahtalerman: For the following quick win:
- https://github.com/fleetdm/fleet/issues/23737
## Summary
Adds a "Targeted platforms" column and a platform filter dropdown to the
Policies page (`/policies/manage`), matching the pattern already used on
the Reports page (`/queries/manage`, `ManageQueriesPage`).
### Frontend
- New non-sortable **Targeted platforms** column rendered via
`PlatformCell`, sourced from each policy's comma-separated `platform`
field.
- New platform filter dropdown (All / macOS / Windows / Linux /
ChromeOS) wired as a `customControl` on the Policies table, alongside
the existing automation filter. Selecting a value pushes a new URL (not
a replace), resets `page` to 0, and updates the `platform` query param.
- `ManagePoliciesPage` reads `location.query.platform` and threads it
through to both `globalPoliciesAPI.loadAll` / `teamPoliciesAPI.loadAll`
and the react-query keys, plus the count endpoints. The
automation-filter and count "hide" conditions now include the platform
filter so they remain visible when only a platform filter is active.
- `frontend/services/entities/global_policies.ts` and `team_policies.ts`
accept an optional `platform` param (with `"all"` normalized to
`undefined`).
- Added tests for the new column and dropdown in
`PoliciesTable.tests.tsx`.
### Backend
- Added `Platform string ` + `` `query:"platform,optional"` `` to
`ListGlobalPoliciesRequest`, `CountGlobalPoliciesRequest`,
`ListTeamPoliciesRequest`, `CountTeamPoliciesRequest`.
- Extended datastore and service signatures (`ListGlobalPolicies`,
`ListTeamPolicies`, `ListMergedTeamPolicies`, `CountPolicies`,
`CountMergedTeamPolicies`, `ListGlobalPolicies`/`ListTeamPolicies` on
the service) to accept a `platform string` arg. Mocks and all call sites
updated.
- Platform filtering in SQL uses a new helper `platformFilterClause`:
```sql
AND (p.platforms = '' OR FIND_IN_SET(?, p.platforms))
```
so policies targeting "all platforms" (empty `platforms` field) always
match regardless of the selected filter. `FIND_IN_SET` uses a bound
parameter (no injection risk).
- Added a new MySQL integration test `testPoliciesPlatformFilter`
covering empty-platform (match-all), per-platform filter, and
team/merged paths.
### Docs
- REST API docs for `GET /api/v1/fleet/global/policies`, `GET
/api/v1/fleet/fleets/:id/policies`, and the corresponding `/count`
endpoints now document the `platform` query param.
- Added `changes/policies-targeted-platforms-filter`.
## Behavior
- `platform=all` (or missing) returns all policies.
- Selecting a specific platform returns policies whose `platforms`
column is empty OR contains the selected token.
- The dropdown only renders when the table is searchable (results exist
OR any filter is active).
- Changing the filter pushes a new URL and resets the page.
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`.
- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [x] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [x] Added/updated automated tests
- [ ] QA'd all new/changed functionality manually
Local verification:
- `go build ./...` — clean
- `go vet ./server/... ./cmd/... ./ee/...` — clean
- `make lint-go-incremental` — 0 issues
- Go service-level policy tests pass. MySQL integration tests compile
but could not be run locally (no Docker); CI will exercise the new
`testPoliciesPlatformFilter` test.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a "Targeted platforms" column with platform icons and an "All
platforms" option.
* Added a platform filter dropdown to scope policy lists; counts,
last-updated, and controls adapt when a platform filter is active.
Backend now honors an optional platform query parameter so filtering
returns matching policies.
* **Tests**
* Added and updated unit and integration tests covering the new column,
filter UI, and platform-filtered policy listings.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: nulmete <nicoulmete1@gmail.com>
- Removed "experimental" for `macos_manual_agent_isntall` and `software`
- There are no plans to break these. Customers are already using them in
production
- @noahtalerman: New Fleet instances now use the `fleetctl new`
templates: https://github.com/fleetdm/fleet/pull/42768/changes
- This starter library was only used for new Fleet instances and as of
the changes above is no longer used
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Cleaned up the starter library configuration by removing two
preconfigured team entries from the example setup.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#45524
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [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), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops
- [x] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [x] Added/updated automated tests
- [x] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [x] QA'd all new/changed functionality manually
For unreleased bug fixes in a release candidate, one of:
- [ ] Confirmed that the fix is not expected to adversely impact load
test results
- [ ] Alerted the release DRI if additional load testing is needed
## Database migrations
- [x] Checked schema for all modified table for columns that will
auto-update timestamps during migration.
- [x] Confirmed that updating the timestamps is acceptable, and will not
cause unwanted side effects.
- [x] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
## New Fleet configuration settings
- [ ] Setting(s) is/are explicitly excluded from GitOps
If you didn't check the box above, follow this checklist for
GitOps-enabled settings:
- [x] Verified that the setting is exported via `fleetctl
generate-gitops`
- [x] Verified the setting is documented in a separate PR to [the GitOps
documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485)
- [x] Verified that the setting is cleared on the server if it is not
supplied in a YAML file (or that it is documented as being optional)
- [x] Verified that any relevant UI is disabled when GitOps mode is
enabled
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Apple Platform SSO (PSSO) for macOS with device registration,
sign-in, and public discovery (JWKS + Apple app-site association)
protected by single-use nonces.
* Added Apple account provisioning (Platform SSO password sync)
configuration with masked client-secret handling and GitOps support.
* Added a host-scoped PSSO device registration token variable for Apple
MDM profile generation.
* **Bug Fixes**
* Fixed macOS packaging to correctly build, embed, and sign the Platform
SSO extension.
* Resetting device Apple MDM data now also clears stored PSSO enrollment
records.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Magnus Jensen <magnus@fleetdm.com>
**Related issue:** Resolves#43379
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
## Testing
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Style**
* Updated Windows MDM enrollment option labels from “Automatic/Manual”
to “Fleet agent-driven/End user-driven” and refreshed the related
on-page description/help text.
* Adjusted radio help-text spacing and added styling for label
formatting on the Windows MDM settings page.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves #
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [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), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops
- [x] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [x] Added/updated automated tests
- [x] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for Apple declarative management declarations on both
System and User channels.
* User-scoped declarations are now delivered, reconciled, and
acknowledged independently from device-scoped declarations.
* **Bug Fixes**
* Prevented scope-mixing so declaration items and status updates no
longer affect the wrong channel.
* Tightened reconciliation behavior for scope changes and missing user
channels.
* **Tests**
* Expanded coverage for channel isolation, payload scope
parsing/validation, and correct delivery payload behavior (including
stripping the payload-scope field from delivered JSON).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
RachelElysia