mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
19f51568c2c5fad2e237db31485f94427140e615
5957 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Thomas Eizinger
|
19f51568c2 |
chore(rust): don't pass errors as values for debug logs (#7318)
Our logging library `tracing` supports structured logging. Structured logging means we can include values within a `tracing::Event` without having to immediately format it as a string. Processing these values - such as errors - as their original type allows the various `tracing` layers to capture and represent them as they see fit. One of these layers is responsible for sending ERROR and WARN events to Sentry, as part of which `std::error::Error` values get automatically captured as so-called "sentry exceptions". Unfortunately, there is a caveat: If an `std::error::Error` value is included in an event that does not get mapped to an exception, the `error` field is completely lost. See https://github.com/getsentry/sentry-rust/issues/702 for details. To work around this, we introduce a `err_with_sources` adapter that an error and all its sources together into a string. For all `tracing::debug!` statements, we then use this to report these errors. It is really unfortunate that we have to do this and cannot use the same mechanism, regardless of the log level. However, until this is fixed upstream, this will do and gives us better information in the log submitted to Sentry. |
||
|
Thomas Eizinger
|
9e9dfd5e97 |
chore(gui-client): downgrade warning to debug (#7313)
With a retry-mechanism in place, there is no need to log a warning when `connect_to_service` fails. Instead, we just log this as on DEBUG and continue trying. If it fails after all attempts, the entire function will bail out and we will receive a Sentry event from error handling higher up the callstack. |
||
|
Thomas Eizinger
|
d38304b21f |
build(rust): depend on our boringtun fork (#7120)
This switches our dependency on `boringtun` over to our fork at https://github.com/firezone/boringtun. The idea of the fork is to carefully only patch selective parts such that upstream things later is still possible. The complete diff can be seen here: https://github.com/cloudflare/boringtun/compare/master...firezone:boringtun:master So far, the only patches in the fork are dependency bumps, linter fixes, adjustments to log levels and the removal of panics when the destination buffer is too small. |
||
|
Thomas Eizinger
|
bf34b26c22 |
refactor(gui-client): remove unnecessary async block (#7312)
The `Server::new` function already returns a `Future`. Calling `.await` on that within an `async` block is equivalent to just calling the `new` function itself. |
||
|
Thomas Eizinger
|
764af71f66 |
fix(website): remove duplicate tailwind rule (#7316)
My editor complained that the `hover:ring-2` class was applied twice for these elements. |
||
|
Thomas Eizinger
|
237865c37b |
test(connlib): drain all Transmits at the end of advance (#7315)
Within our test suite, we "spin" for several (simulated) seconds after each state transition to allow for packets being sent between the different nodes. The test suite simulates different latencies by delaying the delivery of some of these packets. `connlib` has several timers for sending packets, i.e. STUN bindings, WG keep-alives etc. These timers never end so we cannot simply spin "until we no longer want to send any packets". Currently, we simply hard-stop after a few seconds and drop the remaining packets and move on to the next state transition. At present, this isn't an issue because only our ICE agent adheres to the simulated time advancement. `boringtun` is still impure and thus we usually don't get to see any of the WireGuard packets like keep-alives and session timeouts etc in our tests. The STUN messages are pretty resilient to retransmissions so the current packet drop doesn't matter. In the process of adopting our boringtun fork (https://github.com/firezone/boringtun) where we will eventually fix the time impurity, dropping some of these packets caused problems. To fix this, we now drain all remaining packets that are sitting in the "yet-to-be-delivered" buffer. These packets are delivered to an "inbox" that is per-host, meaning the host (i.e. client, gateway or relay) will still perceive the incoming packet with the correct latency. We extract this functionality from #7120 because it is generally useful. |
||
|
Thomas Eizinger
|
a83729e439 |
chore(gateway): be more detailed in error reporting (#7314)
Instead of collapsing multiple of these errors into one, we emit a dedicated error message for each case. This will allow us to distinguish them within Sentry events. |
||
|
Thomas Eizinger
|
b78e84090c |
refactor(gui-client): reduce warning to debug (#7311)
Windows has some funny behaviour where creating the deep-link server sometimes fails and we have to try again. Currently, each of these operations is logged as a warning when it would actually succeed later. These create unnecessary Sentry alerts. If we run out of attempts to create the deep-link server (currently 10), the entire function fails which will be logged as an error further down. The last 500 INFO and DEBUG logs will be captured as breadcrumbs together with the event, meaning we still get to see those error messages on why it failed to create the deep-link server. Resolves: #7238. |
||
|
Thomas Eizinger
|
ad4eea29ff |
chore(rust): don't panic in fallible functions (#7298)
"Just let it crash" is terrible advice for software that is shipped to end users. Where possible, we should use proper error handling and only fail the current function / task that is active, e.g. drop a particular packet instead of failing all of connlib. We more or less already do that. Activating the clippy lint `unwrap_in_result` surfaced a few more places where we panic despite being in a function that is fallible already. These cases can easily be converted to not panic and return an error instead. |
||
|
Thomas Eizinger
|
0dc078876b |
refactor(gui-client): capture error sources when connect fails (#7303)
When `connlib` fails to establish a session, the GUI client currently
only captures the top-level error within `connect_to_firezone` because
it uses `.to_string()` for all errors. Unfortunately, that doesn't print
any of the sources of an error.
To conveniently capture all sources, we can use `anyhow` and its
alternate formatting using `format!("{e:#}")` (notice the `#`). Not all
errors within `connect_to_firezone` should be captured like this
however. Certain IO errors, in particular when trying to resolve the
domain of the portal, need to be captured separately because they may
resolve by themselves if we gain connectivity again. This is important,
otherwise we discard the users token when they boot-up a machine without
internet access yet Firezone is auto-starting.
To make this more ergonomic, we trim down `IpcServiceError` to two
variants: The IO variant we need to special-case and everything else.
This allows us to create `From` impls which "do the right thing" by
capturing more error information using `anyhow`'s alternate formatting.
|
||
|
dependabot[bot]
|
7e4e190cd6 |
build(deps): Bump test-strategy from 0.3.1 to 0.4.0 in /rust (#7308)
Bumps [test-strategy](https://github.com/frozenlib/test-strategy) from 0.3.1 to 0.4.0. <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
1aa9ae9885 |
build(deps): Bump tokio from 1.41.0 to 1.41.1 in /rust (#7307)
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.41.0 to 1.41.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/tokio/releases">tokio's releases</a>.</em></p> <blockquote> <h2>Tokio v1.41.1</h2> <h1>1.41.1 (Nov 7th, 2024)</h1> <h3>Fixed</h3> <ul> <li>metrics: fix bug with wrong number of buckets for the histogram (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6957">#6957</a>)</li> <li>net: display <code>net</code> requirement for <code>net::UdpSocket</code> in docs (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6938">#6938</a>)</li> <li>net: fix typo in <code>TcpStream</code> internal comment (<a href="https://redirect.github.com/tokio-rs/tokio/issues/6944">#6944</a>)</li> </ul> <p><a href="https://redirect.github.com/tokio-rs/tokio/issues/6957">#6957</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6957">tokio-rs/tokio#6957</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6938">#6938</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6938">tokio-rs/tokio#6938</a> <a href="https://redirect.github.com/tokio-rs/tokio/issues/6944">#6944</a>: <a href="https://redirect.github.com/tokio-rs/tokio/pull/6944">tokio-rs/tokio#6944</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
cd26ce6dfe |
refactor(gui-client): return error to TypeScript from commands (#7302)
Within the Tauri client, we invoke commands from TypeScript on the Rust side. These commands can sometimes fail, which is why these commands return a `Result`. Most of our commands actually only send messages through a channel to an event-loop. This can only fail if the other side of the channel is closed, which should(?) only happen if the program is shutting down or some part of it crashed. Regardless, these errors can directly be forwarded to the TypeScript code where they will get caught and logged to the browser console. In the future, we can install Sentry's TypeScript client in the GUI code to automatically report errors on the TypeScript side too. Resolves: #7256. |
||
|
Thomas Eizinger
|
a5e20064dc |
refactor(gui-client): downgrade temporary error (#7304)
If we only temporarily fail to connect to the portal, we don't need to report this as a warning. Resolves: #7251. |
||
|
Thomas Eizinger
|
4e67c568da |
refactor: downgrade errors when we cannot bind sockets (#7305)
Most of the time, these errors are a result of a limited IP stack, for example IPv6 not being available. Reporting these as errors to Sentry is unnecessarily noisy. If something else happens further down the line, the last 500 debug and info logs will be sent along with the error report so we will still see these in the breadcrumbs if an actual error happens later. Resolves: #7245. |
||
|
Thomas Eizinger
|
488c599d5b |
chore(telemetry): capture Firezone ID and account in user ctx (#7310)
Sentry has a feature called the "User context" which allows us to assign events to individual users. This in turn will give us statistics in Sentry, how many users are affected by a certain issue. Unfortunately, Sentry's user context cannot be built-up step-by-step but has to be set as a whole. To achieve this, we need to slightly refactor `Telemetry` to not be `clone`d and instead passed around by mutable reference. Resolves: #7248. Related: https://github.com/getsentry/sentry-rust/issues/706. |
||
|
Thomas Eizinger
|
06a274c4e5 |
refactor(apple): make panics on decoding errors more descriptive (#7301)
The communication between the native Apple client and `connlib` uses JSON encoding. The deserialisation of these should never fail because a particular version of `connlib` is always bundled with the native client. Thus, panicking here is justified. In case it does ever happen, we improve the panic message with this patch. |
||
|
Thomas Eizinger
|
213dd34ff3 |
chore(apple): log all connect errors on the connlib-side (#7300)
We don't have Sentry yet in the native Apple client, meaning we don't yet learn about errors returned from the `connect` call. Normally, logging and returning an error is an anti-pattern. We are okay with that in this case until we can report these errors in the native Apple client. |
||
|
Thomas Eizinger
|
62cb32b7a3 |
chore(gateway): report more tunnel errors to event-loop (#7299)
Currently, the Gateway's state machine functions for processing packets use type-signature that only return `Option`. Any errors while processing packets are logged internally. This makes it difficult to consistently log these errors. We refactor these functions to return `Result<Option<T>>` in most cases, indicating that they may fail for various reasons and also sometimes succeed without producing an output. This allows us to consistently log these errors in the event-loop. Logging them on WARN or ERROR would be too spammy though. In order to still be alerted about some of these, we use the `telemetry_event!` macro which samples them at a rate of 1%. This will alert us about cases that happen often and allows us to handle them explicitly. Once this is deployed to staging, I will monitor the alerts in Sentry to ensure we won't get spammed with events from customers on the next release. |
||
|
Jamil
|
ce8d8709d6 |
chore(infra): Remove project owners that are no longer owners (#7297)
Now Terraform is receiving a 400 from the Google API because these users
don't exist... 🙃.
Hopefully the cycle was broken by the last PR and this one succeeds.
|
||
|
Jamil
|
b0c6b6d3c5 |
fix(infra): Restore project owners to prevent cycle. Will delete later (#7296)
Terraform is complaining about a cycle involved with deleting these project owners from the prod config. https://app.terraform.io/app/firezone/workspaces/production/runs/run-7vhn8Yv5pksywBtd Will restore them to get prod to deploy now, and then investigate the cycle more carefully afterward. |
||
|
dependabot[bot]
|
f47c959e3f |
build(deps): Bump the google group across 1 directory with 2 updates (#7279)
Bumps the google group with 2 updates in the /terraform/environments/production directory: [hashicorp/google](https://github.com/hashicorp/terraform-provider-google) and [hashicorp/google-beta](https://github.com/hashicorp/terraform-provider-google-beta). Updates `hashicorp/google` from 5.42.0 to 6.10.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/hashicorp/terraform-provider-google/releases">hashicorp/google's releases</a>.</em></p> <blockquote> <h2>v6.10.0</h2> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_compute_instance_guest_attributes</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20095">#20095</a>)</li> <li><strong>New Data Source:</strong> <code>google_service_accounts</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20062">#20062</a>)</li> <li><strong>New Resource:</strong> <code>google_iap_settings</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20085">#20085</a>)</li> </ul> <p>IMPROVEMENTS:</p> <ul> <li>apphub: added <code>GLOBAL</code> enum value to <code>scope.type</code> field in <code>google_apphub_application</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20015">#20015</a>)</li> <li>assuredworkloads: added <code>workload_options</code> field to <code>google_assured_workloads_workload</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19985">#19985</a>)</li> <li>bigquery: added <code>external_catalog_dataset_options</code> fields to <code>google_bigquery_dataset</code> resource (beta) (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20097">#20097</a>)</li> <li>bigquery: added descriptive validation errors for missing required fields in <code>google_bigquery_job</code> destination table configuration (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20077">#20077</a>)</li> <li>compute: <code>desired_status</code> on google_compute_instance can now be set to <code>TERMINATED</code> or <code>SUSPENDED</code> on instance creation (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20031">#20031</a>)</li> <li>compute: added <code>header_action</code> and <code>redirect_options</code> fields to <code>google_compute_security_policy_rule</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20079">#20079</a>)</li> <li>compute: added <code>interface.ipv6-address</code> field in <code>google_compute_external_vpn_gateway</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20091">#20091</a>)</li> <li>compute: added <code>propagated_connection_limit</code> and <code>connected_endpoints.propagated_connection_count</code> fields to <code>google_compute_service_attachment</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20016">#20016</a>)</li> <li>compute: added plan-time validation to <code>name</code> on <code>google_compute_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20036">#20036</a>)</li> <li>compute: added support for <code>advanced_machine_features.turbo_mode</code> to <code>google_compute_instance</code>, <code>google_compute_instance_template</code>, and <code>google_compute_region_instance_template</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20090">#20090</a>)</li> <li>container: added in-place update support for <code>labels</code>, <code>resource_manager_tags</code> and <code>workload_metadata_config</code> in <code>google_container_cluster.node_config</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20038">#20038</a>)</li> <li>filestore: added <code>protocol</code> property to resource <code>google_filestore_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19982">#19982</a>)</li> <li>memorystore: added <code>mode</code> flag to <code>google_memorystore_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19988">#19988</a>)</li> <li>netapp: added <code>zone</code> and <code>replica_zone</code> fields to <code>google_netapp_storage_pool</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19980">#19980</a>)</li> <li>netapp: added <code>zone</code> and <code>replica_zone</code> fields to <code>google_netapp_volume</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19980">#19980</a>)</li> <li>networksecurity: added <code>tls_inspection_policy</code> field to <code>google_network_security_gateway_security_policy</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19986">#19986</a>)</li> <li>resourcemanager: added <code>disabled</code> to <code>google_service_account</code> datasource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20034">#20034</a>)</li> <li>spanner: added <code>asymmetric_autoscaling_options</code> field to <code>google_spanner_instance</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20014">#20014</a>)</li> <li>sql: removed the client-side default of <code>ENTERPRISE</code> for <code>edition</code> in <code>google_sql_database_instance</code> so that <code>edition</code> is determined by the API when unset. This will cause new instances to use <code>ENTERPRISE_PLUS</code> as the default for POSTGRES_16. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19977">#19977</a>)</li> <li>vmwareengine: added <code>autoscaling_settings</code> to <code>google_vmwareengine_private_cloud</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20057">#20057</a>)</li> </ul> <p>BUG FIXES:</p> <ul> <li>accesscontextmanager: fixed permadiff for perimeter ingress / egress rule resources (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20046">#20046</a>)</li> <li>compute: fixed an error in <code>google_compute_security_policy_rule</code> that prevented updating the default rule (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20066">#20066</a>)</li> <li>container: fixed missing in-place updates for some <code>google_container_cluster.node_config</code> subfields (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/20038">#20038</a>)</li> </ul> <h2>v6.9.0</h2> <p>DEPRECATIONS:</p> <ul> <li>containerattached: deprecated <code>security_posture_config</code> field in <code>google_container_attached_cluster</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19912">#19912</a>)</li> </ul> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_oracle_database_autonomous_database</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19903">#19903</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_autonomous_databases</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19901">#19901</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_cloud_exadata_infrastructures</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19884">#19884</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_cloud_vm_clusters</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19900">#19900</a>)</li> <li><strong>New Resource:</strong> <code>google_apigee_app_group</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19921">#19921</a>)</li> <li><strong>New Resource:</strong> <code>google_apigee_developer</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19911">#19911</a>)</li> <li><strong>New Resource:</strong> <code>google_network_connectivity_group</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19902">#19902</a>)</li> </ul> <p>IMPROVEMENTS:</p> <ul> <li>compute: <code>google_compute_network_firewall_policy_association</code> now uses MMv1 engine instead of DCL. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19976">#19976</a>)</li> <li>compute: <code>google_compute_region_network_firewall_policy_association</code> now uses MMv1 engine instead of DCL. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19976">#19976</a>)</li> <li>compute: added <code>creation_timestamp</code> field to <code>google_compute_instance</code>, <code>google_compute_instance_template</code>, <code>google_compute_region_instance_template</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19906">#19906</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/hashicorp/terraform-provider-google/blob/main/CHANGELOG.md">hashicorp/google's changelog</a>.</em></p> <blockquote> <h2>6.10.0 (Unreleased)</h2> <h2>6.9.0 (October 28, 2024)</h2> <p>DEPRECATIONS:</p> <ul> <li>containerattached: deprecated <code>security_posture_config</code> field in <code>google_container_attached_cluster</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19912">#19912</a>)</li> </ul> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_oracle_database_autonomous_database</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19903">#19903</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_autonomous_databases</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19901">#19901</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_cloud_exadata_infrastructures</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19884">#19884</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_cloud_vm_clusters</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19900">#19900</a>)</li> <li><strong>New Resource:</strong> <code>google_apigee_app_group</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19921">#19921</a>)</li> <li><strong>New Resource:</strong> <code>google_apigee_developer</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19911">#19911</a>)</li> <li><strong>New Resource:</strong> <code>google_network_connectivity_group</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19902">#19902</a>)</li> </ul> <p>IMPROVEMENTS:</p> <ul> <li>compute: <code>google_compute_network_firewall_policy_association</code> now uses MMv1 engine instead of DCL. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19976">#19976</a>)</li> <li>compute: <code>google_compute_region_network_firewall_policy_association</code> now uses MMv1 engine instead of DCL. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19976">#19976</a>)</li> <li>compute: added <code>creation_timestamp</code> field to <code>google_compute_instance</code>, <code>google_compute_instance_template</code>, <code>google_compute_region_instance_template</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19906">#19906</a>)</li> <li>compute: added <code>key_revocation_action_type</code> to <code>google_compute_instance</code> and related resources (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19952">#19952</a>)</li> <li>looker: added <code>deletion_policy</code> to <code>google_looker_instance</code> to allow force-destroying instances with nested resources by setting <code>deletion_policy = FORCE</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19924">#19924</a>)</li> <li>monitoring: added <code>alert_strategy.notification_prompts</code> field to <code>google_monitoring_alert_policy</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19928">#19928</a>)</li> <li>storage: added <code>hierarchical_namespace</code> to <code>google_storage_bucket</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19882">#19882</a>)</li> <li>sql: removed the client-side default of <code>ENTERPRISE</code> for <code>edition</code> in <code>google_sql_database_instance</code> so that <code>edition</code> is determined by the API when unset. This will cause new instances to use <code>ENTERPRISE_PLUS</code> as the default for POSTGRES_16. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19977">#19977</a>)</li> <li>vmwareengine: added <code>autoscaling_settings</code> to <code>google_vmwareengine_cluster</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19962">#19962</a>)</li> <li>workstations: added <code>max_usable_workstations</code> field to <code>google_workstations_workstation_config</code> resource. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19872">#19872</a>)</li> </ul> <p>BUG FIXES:</p> <ul> <li>compute: fixed an issue where immutable <code>distribution_zones</code> was incorrectly sent to the API when updating <code>distribution_policy_target_shape</code> in <code>google_compute_region_instance_group_manager</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19949">#19949</a>)</li> <li>container: fixed a crash in <code>google_container_node_pool</code> caused by an occasional nil pointer (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19922">#19922</a>)</li> <li>essentialcontacts: fixed <code>google_essential_contacts_contact</code> import to include required parent field. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19877">#19877</a>)</li> <li>sql: made <code>google_sql_database_instance.0.settings.0.data_cache_config</code> accept server-side changes when unset. When unset, no diffs will be created when instances change in <code>edition</code> and the feature is enabled or disabled as a result. (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19972">#19972</a>)</li> <li>storage: removed retry on 404s during refresh for <code>google_storage_bucket</code>, preventing hanging when refreshing deleted buckets (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19964">#19964</a>)</li> </ul> <h2>6.8.0 (October 21, 2024)</h2> <p>FEATURES:</p> <ul> <li><strong>New Data Source:</strong> <code>google_oracle_database_cloud_exadata_infrastructure</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19856">#19856</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_cloud_vm_cluster</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19859">#19859</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_db_nodes</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19871">#19871</a>)</li> <li><strong>New Data Source:</strong> <code>google_oracle_database_db_servers</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19823">#19823</a>)</li> <li><strong>New Resource:</strong> <code>google_oracle_database_autonomous_database</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19860">#19860</a>)</li> <li><strong>New Resource:</strong> <code>google_oracle_database_cloud_exadata_infrastructure</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19798">#19798</a>)</li> <li><strong>New Resource:</strong> <code>google_oracle_database_cloud_vm_cluster</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19837">#19837</a>)</li> <li><strong>New Resource:</strong> <code>google_transcoder_job_template</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19854">#19854</a>)</li> <li><strong>New Resource:</strong> <code>google_transcoder_job</code> (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19854">#19854</a>)</li> </ul> <p>IMPROVEMENTS:</p> <ul> <li>cloudfunctions: increased the timeouts to 20 minutes for <code>google_cloudfunctions_function</code> resource (<a href="https://redirect.github.com/hashicorp/terraform-provider-google/pull/19799">#19799</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Brian Manifold
|
1a6e70a3d2 |
fix(portal): Fix sign_up/sign_in email templates (#7295)
Why: * Two of the email templates using an `<a>` tag were not properly interpolating a view variable. This happened when the templates were moved from the `web` app using `.heex` files to the `domain` app using `.eex` files. Fixes #7294 |
||
|
Brian Manifold
|
50ba752d30 |
fix(infra): Update gcp cloud armor rules (#7293)
The expression for one of the rules was not able to be applied due to invalid characters (`\n`) and even once the invalid characters were removed there is a limit of 5 subexpressions, but the previous expression contained 10. Along with the expression change, the `deny(451)` is not allowed. The only `deny` codes allowed are `403`, `404`, `502` |
||
|
Jamil
|
1dda915376 |
ci: Publish new clients (#7291)
Fixes the roaming bug. |
||
|
Brian Manifold
|
da743f2743 | fix(CI): Update bencher permissions in CI workflow (#7290) | ||
|
Brian Manifold
|
40ca7fccf0 |
fix(portal): Update log level for failed component version fetch (#7286)
Why:
* The Firezone website is hosting the component versions at the moment
and due to how Vercel works, occassionally a request will
timeout when being made to the /api/versions endpoint. This had been
throwing an error in the elixir logs and triggering an alert, but
because there is always a default set of component version values in
the elixir app there isn't really a need for an error/alert. With
that in mind the log level will be set to `warning` rather than
`error`.
Closes #7233
|
||
|
Thomas Eizinger
|
8653146c18 |
fix(connlib): discard timer once it fired (#7288)
Within `connlib`, we have many nested state machines. Many of them have internal timers by means of timestamps with which they indicate, when they'd like to be "woken" to perform time-related processing. For example, the `Allocation` state machine would indicate with a timestamp 5 minutes from the time an allocation is created that it needs to be woken again in order to send the refresh message to the relay. When we reset our network connections, we pretty much discard all state within connlib and together with that, all of these timers. Thus the `poll_timeout` function would return `None`, indicating that our state machines are not waiting for anything. Within the eventloop, the most outer state machine, i.e. `ClientState` is paired with an `Io` component that actually implements the timer by scheduling a wake-up aggregated as the earliest point of all state machines. In order to not fire the same timer multiple times in a row, we already intended to reset the timer once it fired. It turns out that this never worked and the timer still lingered around. When we call `reset`, `poll_timeout` - which feeds this timer - returns `None` and the timer doesn't get updated until it will finally return `Some` with an `Instant`. Because the previous timer didn't get cleared when it fired, this caused `connlib` to busy loop and prevent some(?) other parts of it from progressing, resulting in us never being able to reconnect to the portal. Yet, because the event loop itself was still operating, we could still resolve DNS queries and such. Resolves: #7254. --------- Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com> |
||
|
Thomas Eizinger
|
4d2dc3dfcb |
refactor(connlib): don't rely on DNS when reconnecting to portal (#7289)
Currently, `connlib` uses the feature of "known hosts" to provide DNS functionality for some domains even without any network connectivity. This is primarily used to ensure that when we reconnect to the portal, we can resolve the domain name which allows us to then create network connections. With recent changes to how our phoenix-channel implementation works, this is actually no longer necessary. Currently, we re-resolve the domain every time we connect, even though we already resolved them when connecting to it for the first time. This step is unnecessary and we can simply directly use the previously resolved IP addresses for the portal domain. |
||
|
Thomas Eizinger
|
cdd3e4d25c |
fix(headless-client): don't fuse futures outside of the loop (#7287)
When waiting on multiple futures concurrently within a loop, it is important that they all get re-created whenever one of them resolves. Currently, due to the `.fuse` call, the SIGHUP signal can only be sent once and future signals get ignored. As a more general fix, I swapped the `futures::select!` macro to the `tokio::select!` macro which allows referencing these futures without pinning and fusing. Ideally, we'd not use any of these macros here and write our own eventloop but that is a larger refactoring. |
||
|
dependabot[bot]
|
3a7101bac0 |
build(deps): Bump the otel group across 1 directory with 4 updates (#7031)
Bumps the otel group with 4 updates in the /rust directory: [opentelemetry](https://github.com/open-telemetry/opentelemetry-rust), [opentelemetry-otlp](https://github.com/open-telemetry/opentelemetry-rust), [opentelemetry_sdk](https://github.com/open-telemetry/opentelemetry-rust) and [tracing-opentelemetry](https://github.com/tokio-rs/tracing-opentelemetry). Updates `opentelemetry` from 0.24.0 to 0.26.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/open-telemetry/opentelemetry-rust/releases">opentelemetry's releases</a>.</em></p> <blockquote> <h2>0.26.0 Release</h2> <p>See changelog for individual crates to know the exact set of changes. As informed during previous release, all crates from this repo follows same version (0.26.0 for this release). This release also upgrades Metric API (part of <code>opentelemetry</code> crate) from alpha to beta.</p> <h2>OpenTelemetry 0.25.0 Release</h2> <p>See changelog for individual crates to know the exact set of changes. This release onwards, all crates from this repo follows same version (0.25.0 for today's release).</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Thomas Eizinger
|
e261cb3c27 |
chore: remove git_version! (#7270)
Reading the Git version requires the entire Git repository to be present, including all tags. The tags are only created _after_ the artifact is being built, when we publish the release. Therefore, these tags are never included in the actual released binary. For Sentry, we use the `CARGO_PKG_VERSION` variable instead. This doesn't tell us whether somebody built a client from source and then used it so there could be some confusion in Sentry events. It is quite unlikely that this happens though so for the majority of Sentry alerts, this will give us the correct version. For the Android client, we also depend on the `GITHUB_SHA` env variable at compile-time. We do the same thing for the GUI client here. Resolves: #6925. |
||
|
Andrew Dryga
|
ab7619c68c |
chore(docs): Add more docs on troubleshooting (#7076)
Signed-off-by: Andrew Dryga <andrew@dryga.com> Co-authored-by: Brian Manifold <bmanifold@users.noreply.github.com> |
||
|
Brian Manifold
|
06791d2d05 |
refactor(portal): API persistent IDs (#7182)
In order for the firezone terraform provider to work properly, the Resources and Policies need to be able to be referenced by their `persistent_id`, specifically in the portal API. |
||
|
Jamil
|
83dfd3a98c |
fix(infra): Don't use macros for Cloud armor (#7285)
Fixes #6807 Follow up to #7282 |
||
|
Thomas Eizinger
|
b7969ce3a1 |
fix(telemetry): ignore events from certain log targets (#7272)
Resolves: #7246. |
||
|
Jamil
|
1bd9a3e134 |
fix(infra): Use proper common expression language syntax (#7282)
https://github.com/firezone/firezone/actions/runs/11713228570/job/32626046819 Language reference: https://github.com/google/cel-spec/blob/master/doc/langdef.md#macros |
||
|
Andrew Dryga
|
0a79cd5045 |
chore(portal): Do not allow signing up from legally-restricted jurisdictions (#7088)
Related to #6807 --------- Co-authored-by: Jamil <jamilbk@users.noreply.github.com> |
||
|
Jamil
|
7bd3d30878 |
fix(ci): Continue on error if uploading to bencher fails (#7280)
Fixes https://github.com/firezone/firezone/actions/runs/11710356831/job/32617881708 |
||
|
Thomas Eizinger
|
2f3fe751bf |
chore(gui-client): log entire error when connlib fails (#7273)
The `error_msg` here is already a user-friendly string because we are also showing it to the user in an error message. These can be entirely different errors so we should display them as different messages. This will allow Sentry to group them together correctly. |
||
|
Thomas Eizinger
|
9948988963 |
chore(gui-client): don't emit error when reading 0 bytes (#7275)
The deep-link server of the GUI client runs in a loop and accepts one connection after another. It can sometimes happen that after accepting a connection, we end up reading 0 bytes. This isn't an error worth reporting, we simply loop around and try again. Resolves: #7257. |
||
|
Jamil
|
71fbfab2d5 |
fix(gui-client): Include rust files when replacing version sentinels (#7278)
Fixes an issue where the ipc_service was stuck reporting 1.3.10. |
||
|
Brian Manifold
|
27169b1369 | chore(ops): Update GCP project owners and notification channels (#7277) | ||
|
Thomas Eizinger
|
53dd16ab2e |
fix(gui-client): don't fail on deleting non-existing credentials (#7271)
Resolves: #7247. |
||
|
Thomas Eizinger
|
c8e12563ff |
chore(gui-client): don't double log errors (#7276)
This line leads to duplicate events in Sentry, we already log the error passed to this function on every call-site. |
||
|
Thomas Eizinger
|
47e45a3cf3 |
chore(telemetry): improve telemetry spans and events (#7206)
DNS resolution is a critical part of `connlib`. If it is slow for whatever reason, users will notice this. To make sure we notice as well, we add `telemetry` spans to the client's and gateway's DNS resolution. For the client, this applies to all DNS queries that we forward to the upstream servers. For the gateway, this applies to all DNS resources. In addition to those IO operations, we also instrument the `match_resource_linear` function. This function operates in `O(n)` of all defined DNS resources. It _should_ be fast enough to not create an impact but it can't hurt to measure this regardless. Lastly, we also instrument `refresh_translations` on the gateway. Refreshing the DNS resolution of a DNS resource should really only happen, when the previous IP addresses become stale yet the user is still trying to send traffic to them. We don't actually have any data on how often that happens. By instrumenting it, we can gather some of this data. To make sure that none of these telemetry events and spans hurt the end-user performance, we introduce macros to `firezone-logging` that sample the creation of these events and spans at a rate of 1%. I ran a flamegraph and none of these even showed up. The most critical one here is probably the `match_resource_linear` span because it happens on every DNS query. Resolves: #7198. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
Thomas Eizinger
|
a5730b6f3b |
chore: release apple client 1.3.8 (#7268)
To be merged once Apple approves the app review. --------- Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com> |
||
|
Jamil
|
19da306839 | ci: Publish GUI 1.3.11 (#7269) | ||
|
Thomas Eizinger
|
42f00fe01e |
chore(snownet): fast-path using PartialEq (#7207)
Counter-intuitively, doing a linear search across all local candidates and checking for equality is faster than hashing the candidate. This is because a `Candidate` actually has quite a few fields and we call this function in the hot-path of packet processing; from `snownet`'s perspective, each packet might come from a different local socket so we have to test for each packet, whether or not we already know about this socket. Using `PartialEq` instead of hashing every candidate saves about 1% in the during a speedtest. |
||
|
Thomas Eizinger
|
78ebad13ab |
chore(rust): log more errors as tracing::Values (#7208)
Logging these as structured values gives us a better stacktrace in Sentry (assuming the errors themselves make proper use of defining an error-chain). |