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

iroh-relay expects a particular setup of certificate directory #2177

Closed
link2xt opened this issue Apr 11, 2024 · 1 comment · Fixed by #2341
Closed

iroh-relay expects a particular setup of certificate directory #2177

link2xt opened this issue Apr 11, 2024 · 1 comment · Fixed by #2341
Assignees
Labels
c-iroh-relay feat New feature or request
Milestone

Comments

@link2xt
Copy link
Contributor

link2xt commented Apr 11, 2024

I am trying to setup iroh-relay with this configuration:

addr = "[::]:443"
stun_port = 3478
hostname = "iroh.example.org"
enable_stun = true
enable_relay = true

[tls]
cert_mode = "Manual"
prod_tls = true
contact = "root@example.org"
cert_dir = "/var/lib/acme/live/iroh.example.org/"

The server is using acmetool which creates directory with the following files:

$ ls /var/lib/acme/live/iroh.example.org/
account
cert
chain
fullchain
privkey
url

iroh expects .key and .crt files instead:

let cert_path = dir.join(format!("{keyname}.crt"));
let key_path = dir.join(format!("{keyname}.key"));

I can create a folder with symlinks that links iroh.example.org.crt to fullchain file and iroh.example.org.key to privkey file, but it would have been easier if instead of cert_dir configuration accepted two explicit paths for the key and for certificate chain.

@github-project-automation github-project-automation bot moved this to 📋 Backlog in iroh Apr 11, 2024
@link2xt
Copy link
Contributor Author

link2xt commented Apr 11, 2024

As a workaround I did:

$ mkdir cert_dir
$ ln -s /var/lib/acme/live/iroh.testrun.org/privkey cert_dir/iroh.example.org.key
$ ln -s /var/lib/acme/live/iroh.testrun.org/fullchain cert_dir/iroh.example.org.crt

@dignifiedquire dignifiedquire added feat New feature or request c-iroh-relay labels Apr 15, 2024
@ramfox ramfox added this to the v0.18.0 milestone May 22, 2024
@ramfox ramfox assigned ramfox and flub and unassigned ramfox Jun 3, 2024
@dignifiedquire dignifiedquire modified the milestones: v0.18.0, v0.19.0 Jun 6, 2024
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.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in iroh Jun 18, 2024
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
Labels
c-iroh-relay feat New feature or request
Projects
Archived in project
4 participants