fleet/tools/osquery
Copilot 0a9537d2e3
Update RustFS Docker image to 1.0.0-alpha.73 (#37099)
**Related issue:** Resolves #

## Description

Bumps RustFS image version from `1.0.0-alpha.72` to `1.0.0-alpha.73` in
docker-compose configurations.

**Files updated:**
- `docker-compose.yml` - root development environment
- `tools/osquery/in-a-box/docker-compose.yml` - Fleet preview
environment

RustFS provides S3-compatible object storage for file carving and
software installer features in development/testing environments.

# 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)
- [ ] 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))

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> ## Summary
> Update RustFS Docker image references from version `1.0.0-alpha.72` to
the latest version `1.0.0-alpha.73` in all docker-compose configuration
files.
> 
> ## Files to Update
> Based on the code search, the following files need to be updated:
> 
> 1. `docker-compose.yml` (root level)
> 2. `docs/solutions/docker-compose/docker-compose.yml`
> 3. `tools/osquery/in-a-box/docker-compose.yml`
> 
> ## Changes Required
> For each file, update the RustFS image reference:
> - **FROM:** `rustfs/rustfs:1.0.0-alpha.72`
> - **TO:** `rustfs/rustfs:1.0.0-alpha.73`
> 
> ## Context
> RustFS is used as an S3-compatible object storage backend in Fleet's
development and testing environments. Keeping the version up-to-date
ensures we have the latest bug fixes and improvements from the RustFS
project.
> 
> ## Verification
> After making these changes, verify that:
> 1. All docker-compose files can start successfully
> 2. The S3-compatible storage functionality works as expected
> 3. File carving and software installer storage features continue to
work properly


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created as a result of the following prompt from
Copilot chat.*
> ## Summary
> Update RustFS Docker image references from version `1.0.0-alpha.72` to
the latest version `1.0.0-alpha.73` in all docker-compose configuration
files.
> 
> ## Files to Update
> Based on the code search, the following files need to be updated:
> 
> 1. `docker-compose.yml` (root level)
> 2. `docs/solutions/docker-compose/docker-compose.yml`
> 3. `tools/osquery/in-a-box/docker-compose.yml`
> 
> ## Changes Required
> For each file, update the RustFS image reference:
> - **FROM:** `rustfs/rustfs:1.0.0-alpha.72`
> - **TO:** `rustfs/rustfs:1.0.0-alpha.73`
> 
> ## Context
> RustFS is used as an S3-compatible object storage backend in Fleet's
development and testing environments. Keeping the version up-to-date
ensures we have the latest bug fixes and improvements from the RustFS
project.
> 
> ## Verification
> After making these changes, verify that:
> 1. All docker-compose files can start successfully
> 2. The S3-compatible storage functionality works as expected
> 3. File carving and software installer storage features continue to
work properly

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: iansltx <472804+iansltx@users.noreply.github.com>
Co-authored-by: Ian Littman <iansltx@gmail.com>
2025-12-11 10:59:46 -06:00
..
in-a-box Update RustFS Docker image to 1.0.0-alpha.73 (#37099) 2025-12-11 10:59:46 -06:00
.env Default osquery container version to latest in test docker-compose (#2152) 2019-11-17 14:10:11 -08:00
docker-compose.linux-overrides.yml Update development docker-compose.yml to use osquery 4.9.0 (#1410) 2021-07-17 12:40:56 -07:00
docker-compose.yml Update development docker-compose.yml to use osquery 4.9.0 (#1410) 2021-07-17 12:40:56 -07:00
example_osquery.flags update file carver block size and various MySQL references (#9625) 2023-02-02 01:01:34 -05:00
fleet.crt Remove kolide types and packages from backend (#974) 2021-06-06 15:07:29 -07:00
fleet.key Remove kolide types and packages from backend (#974) 2021-06-06 15:07:29 -07:00
README.md Quick spelling/grammar fixes (#23859) 2024-11-18 13:36:59 -06:00

Configs and Tools for Testing Fleet

The files in this directory are intended to assist with Fleet development.

  • docker-compose.yml: This docker-compose file helps with starting osqueryd instances for testing Fleet. More on this below.

  • example_osquery.conf: An example osquery config file that sets up basic configuration for distributed queries.

  • example_osquery.flags: An example osquery flagfile setting the config options that must be loaded before the full JSON config.

  • fleet.crt & fleet.key: Self-signed SSL certificate & key useful for testing locally with osqueryd. Works with the domain host.docker.internal (exposed within docker containers as the host's IP). Should never be used in production.

Testing with containerized osqueryd

Using Docker enables us to rapidly spin up and down pre-configured osqueryd instances for testing Fleet. Currently we have container images for Ubuntu14 and Centos7 osquery installations.

Setup

Docker and docker-compose are the only dependencies. The necessary container images will be pulled from Docker Cloud on first run.

Set the environment variable ENROLL_SECRET to the value of your Fleet enroll secret (available on the manage hosts page, or via fleetctl get enroll-secret).

(Optionally) Set FLEET_SERVER if you want to connect to a fleet server besides host.docker.internal:8080.

Running osqueryd

The osqueryd instances are configured to use the TLS plugins at host.docker.internal:8080. Using the example_osquery.flags in this directory should configure Fleet with the appropriate settings for these osqueryd containers to connect.

To start one instance each of Centos 6, Centos 7, Ubuntu 14, and Ubuntu 16 osqueryd, use:

docker-compose up

Linux users should use the overrides (which add DNS entries for host.docker.internal based on the DOCKER_HOST env var):

docker-compose -f docker-compose.yml -f docker-compose.linux-overrides.yml up

The logs will be displayed on the host shell. Note that docker-compose up will reuse containers (so the state of osqueryd will be maintained across calls). To remove the containers and start from a fresh state on the next call to up, use:

docker-compose rm

If you want to only start one instance of osqueryd, use:

docker-compose run ubuntu14-osquery

or

docker-compose run centos7-osquery

Note that docker-compose run does not save state between calls.

This system can also be used to start many instances of osqueryd running in containers on the same host:

docker-compose up -d && docker-compose up --scale ubuntu14-osquery=20

To stop the containers when running in detached mode like this, use:

docker-compose stop

And to delete the containers when wanting a fresh state, or when finished testing, use:

docker-compose rm

We have had no trouble running up to 100 containerized osqueryd instances on a single processor core and about 1GB of RAM.

Generating an osqueryd core file

The docker containers are configured to allow core files to be generated if osqueryd crashes for some reason. You can attach to the container hosting the errant osqueryd instance, install gdb and use it to read the core file to find out where the crash occurred. The other scenario where you might find a core dump useful is if osqueryd stops responding. In this case you can generate a core dump using the following instructions.

  1. Open a shell session on a container
docker exec -t -i <container id> /bin/bash
  1. Find the process ID of osqueryd
ps aux

There will be two osqueryd processes, you'll probably be interested in the child process (the one with the higher pid)

  1. Send a signal to the process to core dump
kill -3 <pid>

The core file should be in your current working directory on the container.