## Changelog
- Updates connlib parameter API_URL (formerly known under different
names as `CONTROL_PLANE_URL`, `PORTAL_URL`, `PORTAL_WS_URL`, and
friends) to be configured as an "advanced" or "hidden" feature at
runtime so that we can test production builds on both staging and
production.
- Makes `AUTH_BASE_URL` configurable at runtime too
- Moves `CONNLIB_LOG_FILTER_STRING` to be configured like this as well
and simplifies its naming
- Fixes a timing attack bug on Android when comparing the `csrf` token
- Adds proper account ID validation to Android to prevent invalid URL
parameter strings from being saved and used
- Cleans up a number of UI / view issues on Android regarding typos,
consistency, etc
- Hides vars from from the `relay` CLI we may not want to expose just
yet
- `get_device_id()` is flawed for connlib components -- SMBios is rarely
available. Data plane components now require a `FIREZONE_ID` now instead
to use for upserting.
Fixes#2482Fixes#2471
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
Switched back to `cos-105` to reduce attack surface and generally have
less maintenance and cleaned up the module to be more reusable for our
customers.
Fixes#2363
* Rename `relay` package to `firezone-relay` so that binaries outputted
match the `firezone-*` cli naming scheme
* Rename `firezone-headless-client` package to `firezone-linux-client`
for consistency
* Add READMEs for user-facing CLI components (there will also be docs
later)
When you change the user in a Dockerfile using USER default, the process inside the container runs with the permissions of that user. In COS, only the root user (or processes with elevated privileges) can bind to ports below 1024. So, if our application is trying to bind to a port below 1024, and it's not running as root, we are getting an error.
The `debug` exporter prints statements like the following to stdout:
> 2023-09-07T09:57:43.468-0700 info TracesExporter {"kind": "exporter",
"data_type": "traces", "name": "debug", "resource spans": 1, "spans": 2}
Activating debug logs should give us overall more insight into what this
thing is doing.
I found the following in the serial port logs on GC:
> [ 24.279297] cloud-init[742]: 2023-09-20 19:34:00,095 -
schema.py[WARNING]: Invalid cloud-config provided: Please run 'sudo
cloud-init schema --system' to see the schema errors.
Not sure if it causes any problems at the moment because the spans seem
to import fine but I figured it cannot hurt to add a linter to our CI.
To better take advantage of the OTEL ecosystem, we change our prometheus
metrics to OTEL metrics. OTEL metrics are pushed to the agent via the
OTEL pipeline set up in https://github.com/firezone/firezone/pull/1995
rather than pulled like prometheus.
This means our `/metrics` endpoint is now gone which we previously
(ab)used as a health-check. I've added a dedicated `/healthz` endpoint.
If we aren't configured to use the Google Cloud Trace exporter, then we
currently have no way of configuring the Google Project Id for the
relay. This in turn means that we cannot set span IDs for the Google
Cloud logging format.
Add a configuration option and also emit a warning if we are configured
to emit Google Cloud logging but don't have the ID set.
