fleet

26,791 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Andrey Kizimenko	8c6bedf661	Hangar: local dev environment — multi-server + SCEP, MDM assets & TUF tabs (#49454 ) <!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> Related issue: N/A — internal developer tooling (`tools/hangar`). ## Summary Fleet Hangar is the local dev-environment control panel (`tools/hangar`, Go + Wails). This PR expands it into a broader local dev-services toolkit for contributors/QA: - Multi-server support — run up to 3 independent local Fleet servers in parallel, each on its own git worktree, offset ports, and docker compose project (server switcher + server-scoped Server/Logs/Database/Git tabs). - SCEP tab — run local SCEP CA servers using the in-repo `server/mdm/scep/cmd/scepserver` (built once to a cached binary). Per-depot profiles, `ca -init`, concurrent start/stop with live logs, and one-click copy for the SCEP URL / challenge / thumbprint (parsed from `ca.pem`). - MDM assets tab — run `tools/mdm/assets export` from saved configs; results list each written file with copy-contents/path + size + timestamp, plus the `FLEET_MDM_APPLE_` env block. - TUF tab* — drive `tools/tuf/test/main.sh` from platform checkboxes. Hangar runs the file-server itself (`SKIP_SERVER=1`) so `fleetctl package` can reach the TUF URL during packaging; streams live build output; shows ngrok tunnel + TUF-server prerequisites; and offers kill-server + delete-assets. - Supporting work — DB backups in app-data + cross-server restore; ngrok live public-URL links + stale-tunnel heal; per-server open-in-browser; Settings → Troubleshoot cards to reap stray `scepserver`/TUF-server processes and delete `test_tuf`. Opening as a draft for transparency. All changes are confined to `tools/hangar/`; nothing touches the Fleet server, agent, or any shipped code. Architecture: each tab is an `internal/<feature>` package (pure, unit-tested logic) behind a thin `services/<feature>_service.go` Wails adapter, reached from the UI as `api.`. Long-running processes go through the shared process engine; everything builds from / runs against the primary repo (Server 1). # Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] Changes file added for user-visible changes — N/A: `tools/hangar` is a developer tool and is not part of a Fleet release. - [x] Input data is properly validated, `SELECT ` is avoided, SQL injection is prevented, JS inline code is prevented, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - External commands (`scepserver`, `go run ./tools/mdm/assets`, `bash main.sh`, the backup/restore `docker` invocation) are spawned with discrete argv slices via the process engine — no shell string interpolation — so user-supplied values (challenge, enroll secret, depot/dir paths) can't inject. Backup names are validated to `[A-Za-z0-9._-]`; server-id path segments are sanitized to `[A-Za-z0-9_-]` (no traversal); TUF asset deletion is scoped to `<repo>/test_tuf`. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - Binary builds / one-shot commands run under bounded `context.WithTimeout`; the TUF-server readiness and ngrok local-API fetches use short HTTP timeouts; no unbounded loops or retries were added. - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI — N/A: no Fleet server API changes. ## Testing - [x] Added/updated automated tests - Go unit tests across the new packages: `settings` (SCEP profiles, TUF config, `migrate` incl. the empty-`servers` case), `scep` (depot/CA parsing, arg builders), `mdmassets` (export args, `wrote … in …` parsing, config persistence), `tuf` (env building, file-server args, asset delete), and `troubleshoot` (live-PID filtering) — plus the existing backups logic. - `tsc --noEmit` clean and `task build` green. - [ ] Where appropriate, automated tests simulate multiple hosts and test for host isolation — N/A. - [x] QA'd all new/changed functionality manually (ongoing local testing of all three tabs). ## Database migrations N/A — no database migrations. ## New Fleet configuration settings N/A — no Fleet server configuration settings (Hangar stores its own settings in app-data). ## fleetd/orbit/Fleet Desktop N/A — no fleetd/orbit/Fleet Desktop changes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Multi-server support (up to three) with server switcher, server-scoped health/logs, and server-scoped Docker Compose controls. * New Servers settings section plus per-server configuration (including ports/compose project) and server-aware start/stop/quit flows. * New SCEP, MDM Assets, and TUF tabs for managing profiles/assets and discovering ngrok URLs. * Git worktree listing/creation/removal. * Centralized, server-scoped database backup management. * Bug Fixes * Improved process discovery to skip dead or racing entries and avoid duplicate docker-compose-up display. * Self-healing pruning of stale ngrok tunnel selections. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-08-05 17:48:34 -05:00
Andrey Kizimenko	a13cd2c373	Remove dead Wails-template scaffolding from tools/hangar (#48126 ) Related issue: N/A — follow-up cleanup to #46406 (Add Hangar). ## What & why Fleet Hangar is a macOS-only, GUI-only dev tool built natively, but the Wails v3 project template left behind config for modes/platforms it never uses. None of it was referenced by CI, scripts, or the documented build flow (`dev` / `build` / `package` / `dist` / `sign`). Removed: - Server-mode + Docker tasks (`build:server`, `run:server`, `build:docker`, `run:docker`, `setup:docker`) in the root and common Taskfiles. They point at `build/docker/Dockerfile.{server,cross}`, which don't exist, and there is no `server` build tag anywhere in the Go code. - Docker cross-compilation in `build/darwin` (`build:docker`, `CROSS_IMAGE`, the `build:universal` `lipo:go` fallback). `build:` and `build:universal` now call the native macOS paths directly. - iOS tasks (`ios:device:list`, `ios:run:device`) — no iOS project exists. - `frontend:vendor:puppertino` — fetched CSS into `frontend/public/puppertino` and rewrote `index.html`; none of those targets exist and no task called it. - `.gitignore` lines for `build/linux` and `build/windows` (neither dir exists). - `config.yml` template placeholders (commented `ios` / `fileAssociations` blocks, the `My Other Data` `other` entry). The darwin signing vars (`SIGN_IDENTITY`, `KEYCHAIN_PROFILE`, `ENTITLEMENTS`) are now declared as empty strings instead of comments, so removing `CROSS_IMAGE` doesn't leave `vars:` as a null mapping (which the Taskfile schema rejects). Behavior is unchanged — the `sign:` preconditions still guard on non-empty values. Net: 11 insertions, 280 deletions across 5 files. No change to the real build flow. ## Testing - Verified with `task build` — exit 0, produces `bin/fleet-hangar` (arm64 Mach-O). - `task --list-all` parses all three Taskfiles with no schema errors and no dangling task references. ## Checklist - [x] QA'd manually (`task build`) No changes file: `tools/hangar` is an internal dev tool, so this is not a user-visible change. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Chores * Simplified build configuration by removing Puppertino CSS integration and server/Docker/iOS build tasks. * Updated development task with improved process management to prevent orphaned processes. * Streamlined macOS build process to native-only implementation, removing cross-compilation support. * Cleaned up build configuration files and project ignore patterns. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-06-23 17:27:13 -05:00
Andrey KizimenkoandGeorge Karr	0f9af89a93	Add Hangar: Go/Wails desktop control panel for the Fleet dev environment (#46406 ) ## Summary Adds `tools/hangar` — a macOS desktop control panel for working on Fleet locally: branch management, `fleet serve` orchestration, log tail, dev MySQL backup/restore, `fleetctl`, GitOps, and `osquery-perf`, all in one window. Built with Go + [Wails 3](https://v3alpha.wails.io) — the backend is plain Go (`os/exec`, `syscall`, goroutines) so Fleet engineers can contribute to it; only the desktop shell is Wails. The `internal/` packages are pure and unit-tested. ### History note Hangar started as a Rust/Tauri app. It was ported to Go, and the Go port is now the canonical `tools/hangar`. The original Rust/Tauri implementation has been removed from the monorepo (preserved in a standalone repo) — so although this branch's earlier commits add and then replace the Rust app, the net diff is just the Go app at `tools/hangar`. The bundle identifier is `com.fleetdm.fleet-hangar`, matching the original app so existing settings carry over. # Checklist for submitter - [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 > No `changes/` file: `tools/` is contributor tooling, not a user-visible Fleet change. No DB migrations, no Fleet config settings, no fleetd/orbit changes. ## Testing - [x] Added/updated automated tests (Go unit tests across `internal/`, including a path-traversal regression for backup deletion) - [x] QA'd all new/changed functionality manually ## Test plan - [x] `cd tools/hangar && task dev` launches the app (live-reload) - [x] `task build` produces `bin/fleet-hangar`; `go test ./...` is green - [x] First-run gate discovers a local Fleet clone and runs dep checks - [x] Server tab can run the build chain and start `fleet serve` - [x] Git tab branch search finds an older branch (e.g. a stale `qa-`) by name <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Introduced Fleet Hangar, a comprehensive desktop application for Fleet development workflows, providing unified controls for server/database management, git operations, configuration, logging, and troubleshooting. * Added database backup management with metadata tracking. * Integrated process orchestration for development services (Docker, ngrok, Python). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: George Karr <georgekarrv@users.noreply.github.com>	2026-06-23 15:45:23 -05:00

Author

SHA1

Message

Date

Andrey Kizimenko

8c6bedf661

Hangar: local dev environment — multi-server + SCEP, MDM assets & TUF tabs (#49454 )

<!-- Add the related story/sub-task/bug number, like Resolves #123, or
remove if NA -->
**Related issue:** N/A — internal developer tooling (`tools/hangar`).

## Summary

Fleet Hangar is the local dev-environment control panel (`tools/hangar`,
Go + Wails). This PR expands it into a broader **local dev-services**
toolkit for contributors/QA:

- **Multi-server support** — run up to 3 independent local Fleet servers
in parallel, each on its own git worktree, offset ports, and docker
compose project (server switcher + server-scoped
Server/Logs/Database/Git tabs).
- **SCEP tab** — run local SCEP CA servers using the in-repo
`server/mdm/scep/cmd/scepserver` (built once to a cached binary).
Per-depot profiles, `ca -init`, concurrent start/stop with live logs,
and one-click copy for the SCEP URL / challenge / thumbprint (parsed
from `ca.pem`).
- **MDM assets tab** — run `tools/mdm/assets export` from saved configs;
results list each written file with copy-contents/path + size +
timestamp, plus the `FLEET_MDM_APPLE_*` env block.
- **TUF tab** — drive `tools/tuf/test/main.sh` from platform checkboxes.
Hangar runs the file-server itself (`SKIP_SERVER=1`) so `fleetctl
package` can reach the TUF URL during packaging; streams live build
output; shows ngrok tunnel + TUF-server prerequisites; and offers
kill-server + delete-assets.
- **Supporting work** — DB backups in app-data + cross-server restore;
ngrok live public-URL links + stale-tunnel heal; per-server
open-in-browser; Settings → Troubleshoot cards to reap stray
`scepserver`/TUF-server processes and delete `test_tuf`.

Opening as a **draft for transparency**. All changes are confined to
`tools/hangar/`; nothing touches the Fleet server, agent, or any shipped
code.

**Architecture:** each tab is an `internal/<feature>` package (pure,
unit-tested logic) behind a thin `services/<feature>_service.go` Wails
adapter, reached from the UI as `api.*`. Long-running processes go
through the shared process engine; everything builds from / runs against
the primary repo (Server 1).

# Checklist for submitter

If some of the following don't apply, delete the relevant line.

- [ ] Changes file added for user-visible changes — N/A: `tools/hangar`
is a developer tool and is not part of a Fleet release.

- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented, JS inline code is prevented, and untrusted data
interpolated into shell scripts/commands is validated against shell
metacharacters.
- External commands (`scepserver`, `go run ./tools/mdm/assets`, `bash
main.sh`, the backup/restore `docker` invocation) are spawned with
discrete argv slices via the process engine — no shell string
interpolation — so user-supplied values (challenge, enroll secret,
depot/dir paths) can't inject. Backup names are validated to
`[A-Za-z0-9._-]`; server-id path segments are sanitized to
`[A-Za-z0-9_-]` (no traversal); TUF asset deletion is scoped to
`<repo>/test_tuf`.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops
- Binary builds / one-shot commands run under bounded
`context.WithTimeout`; the TUF-server readiness and ngrok local-API
fetches use short HTTP timeouts; no unbounded loops or retries were
added.
- [ ] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI — N/A: no Fleet server API
changes.

## Testing

- [x] Added/updated automated tests
- Go unit tests across the new packages: `settings` (SCEP profiles, TUF
config, `migrate` incl. the empty-`servers` case), `scep` (depot/CA
parsing, arg builders), `mdmassets` (export args, `wrote … in …`
parsing, config persistence), `tuf` (env building, file-server args,
asset delete), and `troubleshoot` (live-PID filtering) — plus the
existing backups logic.
  - `tsc --noEmit` clean and `task build` green.
- [ ] Where appropriate, automated tests simulate multiple hosts and
test for host isolation — N/A.
- [x] QA'd all new/changed functionality manually (ongoing local testing
of all three tabs).

## Database migrations

N/A — no database migrations.

## New Fleet configuration settings

N/A — no Fleet server configuration settings (Hangar stores its own
settings in app-data).

## fleetd/orbit/Fleet Desktop

N/A — no fleetd/orbit/Fleet Desktop changes.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Multi-server support (up to three) with server switcher, server-scoped
health/logs, and server-scoped Docker Compose controls.
* New **Servers** settings section plus per-server configuration
(including ports/compose project) and server-aware start/stop/quit
flows.
* New **SCEP**, **MDM Assets**, and **TUF** tabs for managing
profiles/assets and discovering ngrok URLs.
  * Git worktree listing/creation/removal.
  * Centralized, server-scoped database backup management.
* **Bug Fixes**
* Improved process discovery to skip dead or racing entries and avoid
duplicate docker-compose-up display.
  * Self-healing pruning of stale ngrok tunnel selections.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

2026-08-05 17:48:34 -05:00

Andrey Kizimenko

a13cd2c373

Remove dead Wails-template scaffolding from tools/hangar (#48126 )

**Related issue:** N/A — follow-up cleanup to #46406 (Add Hangar).

## What & why

Fleet Hangar is a macOS-only, GUI-only dev tool built natively, but the
Wails v3 project template left behind config for modes/platforms it
never uses. None of it was referenced by CI, scripts, or the documented
build flow (`dev` / `build` / `package` / `dist` / `sign`).

Removed:
- **Server-mode + Docker tasks** (`build:server`, `run:server`,
`build:docker`, `run:docker`, `setup:docker`) in the root and common
Taskfiles. They point at `build/docker/Dockerfile.{server,cross}`, which
don't exist, and there is no `server` build tag anywhere in the Go code.
- **Docker cross-compilation** in `build/darwin` (`build:docker`,
`CROSS_IMAGE`, the `build:universal` `lipo:go` fallback). `build:` and
`build:universal` now call the native macOS paths directly.
- **iOS tasks** (`ios:device:list`, `ios:run:device`) — no iOS project
exists.
- **`frontend:vendor:puppertino`** — fetched CSS into
`frontend/public/puppertino` and rewrote `index.html`; none of those
targets exist and no task called it.
- **`.gitignore`** lines for `build/linux` and `build/windows` (neither
dir exists).
- **`config.yml`** template placeholders (commented `ios` /
`fileAssociations` blocks, the `My Other Data` `other` entry).

The darwin signing vars (`SIGN_IDENTITY`, `KEYCHAIN_PROFILE`,
`ENTITLEMENTS`) are now declared as empty strings instead of comments,
so removing `CROSS_IMAGE` doesn't leave `vars:` as a null mapping (which
the Taskfile schema rejects). Behavior is unchanged — the `sign:`
preconditions still guard on non-empty values.

Net: **11 insertions, 280 deletions** across 5 files. No change to the
real build flow.

## Testing

- Verified with `task build` — exit 0, produces `bin/fleet-hangar`
(arm64 Mach-O).
- `task --list-all` parses all three Taskfiles with no schema errors and
no dangling task references.

## Checklist

- [x] QA'd manually (`task build`)

No changes file: `tools/hangar` is an internal dev tool, so this is not
a user-visible change.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
* Simplified build configuration by removing Puppertino CSS integration
and server/Docker/iOS build tasks.
* Updated development task with improved process management to prevent
orphaned processes.
* Streamlined macOS build process to native-only implementation,
removing cross-compilation support.
  * Cleaned up build configuration files and project ignore patterns.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

2026-06-23 17:27:13 -05:00

Andrey KizimenkoandGeorge Karr

0f9af89a93

Add Hangar: Go/Wails desktop control panel for the Fleet dev environment (#46406 )

## Summary

Adds `tools/hangar` — a macOS desktop control panel for working on Fleet
locally: branch management, `fleet serve` orchestration, log tail, dev
MySQL backup/restore, `fleetctl`, GitOps, and `osquery-perf`, all in one
window.

Built with **Go + [Wails 3](https://v3alpha.wails.io)** — the backend is
plain Go (`os/exec`, `syscall`, goroutines) so Fleet engineers can
contribute to it; only the desktop shell is Wails. The `internal/`
packages are pure and unit-tested.

### History note
Hangar started as a Rust/Tauri app. It was ported to Go, and **the Go
port is now the canonical `tools/hangar`**. The original Rust/Tauri
implementation has been removed from the monorepo (preserved in a
standalone repo) — so although this branch's earlier commits add and
then replace the Rust app, the net diff is just the Go app at
`tools/hangar`. The bundle identifier is `com.fleetdm.fleet-hangar`,
matching the original app so existing settings carry over.

# Checklist for submitter

- [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

> No `changes/` file: `tools/` is contributor tooling, not a
user-visible Fleet change. No DB migrations, no Fleet config settings,
no fleetd/orbit changes.

## Testing

- [x] Added/updated automated tests (Go unit tests across `internal/`,
including a path-traversal regression for backup deletion)
- [x] QA'd all new/changed functionality manually

## Test plan
- [x] `cd tools/hangar && task dev` launches the app (live-reload)
- [x] `task build` produces `bin/fleet-hangar`; `go test ./...` is green
- [x] First-run gate discovers a local Fleet clone and runs dep checks
- [x] Server tab can run the build chain and start `fleet serve`
- [x] Git tab branch search finds an older branch (e.g. a stale `qa-*`)
by name


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Introduced Fleet Hangar, a comprehensive desktop application for Fleet
development workflows, providing unified controls for server/database
management, git operations, configuration, logging, and troubleshooting.
  * Added database backup management with metadata tracking.
* Integrated process orchestration for development services (Docker,
ngrok, Python).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: George Karr <georgekarrv@users.noreply.github.com>

2026-06-23 15:45:23 -05:00