```[tasklist]
### Before merging
- [x] Make sure the service auto-starts
- [x] Make the process idle and report its status to Windows properly using https://github.com/mullvad/windows-service-rs
- [x] DRY log dir code
- [x] Figure out where service logs will go and how the GUI will zip them
- [x] Make sure the service gets a shut down signal from Windows (this is hard to catch in the Tauri GUI)
- [x] Make sure the service restarts when Firezone is updated
- [x] Make sure the service is stopped and un-installed when Firezone is un-installed
- [x] Add test to install the MSI and check that the service runs
- [x] (will move to another PR) ~~Clean up function names~~
- [x] Make sure the Linux GUI was not broken by refactoring
```
On some older systems (CentOS 7), `file gateway` will produce this:
```
firezone-gateway: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
```
`ELF` is a much more reliable means of detecting the file is a binary
executable.
Is this worth it?
```[tasklist]
### Before merging
- [x] Double-check docs and ask Jamil to review
- [x] Would need Brian to review the terraform thing
- [x] Make sure Docker compat isn't broken for existing users (shouldn't be, the image is still just `client`)
- [x] Decide whether compatibility tests need to pass (if something breaks after merge we can revert this)
```
This will fix an issue with `linux-group` and `token-path` that happens
when I try to split up the binaries.
```[tasklist]
### Before merging
- [x] Fix linux-group. That stub-ipc-client command doesn't even exist anymore
```
```[tasklist]
### Before merging
- [x] (FAILED) Test CI deb on Ubuntu 24.04 #4883
- [x] Wait for everything else to merge: #3884
- [x] Fix#4889
- [x] Fix#4890
- [x] Test on Ubuntu 20.04 (683bddc0b passed)
- [x] Test on Ubuntu 22.04 (683bddc0b passed)
- [x] diff between main and 683bddc0b to make sure nothing in the code changed
- [ ] Someone other than me should give it a once-over. `intended_behavior.md` has the manual smoke test I've been doing on it. Install script is <a943a9dba1/scripts/firezone-client-gui-install.sh> Deb package from CI is <https://github.com/firezone/firezone/actions/runs/8972824465/artifacts/1477261361>
```
This is what I've been doing on the testing VMs to exercise the
first-run behavior.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
This will keep the files from going out of sync.
This PR also checks that the IPC service creates the IPC socket with
`root:firezone` as the owner and group, when running under systemd.
This aligns some of the internal names with #4531, but it shouldn't
break the externally-visible things like package names or permalinks.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Now that we've worked out the flakiness from the iperf tests, we should
increase the UDP send rate so we have some benchmark of how many packets
we can actually handle before dropping.
For tests it doesn't hurt, but this will be used as a template for the
systemd service we ship to production, and that can't have the ID there.
So I'm also cleaning up a few other problems I noticed:
- I wanted to split the service files as part of #4531, so that the GUI
Client and headless Client can have separate sandbox rules. e.g, the
headless Client won't be allowed to create Unix domain sockets
- I'm punting more things to systemd, which allows us to tighten down
the sandbox further, e.g. creating `/var/lib/dev.firezone.client` and
`/run/dev.firezone.client` for us
- Closes#4461
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
```[tasklist]
- [x] Update website
- [x] Update blog entry with old link
- [ ] ~~Replace Github URL in GUI Client updater with our own links~~
- [ ] Wait for CI to go green
```
Refs #4531
This proposes a unified scheme for deb and MSI packages, and moves
Windows to that scheme.
This breaks compatibility. Existing Clients won't recognize the new
asset names once this is merged, so they won't show the "Firezone 1.0.0
is available" pop-up.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Closes#4682Closes#4691
```[tasklist]
# Before merging
- [x] Wait for `linux-group` test to go green on `main` (#4692)
- [ ] Wait for those browsers tests to get fixed
- [ ] *All* compatibility tests must pass on this branch
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Considered using Elixir and Rust to write the tests.
For Elixir, `wallaby` doesn't seem to have a way to attach to an
existing `chromium` instance, launching it each time, which makes it
hard to coordinate with the relay restart.
For Rust we considered `thirtyfour` which would be very nice since we
could test both firefox and chrome but each time it connects to the
instance it launches a new session making it hard to test the DNS cache
behavior.
We also considered `chrome_headless` for Rust it needs a small patch to
prevent it from closing the browser after `Drop` but it still presents a
problem, since it has no easy way to retrieve if loading a page has
succeeded. There are some workarounds such as retrieving the title that
we could have used but after some testing they are quite finnicky and we
don't want that for CI.
So I ended up settling for TypeScript but I'm open to other options, or
a fix for the previous ones!
There are some modifications still incoming for this PR, around the test
name and that sleep in the middle of the test doesn't look good so I
will probably add some retries, but the gist is here, will keep it in
draft until we expect it to be passing.
So feel free to do some initial reviews.
Note: the number of lines changed is greatly exaggerated by
`package.lock`
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Whenever we receive a `relays_presence` message from the portal, we
invalidate the candidates of all now disconnected relays and make
allocations on the new ones. This triggers signalling of new candidates
to the remote party and migrates the connection to the newly nominated
socket.
This still relies on #4613 until we have #4634.
Resolves: #4548.
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
```[tasklist]
# Before merging
- [x] Remove file extension `.txt`
- [x] Wait for `linux-group` test to go green on `main` (#4692)
- [x] *all* compatibility tests must be green on this branch
```
Closes#4664Closes#4665
~~The compatibility tests are expected to fail until the next release is
cut, for the same reasons as in #4686~~
The compatibility test must be handled somehow, otherwise it'll turn
main red.
`linux-group` was moved out of integration / compatibility testing, but
the DNS tests do need the whole Docker + portal setup, so that one can't
move.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Closes#4669
This should stop the problem of `linux-group` failing because of trying
to test an older release that doesn't have the right CLI features
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
As part of #4568, we are adding a 2nd relay which showed some
short-comings of the current process state assertions because they were
running outside the docker containers, thus listing all relays as soon
as there are multiple.
```[tasklist]
### Before merging
- [x] Update KB
```
Maybe not a feature since Linux IPC isn't available to users yet?
I think it's okay if the new `linux-group` test fails in compatibility,
since it wasn't implemented at all back then.
Closes#4659Closes#4660
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Refs #4513
The next step after this is to use this to test security in the Linux
IPC code, it should reject any IPC commands from users not in the
`firezone` group.
Should drop our `systemd-analyze security` level from 9.7 to about 2.5.
We could go a little further, but it would take a lot more effort, and
this is a good starting point.
```[tasklist]
# Before review
- [x] Remove unused trap function in Bash
- [x] Remove `systemd-analyze` call
```
I wasn't aware of `set x` when I wrote this, and it looks good in the
other test scripts.
I'm not sourcing `lib.sh` yet, because I don't happen to need any
functions from it. I have other draft PRs that will probably end up
using it.
This is needed so that we can auto-update the systemd unit file, either
manually, or with a package manager like `apt`. We don't want users
cut-and-pasting these together on every update, and we don't want
machines doing it. Making the file updatable means we can make security
fixes to it easily.
Upon receiving a SIGTERM, we immediately disconnect from the websocket
connection to the portal and set a flag that we are shutting down.
Once we are disconnected from the portal and no longer have an active
allocations, we exit with 0. A repeated SIGTERM signal will interrupt
this process and force the relay to shutdown.
Disconnecting from the portal will (eventually) trigger a message to
clients and gateways that this relay should no longer be used. Thus,
depending on the timeout our supervisor has configured after sending
SIGTERM, the relay will continue all TURN operations until the number of
allocations drops to 0.
Currently, we also allow clients to make new allocations and refreshing
existing allocations. In the future, it may make sense to implement a
dedicated status code and refuse `ALLOCATE` and `REFRESH` messages
whilst we are shutting down.
Related: #4548.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
