Scott Gress
df44a9342e
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #43484 # Details Apple Silicon Macs were being forced down the Wine+local-wix-dir path because the fleetdm/wix:latest image was deemed unreliable on arm64 in Jan 2024. Docker Desktop's amd64 emulation has matured since -- the image builds both amd64 and arm64 MSIs on arm64 macOS successfully. This PR: - Drops the arm64-forces-Wine guard in BuildMSI so the Docker path is the default on every macOS arch when --local-wix-dir isn't provided. - Drops the macOS "Install wine and wix" + "Build MSI on macOS (using local Wix)" CI steps. The ubuntu-latest matrix entry already exercises the Docker path, and the install-wine.sh flow is brittle against Gcenx release churn and homebrew-cask deprecation. - Updates the install-wine.sh script to fail and output a message indicating that Docker should be used, or else Wine installed manually. ``` ============================================================ This script no longer installs Wine. ============================================================ Wine is no longer required to build Windows (.msi) packages on macOS. fleetctl package now uses Docker by default on all macOS architectures. RECOMMENDED: install Docker Desktop https://docs.docker.com/get-docker If you cannot use Docker and still need to build MSIs with Wine on macOS see the upstream WineHQ wiki for installation instructions: https://gitlab.winehq.org/wine/wine/-/wikis/MacOS Automatic Wine installation via Homebrew is no longer attempted here because the wine-stable cask is deprecated and upstream Wine releases have caused repeated breakage. ``` - Retains the wix auto-download helper (downloadAndExtractZip, extractZipFile, wixDownload) for backwards-compatibility when Docker isn't detected, with a deprecation warning. The Wine + --local-wix-dir path remains available for macOS users who opt into it, but is no longer documented. See #43484. # 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. ## Testing - [X] Added/updated automated tests - Dropped MacOS packaging tests. The Ubuntu test already exercises the Docker path that MacOS now uses. - [X] QA'd all new/changed functionality manually - Built and installed both amd64 and arm64 .msi packages successfully <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * MSI packages on macOS now build using Docker by default, removing the Wine dependency. * **Documentation** * Updated macOS setup guidance: Docker Desktop is now required for MSI packaging instead of Wine. * **Chores** * Simplified Wine-related helper scripts and removed outdated installation logic. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Orbit is a lightweight osquery installer and autoupdater. With Orbit, it's easy to deploy osquery, manage configurations, and keep things up-to-date. Orbit eases the deployment of osquery connected with a Fleet server, and is a (near) drop-in replacement for osquery in a variety of deployment scenarios.
Orbit is the recommended agent for Fleet. But Orbit can be used with or without Fleet, and Fleet can be used with or without Orbit.
How to build from source
To build orbit we use goreleaser.
For reference, here are the build configuration files:
- Goreleaser github workflow
- Goreleaser configuration file for each platform:
Following are the commands to build in case you can't use goreleaser.
IMPORTANT: We recommend you build orbit natively and not cross compile to avoid any build or runtime errors.
macOS
CGO_ENABLED=1 \
CODESIGN_IDENTITY=$CODESIGN_IDENTITY \
ORBIT_VERSION=$VERSION \
ORBIT_BINARY_PATH=./orbit-macos \
go run ./orbit/tools/build/build.go
Windows
CGO_ENABLED=0 \
GOOS=windows \
GOARCH=amd64 \
go build \
-trimpath \
-ldflags="-s -w -X github.com/fleetdm/fleet/v4/orbit/pkg/build.Version=$VERSION \
-X github.com/fleetdm/fleet/v4/orbit/pkg/build.Commit=$COMMIT \
-X github.com/fleetdm/fleet/v4/orbit/pkg/build.Date=$DATE" \
-o ./orbit.exe ./orbit/cmd/orbit
Linux
CGO_ENABLED=1 \
GOOS=linux \
GOARCH=amd64 \
go build \
-trimpath \
-ldflags="-s -w -X github.com/fleetdm/fleet/v4/orbit/pkg/build.Version=$VERSION \
-X github.com/fleetdm/fleet/v4/orbit/pkg/build.Commit=$COMMIT \
-X github.com/fleetdm/fleet/v4/orbit/pkg/build.Date=$DATE" \
-o ./orbit-linux ./orbit/cmd/orbit
Bugs
To report a bug or request a feature, create an issue in the fleet GitHub repository.
Orbit Development
Run Orbit From Source
To execute orbit from source, use the following commands:
Connect to a Fleet server
Modify the fleet-url and enroll-secret as appropriate:
go run github.com/fleetdm/fleet/v4/orbit/cmd/orbit \
--dev-mode \
--disable-updates \
--root-dir /tmp/orbit \
--fleet-url https://localhost:8080 \
--insecure \
--enroll-secret Pz3zC0NMDdZfb3FtqiLgwoexItojrYh/ \
-- --verbose
Using a custom flagfile
With a flagfile.txt for osqueryd:
go run github.com/fleetdm/fleet/v4/orbit/cmd/orbit \
--dev-mode \
--disable-updates \
--root-dir /tmp/orbit \
-- --flagfile=flagfile.txt --verbose
Open an interactive shell to run SQL
This can be useful for building/testing extension tables:
go run github.com/fleetdm/fleet/v4/orbit/cmd/orbit \
--dev-mode \
--disable-updates \
--root-dir /tmp/orbit \
shell
Generate Installer Packages from Orbit Source
The fleetctl package command generates installers by fetching the targets/executables from a TUF repository.
To generate an installer that contains an Orbit built from source you need to setup a local TUF repository.
The following document explains how you can generate a TUF repository, and installers that use it tools/tuf/test.
FAQs
How does Orbit compare with Kolide Launcher?
Orbit is inspired by the success of Kolide Launcher, and approaches a similar problem domain with new strategies informed by the challenges encountered in real world deployments. Orbit does not share any code with Launcher.
- Both Orbit and Launcher use The Update Framework specification for managing updates. Orbit utilizes the official go-tuf library, while Launcher has it's own implementation of the specification.
- Orbit can be deployed as a (near) drop-in replacement for osquery, supporting full customization of the osquery flags. Launcher heavily manages the osquery flags making deployment outside of Fleet or Kolide's SaaS difficult.
- Orbit prefers the battle-tested plugins of osquery. Orbit uses the built-in logging, configuration, and live report plugins, while Launcher uses custom implementations.
- Orbit prefers the built-in osquery remote APIs. Launcher utilizes a custom gRPC API that has led to issues with character encoding, load balancers/proxies, and request size limits.
- Orbit encourages use of the osquery performance Watchdog, while Launcher disables the Watchdog.
Additionally, Orbit aims to tackle problems out of scope for Launcher:
- Configure updates via release channels, providing more granular control over agent versioning.
- Manage osquery startup flags from a remote (Fleet) server.
- Support for deploying and updating osquery extensions.
- Manage osquery versions from a remote (Fleet) server.
Is Orbit Free?
Yes! Orbit is licensed under an MIT license and all uses are encouraged.
How does orbit update osquery? And how do the stable and edge channels get triggered to update osquery on a self hosted Fleet instance?
Orbit uses a configurable update server. We expect that many folks will just use the update server we manage (similar to what Kolide does with Launcher's update server). We are also offering tooling for self-managing an update server as part of Fleet Premium (the subscription offering).
Community
Chat
Please join us in the #fleet channel on osquery Slack.
