Rather than the current behavior of raising a 500 when we receive
missing / invalid params in IdP auth callbacks, it would be helpful to
show the user which params were provided, in case the IdP has set
anything useful to aid the user.
For example, we recently received these params from `okta` for a pilot
account (and subsequently rendered them a 500):
```
%{"account_id_or_slug" => "<redacted>", "error" => "access_denied", "error_description" => "User is not assigned to the client application.", "provider_id" => "<redacted>", "state" => "<redacted>"}
```
Bumps [postgrex](https://github.com/elixir-ecto/postgrex) from 0.19.3 to
0.20.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/elixir-ecto/postgrex/blob/master/CHANGELOG.md">postgrex's
changelog</a>.</em></p>
<blockquote>
<h2>v0.20.0 (2025-02-05)</h2>
<ul>
<li>
<p>Deprecations</p>
<ul>
<li>Deprecate <code>:search_path</code> and use <code>:parameters</code>
option instead</li>
</ul>
</li>
<li>
<p>Bug fixes</p>
<ul>
<li>Ensure <code>Duration</code> type returns same units as
<code>Postgrex.Interval</code></li>
<li>Call disconnect on protocol when reconnecting in
<code>Postgrex.ReplicationConnection</code></li>
<li>Call disconnect only if there is protocol in
<code>Postgrex.SimpleConnection</code></li>
</ul>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="c2af85d8eb"><code>c2af85d</code></a>
Release v0.20.0 (with Elixir v1.19 warnings fixed)</li>
<li><a
href="b50103a939"><code>b50103a</code></a>
Release v0.20.0</li>
<li><a
href="51ccbdd1d5"><code>51ccbdd</code></a>
Update postgrex.ex</li>
<li><a
href="34a57fe359"><code>34a57fe</code></a>
Deprecate <code>:search_path</code> and use <code>:parameters</code>
option instead (<a
href="https://redirect.github.com/elixir-ecto/postgrex/issues/729">#729</a>)</li>
<li><a
href="928e43a816"><code>928e43a</code></a>
Have Duration return same units as Postgrex.Interval (<a
href="https://redirect.github.com/elixir-ecto/postgrex/issues/728">#728</a>)</li>
<li><a
href="a6f20205a3"><code>a6f2020</code></a>
Call disconnect on protocol when reconnecting in Replication connection
(<a
href="https://redirect.github.com/elixir-ecto/postgrex/issues/726">#726</a>)</li>
<li><a
href="9748fcbbd7"><code>9748fcb</code></a>
Update dependencies with warnings (<a
href="https://redirect.github.com/elixir-ecto/postgrex/issues/723">#723</a>)</li>
<li><a
href="c3097f429a"><code>c3097f4</code></a>
More safety checks around comments (<a
href="https://redirect.github.com/elixir-ecto/postgrex/issues/722">#722</a>)</li>
<li><a
href="6d9e2ca81a"><code>6d9e2ca</code></a>
Minor link correction and moduledoc cleanup (<a
href="https://redirect.github.com/elixir-ecto/postgrex/issues/720">#720</a>)</li>
<li><a
href="cebb02f923"><code>cebb02f</code></a>
Disconnect only if there is a protocol</li>
<li>See full diff in <a
href="https://github.com/elixir-ecto/postgrex/compare/v0.19.3...v0.20.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Adds the following endpoints:
- `PUT /clients/:id` for updating the `name`
- `PUT /clients/:client_id/verify` for verifying a client
- `PUT /clients/:client_id/unverify` for unverifying a client
- `GET /clients` for listing clients in an account
- `GET /clients/:id` for getting a single client
- `DELETE /clients/:id` for deleting a client
Related: #8081
If the websocket connection between a relay and the portal experiences a
temporary network split, the portal will immediately send the
disconnected id of the relay to any connected clients and gateways, and
all relayed connections (and current allocations) will be immediately
revoked by connlib.
This tight coupling is needlessly disruptive. As we've seen in staging
and production logs, relay disconnects can happen randomly, and in the
vast majority of cases immediately reconnect. Currently we see about 1-2
dozen of these **per day**.
To better account for this, we introduce a debounce mechanism in the
portal for `relays_presence` disconnects that works as follows:
- When a relay disconnects, record its `stamp_secret` (this is somewhat
tricky as we don't get this at the time of disconnect - we need to cache
it by relay_id beforehand)
- If the same `relay_id` reconnects again with the same `stamp_secret`
within `relays_presence_debounce_timeout` -> no-op
- If the same `relay_id` reconnects again with a **different**
`stamp_secret` -> disconnect immediately
- If it doesn't reconnect, **then** send the `relays_presence` with the
disconnected_id after the `relays_presence_debounce_timeout`
There are several ways connlib detects a relay is down:
1. Binding requests time out. These happen every 25s, so on average we
don't know a Relay is down for 12.5s + backoff timer.
2. `relays_presence` - this is currently the fastest way to detect
relays are down. With this change, the caveat is we will now detect this
with a delay of `relays_presence_debounce_timer`.
Fixes#8301
Bumps [plug_cowboy](https://github.com/elixir-plug/plug_cowboy) from
2.7.2 to 2.7.3.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/elixir-plug/plug_cowboy/blob/master/CHANGELOG.md">plug_cowboy's
changelog</a>.</em></p>
<blockquote>
<h2>v2.7.3</h2>
<h3>Enhancements</h3>
<ul>
<li>Ensure errors from Cowboy 2.13 are correctly translated</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="e5d5fd8057"><code>e5d5fd8</code></a>
Release: v2.7.3</li>
<li><a
href="cebf20c7bf"><code>cebf20c</code></a>
Translate errors for Cowboy 2.13.0</li>
<li><a
href="79b7bf8f26"><code>79b7bf8</code></a>
Improve docs (<a
href="https://redirect.github.com/elixir-plug/plug_cowboy/issues/104">#104</a>)</li>
<li>See full diff in <a
href="https://github.com/elixir-plug/plug_cowboy/compare/v2.7.2...v2.7.3">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [flowbite](https://github.com/themesberg/flowbite) from 3.1.1 to
3.1.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/themesberg/flowbite/releases">flowbite's
releases</a>.</em></p>
<blockquote>
<h2>v3.1.2</h2>
<ul>
<li>create new theme file to move CSS variables</li>
<li>update quickstart guide to reflect this change</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4ffec1008a"><code>4ffec10</code></a>
refactor(flowbite): move color theme variables to css file</li>
<li><a
href="38984c12ae"><code>38984c1</code></a>
refactor(colors): move colors from plugin to theme file</li>
<li><a
href="23732fd518"><code>23732fd</code></a>
docs(datepicker): specify that you need to set source</li>
<li>See full diff in <a
href="https://github.com/themesberg/flowbite/compare/v3.1.1...v3.1.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [argon2_elixir](https://github.com/riverrun/argon2_elixir) from
4.0.0 to 4.1.2.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/riverrun/argon2_elixir/blob/master/CHANGELOG.md">argon2_elixir's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>The format is based on <a
href="https://keepachangelog.com/en/1.0.0/">Keep a Changelog</a>,
and this project adheres to <a
href="https://semver.org/spec/v2.0.0.html">Semantic Versioning</a>.</p>
<h2>v4.1.1 (2025-02-04)</h2>
<ul>
<li>Bug fixes
<ul>
<li>fixed unnecessary raise that results in warnings in Elixir 1.18</li>
</ul>
</li>
</ul>
<h2>v4.1.0 (2024-10-04)</h2>
<ul>
<li>Changes
<ul>
<li>Updated dependencies and made changes to silence warnings in Elixir
1.17</li>
</ul>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="f0e4a359f4"><code>f0e4a35</code></a>
update dependencies</li>
<li><a
href="bdc8be851e"><code>bdc8be8</code></a>
update to version 4.1.1</li>
<li><a
href="a390332029"><code>a390332</code></a>
Merge pull request <a
href="https://redirect.github.com/riverrun/argon2_elixir/issues/66">#66</a>
from flaviogrossi/fix_unnecessary_raise</li>
<li><a
href="db9a3f243e"><code>db9a3f2</code></a>
fix unnecessary raise</li>
<li><a
href="5b7a0757d5"><code>5b7a075</code></a>
update changelog</li>
<li><a
href="d3eb849c9f"><code>d3eb849</code></a>
update for Elixir 1.17</li>
<li>See full diff in <a
href="https://github.com/riverrun/argon2_elixir/compare/v4.0.0...v4.1.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [phoenix_html](https://github.com/phoenixframework/phoenix_html)
from 4.2.0 to 4.2.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/phoenixframework/phoenix_html/blob/main/CHANGELOG.md">phoenix_html's
changelog</a>.</em></p>
<blockquote>
<h2>4.2.1 (2025-02-21)</h2>
<ul>
<li>Enhancements
<ul>
<li>Add type to <code>Phoenix.HTML.FormField</code></li>
<li>Allow keyword lists in options to use nil as key/value</li>
</ul>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="71430c1d32"><code>71430c1</code></a>
Release v4.2.1</li>
<li><a
href="1a9341e931"><code>1a9341e</code></a>
Expand documentation of options_for_select (<a
href="https://redirect.github.com/phoenixframework/phoenix_html/issues/460">#460</a>)</li>
<li><a
href="0d15b13c78"><code>0d15b13</code></a>
Update ci.yml (<a
href="https://redirect.github.com/phoenixframework/phoenix_html/issues/459">#459</a>)</li>
<li><a
href="1bea177dfb"><code>1bea177</code></a>
Add type to Phoenix.HTML.FormField (<a
href="https://redirect.github.com/phoenixframework/phoenix_html/issues/458">#458</a>)</li>
<li><a
href="0a11e96826"><code>0a11e96</code></a>
Merge pull request <a
href="https://redirect.github.com/phoenixframework/phoenix_html/issues/457">#457</a>
from phoenixframework/sd-makeup-syntect</li>
<li><a
href="7ccce864f5"><code>7ccce86</code></a>
use makeup_syntect for highlighting JS (and diff)</li>
<li><a
href="9007635b14"><code>9007635</code></a>
Allow keyword list options to use nil as key and/or value (<a
href="https://redirect.github.com/phoenixframework/phoenix_html/issues/456">#456</a>)</li>
<li><a
href="df2a3f6352"><code>df2a3f6</code></a>
Update ExDoc</li>
<li>See full diff in <a
href="https://github.com/phoenixframework/phoenix_html/compare/v4.2.0...v4.2.1">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Instead of crashing, it would make sense to log these and let the
connected entity maintain its WebSocket connection.
This should never happen in practice if we maintain our version
compatibility matrix properly, but it will help reduce the blast radius
of a channel message bug that happens to slip out into the wild.
Fixes#4679
In order to properly handle SRV and TXT records on the clients, we need
to be able to pick a Gateway using the initial query itself. After that,
we need to know the Gateway Tunnel IPs we're connecting to so we can
have the query perform the lookup.
Fixes#8281
We had a number of validation issues:
- DNS resources allow address `1.1.1.1` or `1.1.1.1/32`. These are not
valid and will cause issues during resolution.
- IP resources were allowing basically any string character on `edit`
caused by a logic bug in the changeset
- CIDR resources, same as above
- `*.*.*.*.google.com` and similar DNS wildcard resources were not
allowed
This PR beefs all of those up so that we have a higher degree of
certainty that our data is valid. If invalid data reaches connlib, it
will cause a panic.
This PR also introduces a migration to migrate any invalid resources
into the proper format in the DB.
Fixes#8287
Why:
* After merging #8267 it was discovered that there was a race condition
that allowed a `resource_create` message to end up at the Gateway
Channel process. Previously, this message would not have ever arrived,
because we were replacing Resource IDs when a breaking change was made,
but since that is no longer the case, it is possible that a connection
could be established between the time the `delete_resource` and
`create_resource` messages are sent and the `create_resource` would end
up at the Gateway Channel process. This commit adds a no-op handler to
make sure the message gets processed without throwing an error.
Why:
* Rather than using a persistent_id field in Resources/Policies, it was
decided that we should allow "breaking changes" to these entities. This
means that Resources/Policies will now be able to update all fields on
the schema without changing the primary key ID of the entity.
* This change will greatly help the API and Terraform provider
development.
@jamilbk, would you like me to put a migration in this PR to actually
get rid of all of the existing soft deleted entities?
@thomaseizinger, I tagged you on this, because I wanted to make sure
that these changes weren't going to break any expectations in the client
and/or gateways.
---------
Signed-off-by: Brian Manifold <bmanifold@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Currently, it would theoretically be possible for an admin to connect
non-internet Resources to the Internet site. This PR fixes that by
enforcing only the `internet` Resource type can belong to the `Internet`
gateway group.
Related: #6834
Sentry uncovered a bug in the resources index liveview where it looks
like some code copy-pasted from the policies index view wasn't updated
properly to work in the resources live view, causing the view to crash
if an admin was viewing the table while the resources are changed in
another page.
In debugging that, I realized the best UX when viewing these tables is
usually just to show a `Reload` button and not update the data live
while the admin is viewing it, as this can cause missed clicks and other
annoyances.
This PR adds an optional `stale` component attribute that, if true, will
render a `Reload` button in the live table which upon clicking will
reload the live table.
Not all index views are updated with this - in some views there is
already logic to handle making an intelligent update without breaking
the view if the data is updated - for example for the clients table.
Ideally, we live-update things that don't reflow layout inline (such as
`online/offline` presence) and for things that do cause layout reflow
(create/delete), we show the `Reload` button.
However that work is saved for a future PR as this one fixes the
immediate bug and this is not the highest priority.
<img width="1195" alt="Screenshot 2025-02-16 at 8 44 43 AM"
src="https://github.com/user-attachments/assets/114efffa-85ea-490d-9cea-78c607081ce3"
/>
<img width="401" alt="Screenshot 2025-02-16 at 9 59 53 AM"
src="https://github.com/user-attachments/assets/8a570213-d4ec-4b6c-a489-dcd9ad1c351c"
/>
It's possible for a client or admin to try and load the redirect URL
directly, or a misconfigured IdP may redirect back to us with missing
params. We should redirect with an error flash instead of 500'ing.
This PR fixes two issues:
1. Since we weren't updating any actual fields in the telemetry reporter
log record, it was never being updated, thus optimistic locking was not
taking effect. To fix this, we use `Repo.update(force: true)`.
2. If a buffer is full, we write immediately, but we provider an empty
`%Log{}` which causes a repetitive `the current value of last_flushed_at
is nil and will not be used as a filter for optimistic locking.`
Some customers have already picked the `Internet` name, which is making
our migrations fail.
This scopes the unique name index by `managed_by` so that our attempts
to create them succeed.
By specifying the `before_send` hook, we can easily drop events based on
their data, such as `original_exception` which contains the original
exception instance raised.
Leveraging this, we can add a `report_to_sentry` parameter to
`Web.LiveErrors.NotFound` to optionally ignore certain not found errors
from going to Sentry.
With the internet site changes now in, editing the Internet Resource is
impossible.
As such, the old instructions for using the Internet Resource no longer
apply, and we need to make sure the Internet Site and Internet Resource
are linked.
This migration ensures that's the case. However, if the internet
resource is currently connected to another site already, we don't move
it. This is only for internet resources that aren't connected to any
sites yet.
When flushing metrics to GCP, we sometimes get the following error:
```
{400, "{\n \"error\": {\n \"code\": 400,\n \"message\": \"One or more TimeSeries could not be written: timeSeries[0-51]: write for resource=gce_instance{zone:us-east1-d,instance_id:6130184649770384727} failed with: One or more points were written more frequently than the maximum sampling period configured for the metric.\",\n \"status\": \"INVALID_ARGUMENT\",\n \"details\": [\n {\n \"@type\": \"type.googleapis.com/google.monitoring.v3.CreateTimeSeriesSummary\",\n \"totalPointCount\": 52,\n \"successPointCount\": 48,\n \"errors\": [\n {\n \"status\": {\n \"code\": 9\n },\n \"pointCount\": 4\n }\n ]\n }\n ]\n }\n}\n"}
```
It would be helpful to know exactly which metrics are failing to flush
so we can further troubleshoot any issues.
This allows connections to the postgresql database via the standard
socket, which - opposed to TCP sockets - allows `peer` authentication
based on local unix users. This removes the need for a password and is
much simpler to deploy when running components locally.
In the current form, `DATABASE_SOCKET_DIR` takes precedence over
hostname, if the environment variable is present. I found that
`compile_config!` somehow enforces a value to be present which is
explicitly not what I want for some of these values (i think). I'd be
glad if anyone with more elixir experience can guide me as to how I can
make this more idiomatic.
---------
Supersedes: #8044
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: oddlama <oddlama@oddlama.org>
Ok, the reason why we're still getting the error `One or more points
were written more frequently than the maximum sampling period configured
for the metric.` is because the metric points are identified by the
labels in the metric, and so are "aggregated" more frequently than our
API calls.
By adding the node name to the labels, we scope the metric by that node
and prevent inserting the points more often than our API calls.
Whenever changing a URL we care about, we add an entry in
`website/redirects.js` to avoid breaking links to the old page. Most
search engines reindex these after 1 year, but other websites and places
won't, so we should generally keep them indefinitely since they don't
cost us much to keep around.
This adds hardening to the relay example systemd service shown in the
admin portal. Instead of running the service as root to download the
relay binary, we can let systemd manage the state directory and run with
lower privileges at all times.
I've also removed a shell injection which would in theory allow a
malicious github api server to run commands as root in the pre start
phase.
That being said I have no idea how this script is intended to function,
since it downloads the relay binary from the latest release on GitHub
which currently is a `gui-client` release without any relay binaries
attached.
