-
Notifications
You must be signed in to change notification settings - Fork 184
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
iroh-relay expects a particular setup of certificate directory #2177
Comments
As a workaround I did:
|
Merged
4 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 18, 2024
…everse-proxy support (#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 #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 - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant. - [x] All breaking changes documented.
ppodolsky
pushed a commit
to izihawa/iroh
that referenced
this issue
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
I am trying to setup iroh-relay with this configuration:
The server is using acmetool which creates directory with the following files:
iroh
expects.key
and.crt
files instead:iroh/iroh-net/src/bin/iroh-relay.rs
Lines 108 to 109 in b07547b
I can create a folder with symlinks that links
iroh.example.org.crt
tofullchain
file andiroh.example.org.key
toprivkey
file, but it would have been easier if instead ofcert_dir
configuration accepted two explicit paths for the key and for certificate chain.The text was updated successfully, but these errors were encountered: