mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
166b0d1573
All of our Linux applications have a soft-dependency on systemd. That is, in the default configuration, we expect systemd to be present on the machine. The only exception here are the docker containers for Headless Client and Gateway. For the GUI client in particular, systemd is a hard-dependency in order to control DNS on the system which we do via `systemd-resolved`. To secure the communication between the GUI client and its tunnel process, we automatically create a group called `firezone-client` to which the user gets added. All members of the group are allowed to access the unix socket which is used for IPC between the two processes. Membership in this group is also a prerequisite for accessing any of the configuration files. On the first launch of the GUI client on a Linux system, this presents a problem. For group membership changes to take the effect, the user needs to reboot. We say that in the documentation but it is unclear whether all users will read that thoroughly enough. To help the user, the GUI client checks for membership of the current user in the group and alerts the user via a dialog box if that isn't the case. This would all be fine if it would actually work. Unfortunately, that check ends up being too late in the process. If we aren't a member of the group, we cannot read the device ID and bail early, thus never reaching the check and terminating the process without any dialog box or user-visible error. We could attempt to fix this by shuffling around some of the startup init code. That is a sub-optimal solution however because it a) may get broken again in the future and b) it means we have to delay initialisation of telemetry until a much later point. Given that this is only a problem on Linux, a better solution is to simply not rely on the disk-based device ID at all. Instead, we can integrate with systemd and deterministically derive a device ID from the unique machine ID and a randomly chosen "app ID". For backwards-compatibility reasons, the disk-based device ID is still prioritised. For all new installs however, we will use the one based on `/etc/machine-id`.
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.