mirror of https://github.com/outbackdingo/firezone.git synced 2026-01-27 18:18:55 +00:00

Files

Thomas Eizinger 2a46fce574 refactor(connlib): remove Result return values from callbacks (#4158 )

Currently, an error returned by `Tunnel::poll_next_event` is only
logged. In other words, they are never fatal. This creates a tricky to
understand relationship on what kind of errors should be returned from
callbacks. Because connlib is used on multiple operating systems, it has
no idea how fatal a particular error is.

This PR removes all of these `Result` return values with the following
consequences:

- For Android, we now panic when a callback fails. This is a slight
change in behaviour. I believe that previously, any exception thrown by
a callback into Android was caught and returned as an error. Now, we
panic because in the FFI layer, we don't have any information on how
fatal the error is. For non-fatal errors, the Android app should simply
not throw an exception. The panics will cause the connlib task to be
shut down which triggers an `on_disconnect`.
- For Swift, there is no behaviour change. The FFI layer already did not
support `Result`s for those callbacks. I don't know how exceptions from
Swift are translated across the FFI layer but there is no change to what
we had before.
- For the Tauri client:
- I chose to log errors on ERROR level and continue gracefully for the
DNS resolvers.
- We panic in case the controller channel is full / closed. That should
really never happen in practice though unless we are currently shutting
down the app.

Resolves: #4064.

2024-03-20 02:09:20 +00:00

docs

docs(linux): document default DNS setup on Debian 12 and Ubuntu 20.04 (#3668 )

2024-02-16 18:20:45 +00:00

src

refactor(connlib): remove Result return values from callbacks (#4158 )

2024-03-20 02:09:20 +00:00

Cargo.toml

refactor(connlib): don't start a runtime as part of Session (#4119 )

2024-03-14 00:06:29 +00:00

README.md

ci: document and fix a couple things for local Docker testing (#3672 )

2024-02-17 16:16:39 +00:00

README.md

linux-client

This crate houses the Firezone linux client.

Building

Assuming you have Rust installed, you can build the Linux client from a Linux host with:

cargo build --release --bin firezone-linux-client

You should then find a binary in target/release/firezone-linux-client.

The releases on Github are built with musl. To build this way, use:

rustup target add x86_64-unknown-linux-musl
sudo apt-get install musl-tools
cargo build --release --bin firezone-linux-client --target x86_64-unknown-linux-musl

Running

To run the Linux client:

Generate a new Service account token from the "Actors -> Service Accounts" section of the admin portal and save it in your secrets manager. The Firezone Linux client requires a service account at this time.
Ensure the FIREZONE_TOKEN=<service_account_token> environment variable is set securely in your client's shell environment. The client requires this variable at startup.
Set FIREZONE_ID to a unique string to identify this client in the portal, e.g. export FIREZONE_ID=$(uuidgen). The client requires this variable at startup.

Set LOG_DIR to a suitable directory for writing logs

export LOG_DIR=/tmp/firezone-logs
mkdir $LOG_DIR

Now, you can start the client with:

./firezone-linux-client

If you're running as an unprivileged user, you'll need the CAP_NET_ADMIN capability to open /dev/net/tun. You can add this to the client binary with:

sudo setcap 'cap_net_admin+eip' /path/to/firezone-linux-client