Regardless of `FIREZONE_DNS_CONTROL`, always try to notify systemd that
we've started.
I had accidentally conflated the idea of running as a systemd service
with the idea of using systemd to control DNS. They're separate, but
I'll keep the service unit in here and always use `sd-notify` since it
should be harmless to use even in Alpine.
~~If `FIREZONE_DNS_CONTROL` is `systemd-resolved`, try to notify systemd
that we've finished startup and the tunnel is ready.~~
Also adds a CI test, including a systemd service file that is **not**
ready for general use.
Ready for review once it's green.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Only user-facing if users are using the Docker image for the Linux
client.
I split off a module for `/etc/resolv.conf` since the code and unit
tests are about 300 lines and aren't related to the rest of the
`tun_linux.rs` code.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
This improves maintenance because we can now use a regular matrix for
the integration tests and one can locally use tools like shellcheck or a
`bash-lsp` during development.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Docker-based gateways won't have working IPv6 (good point @AndrewDryga),
so I started testing the systemd gateways more and found some issues I
fixed.
* Update default tab order for Deploy gateways page to prefer systemd
* Update unit file to run gateway as unprivileged user
* Remove dependency on `wget` in unit file
* Fix iptables logic so rules as re-created on reboot
* Use `/var/lib/firezone` instead of `/etc/firezone` for writing runtime
files (`/etc/` is often mounted read-only on hardened systems)
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Andrew Dryga <andrew@dryga.com>
* Add new `VERSION` to `docker_migrate.sh` script
* Add missing `SAML_KEYFILE_PATH` and `SAML_CERTFILE_PATH` env vars to
migrate script
* Add missing `PHOENIX_PORT` var
* Bump Elixir to 1.14.3
* Bump Erlang to 25.2.1
* Update docs to document new VERSION var in docker-compose.yml upgrade
mechanism
Fixes#1395
Adds a minimal supervision tree for making DB changes from the
`FzHttp.Release` module. This allows the `bin/create-or-reset-admin` and
`bin/create-api-token` commands to be with `docker compose exec` or
`docker compose run --rm` indiscriminately.
Starting the FzHttp.Repo directly is more involved it's not compiled
into the release as an OTP app.
### TODO
- [x] "/v0"
- [x] Double-check migration order; re-timestamp if necessary
- [x] Move `sites` fields to `configurations` so they can be updated
from API
- [x] #1240 -- it introduces possible race conditions for API requests
- [x] #1249
- [ ] #1008
- [ ] Final review
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Andrew Dryga <andrew@dryga.com>
This PR also moves to `yarn` for docs package management for improved
speed, security, and developer experience. Docusaurus prefers yarn.
Refs firezone/marketing#126
* Remove _build folders for umbrella apps
For umbrella apps everything goes into /_build directory so there no need to ignore directories that should never be created
* Change mix aliases to be more aligned with what OS community would expect
1. We want ecto.create and ecto.migrate to be run on each tests, this will simplify setup steps (no need to run migrations manually)
2. ecto.remigrate is not needed because now you can just run ecto.drop and on tests migrations would be executed anyways.
* Rename docker-compose step name in CONTRIBUTING.md
The step was renamed here: dd67baf629 (diff-67a4805fdcc6145d7b3ada2a6099a9b2e91c9d0fd108c22f95d2f01d219793d1R10)
* Remove .devcontainer
This an is opinionated change. Right now devcontainer doesn't work but should be easy to fix (with renaming step name), but at the same time it forces developers that use VS code to have unified development environment (including plugins for the editor itself).
I feel like it's not a good path to go for OS and for small team - everyone should be allowed to use setup they like. Especially for people like me that tend to recompile ls-elixir for Elixir plugin from master branch.
Plus it's yet another thing to maintain while nobody on the team is using it, which means it will be always causing issues.
* Make fz_http mix.exs aliases aligned with umbrella app ones
* Redirect stderr to stdout in a command called from dev.exs
Otherwise I'm getting this on my MacOS (that has a `route` implementation that doesn't show interfaces) when `mix phx.server` is executed:
```
usage: route [-dnqtv] command [[modifiers] args]
```
* Fix race condition due to static device field values
Both public_key and name are unique and we should not use static values for field covered by unique index, otherwise deadlocks and slow tests are expected.
* Remove unwanted transaction block
The changeset code doesn't have any code that accesses the database and individual Ecto.SQL commands are already wrapped in transactions by default, so there is no need to start it manually and hold for longer than expected (while irrelevant Elixir code is running).
* Use netstat to identify egress interface on MacOS
* Rename uninstall.sh to omnibus-uninstall.sh
* Fix uninstall path in omnibus_build.yml
* fix: use caddy in host network_mode and make sure urls have a scheme
* fix: remove unnecesary exposed ports
* fix: remove support for hostnames begining with // since caddy doesn't support it
* Fix schemeless external URLs; error on invalid ones (#1090)
* Fix schemeless external URLs; error on invalid ones
* use different dockerfile for linux vs non-linux
* Use conditional EXTERNAL_URL defaults
* suppress empty warning
* postgres volume location
* Use inline Caddyfile
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
