Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(iroh-net)!: Rework relay-server binary, more configurable, reverse-proxy support #2341

Merged
merged 20 commits into from
Jun 18, 2024

Conversation

flub
Copy link
Contributor

@flub flub commented Jun 4, 2024

Description

This re-architects the relay-server binary. There is now a struct with detailed configuration which runs the entire server and aborts the server on drop. This simplifies running the server in various situations, including tests. The configuration is now done using a declarative struct, which supports more control over how it runs so it can be more easily used behind a reverse proxy, without TLS etc.

This is aiming to fix #2177, #2179 and #2178.

Breaking Changes

The configuration file format has changed, deployments will need to updated. For the full format see struct Config in iroh-net/src/bin/iroh-relay.rs. Here a summary:

  • The 3 parts of the server now have an independent enable setting: enable_relay, enable_stun and enable_metrics. If omitted they default to true.
  • The way to specify which addresses the server listens on has changed: http_bind_addr is for the relay server, stun_bind_addr for the STUN server, metrics_bind_addr is for the optional metrics server and tls.https_bind_addr is for when TLS is enabled. Note these are now all full socket addresses. All have sensible defaults if omitted.
  • There are new options in tls.cert_path and tls.key_path which allow more control over where the manual TLS keys are to be read from.
  • iroh_net::defaults::DEFAULT_RELAY_STUN_PORT has been renamed to iroh_net::defaults::DEFAULT_STUN_PORT.

TBD: some APIs changed as well. Why are they not all private?

Notes & open questions

  • The iroh_net::relay::iroh_relay crate name is a bit weird. But iroh_net::relay::server is already taken. Maybe iroh_net::relay::bin could work, but that would be weird when using it from code in other places.
  • The ServerConfig struct is a declarative way of controlling the new server interface. It's kind of nice to use. Bu it is a public API that will be a breaking change every time it changes, and it will change. Maybe it's worth creating a builder API for this. But maybe that's something to only tackle when it is a real demand. I feel like the iroh_net::relay::server builders are an attempt at doing this earlier than needed.

Change checklist

  • Self-review.
  • Documentation updates if relevant.
  • Tests if relevant.
  • All breaking changes documented.

@link2xt
Copy link
Contributor

link2xt commented Jun 4, 2024

Related issue for reference: #2179

@flub flub self-assigned this Jun 4, 2024
@dignifiedquire dignifiedquire added this to the v0.19.0 milestone Jun 6, 2024
flub added 11 commits June 6, 2024 22:35
still a lot of cleanup and some bug fixing
There it's also available to other code
The server itself doesn't need this, only the Let's Encrypt config.
So push it into there and remove the need for it otherwise.
an empty join_set will return None right away.  but this set will be
empty most of the time
@flub flub requested a review from Arqu June 10, 2024 17:38
@flub
Copy link
Contributor Author

flub commented Jun 10, 2024

@Arqu probably time for you to give some feedback on the config file changes I'm proposing. Check src/bin/iroh-relay.rs' Config which should have sufficient docs, the changes are highlighted in the pr description

@flub
Copy link
Contributor Author

flub commented Jun 10, 2024

@link2xt I think this is in a reasonable shape now. For you the important changes are probably also described in the Config struct of the binary.

(can't seem to ask you as reviewer :( )

@Arqu
Copy link
Collaborator

Arqu commented Jun 11, 2024

@Arqu probably time for you to give some feedback on the config file changes I'm proposing. Check src/bin/iroh-relay.rs' Config which should have sufficient docs, the changes are highlighted in the pr description

Just went over this, the changes are nice and I'm fine with this moving forward. Once this lands I'll update the configuration files for the deployments.

@flub flub marked this pull request as ready for review June 11, 2024 15:20
@dignifiedquire dignifiedquire changed the title refactor(iroh-net): Rework relay-server binary, more configurable, reverse-proxy support refactor(iroh-net)!: Rework relay-server binary, more configurable, reverse-proxy support Jun 18, 2024
fn key_path(&self) -> PathBuf {
self.manual_key_path
.clone()
.unwrap_or_else(|| self.cert_dir().join("default.key"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should these file names be constants?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They used to use the hostname field. But it seemed weird to require the hostname for manual TLS, it was only used to pick up a default name here. I think a constant default is fine, I honestly expect this to be customised most of the time.

@@ -320,13 +378,17 @@ impl ServerState {
}
}
}
if let Some(server) = server {
// TODO: if the task this is running in is aborted this server is not shut
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about this todo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to leave that in because I felt like if I had to turn all of the relay server actors into structured concurrency the rabbit hole was too deep. This is basically the status quo so not a regression. It would be nice to do this, but as a separate PR probably.

Plus, would need to decide on how much I like tokio-graceful-shutdown possibly :)

Copy link
Contributor

@dignifiedquire dignifiedquire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some small notes, otherwise lgtm

@flub flub enabled auto-merge June 18, 2024 11:50
@flub flub added this pull request to the merge queue Jun 18, 2024
Merged via the queue into main with commit 4ff1ec4 Jun 18, 2024
28 of 29 checks passed
@flub flub deleted the flub/relay-server branch June 18, 2024 12:09
ppodolsky pushed a commit to izihawa/iroh that referenced this pull request Jun 22, 2024
…everse-proxy support (n0-computer#2341)

## Description

This re-architects the relay-server binary. There is now a struct with
detailed configuration which runs the entire server and aborts the
server on drop. This simplifies running the server in various
situations, including tests. The configuration is now done using a
declarative struct, which supports more control over how it runs so it
can be more easily used behind a reverse proxy, without TLS etc.

This is aiming to fix n0-computer#2177, n0-computer#2179 and n0-computer#2178.

## Breaking Changes

The configuration file format has changed, deployments will need to
updated. For the full format see `struct Config` in
`iroh-net/src/bin/iroh-relay.rs`. Here a summary:

- The 3 parts of the server now have an independent enable setting:
`enable_relay`, `enable_stun` and `enable_metrics`. If omitted they
default to `true`.
- The way to specify which addresses the server listens on has changed:
`http_bind_addr` is for the relay server, `stun_bind_addr` for the STUN
server, `metrics_bind_addr` is for the optional metrics server and
`tls.https_bind_addr` is for when TLS is enabled. Note these are now all
full socket addresses. All have sensible defaults if omitted.
- There are new options in `tls.cert_path` and `tls.key_path` which
allow more control over where the manual TLS keys are to be read from.
- `iroh_net::defaults::DEFAULT_RELAY_STUN_PORT` has been renamed to
`iroh_net::defaults::DEFAULT_STUN_PORT`.

TBD: some APIs changed as well.  Why are they not all private?


## Notes & open questions

* The `iroh_net::relay::iroh_relay` crate name is a bit weird. But
`iroh_net::relay::server` is already taken. Maybe `iroh_net::relay::bin`
could work, but that would be weird when using it from code in other
places.
* The `ServerConfig` struct is a declarative way of controlling the new
server interface. It's kind of nice to use. Bu it is a public API that
will be a breaking change every time it changes, and it will change.
Maybe it's worth creating a builder API for this. But maybe that's
something to only tackle when it is a real demand. I feel like the
`iroh_net::relay::server` builders are an attempt at doing this earlier
than needed.

## Change checklist

- [x] Self-review.
- [x] Documentation updates if relevant.
- [x] Tests if relevant.
- [x] All breaking changes documented.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

iroh-relay expects a particular setup of certificate directory
4 participants