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.

Sign up for GitHub

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

Jump to bottom

josh-proxy: allow listening on unix sockets + systemd socket activation #1288

Open
flokli opened this issue Oct 25, 2023 · 3 comments
Open

josh-proxy: allow listening on unix sockets + systemd socket activation #1288

flokli opened this issue Oct 25, 2023 · 3 comments

Comments

@flokli
Copy link
Contributor

flokli commented Oct 25, 2023

I'd like to bind josh-proxy to a unix socket, or even use systemd socket activation, so I can lazily start josh-proxy on the first connection.

This seems to be well supported in the tokio-listener crate, which provides clap integration too:

  <LISTEN_ADDRESS>
          Socket address to listen for incoming connections.
          
          Various types of addresses are supported:
          
          * TCP socket address and port, like 127.0.0.1:8080 or [::]:80
          
          * UNIX socket path like /tmp/mysock or Linux abstract address like @abstract
          
          * Special keyword "inetd" for serving one connection from stdin/stdout
          
          * Special keyword "sd-listen" or "sd-listen-unix" to accept connections from file descriptor 3 (e.g. systemd socket activation)

This is a more general fix to a followup of #1285 I wanted to work on - rather than just adding support for IP to bind on, we'd gain support for all the other things you can bind on.

This would however mean we'd need to introduce another "listen address" cli arg (and deprecate the port one).
@christian-schilling
Copy link
Member

I think there is no reason not to do this 👍🏻

flokli added a commit to flokli/josh that referenced this issue Nov 1, 2023
@flokli
josh-proxy: use clap derive
d6e5c1f 
This simplifies the argument parsing a lot - we can almost parse the
needed structure just with that, including all the manual default
handling.

The only thing that does change is the handling of upstreams - rather
than populating two fields in the Arg struct, it now contains a
`Vec<Remote>`.

We can use clap to ensure there's at least one element (same for local),
but comparison of individual args and further validation (max 2, not two
of the same type) is now left to `josh-proxy.rs`.

For this, a `make_upstream` is introduced, turning that list of enums
with URLs into a JoshProxyUpstream.

Error handling in run_proxy isn't awfully verbose, just exit nonzero, so
I opted to log *that* specific error with an eprintln!, but happy to
also add it for all errors (in main()).

This is in preparation for
josh-project#1288.
@flokli flokli mentioned this issue Nov 1, 2023
Merged
flokli added a commit to flokli/josh that referenced this issue Nov 1, 2023
@flokli
josh-proxy: use clap derive
6174e7a 
This simplifies the argument parsing a lot - we can almost parse the
needed structure just with that, including all the manual default
handling.

The only thing that does change is the handling of upstreams - rather
than populating two fields in the Arg struct, it now contains a
`Vec<Remote>`.

We can use clap to ensure there's at least one element (same for local),
but comparison of individual args and further validation (max 2, not two
of the same type) is now left to `josh-proxy.rs`.

For this, a `make_upstream` is introduced, turning that list of enums
with URLs into a JoshProxyUpstream.

Error handling in run_proxy isn't awfully verbose, just exit nonzero, so
I opted to log *that* specific error with an eprintln!, but happy to
also add it for all errors (in main()).

This is in preparation for
josh-project#1288.
flokli added a commit to flokli/josh that referenced this issue Nov 1, 2023
@flokli
josh-proxy: use clap derive
7d7f4b3 
This simplifies the argument parsing a lot - we can almost parse the
needed structure just with that, including all the manual default
handling.

The only thing that does change is the handling of upstreams - rather
than populating two fields in the Arg struct, it now contains a
`Vec<Remote>`.

We can use clap to ensure there's at least one element (same for local),
but comparison of individual args and further validation (max 2, not two
of the same type) is now left to `josh-proxy.rs`.

For this, a `make_upstream` is introduced, turning that list of enums
with URLs into a JoshProxyUpstream.

Error handling in run_proxy isn't awfully verbose, just exit nonzero, so
I opted to log *that* specific error with an eprintln!, but happy to
also add it for all errors (in main()).

This is in preparation for
josh-project#1288.
@flokli
Copy link
Contributor Author

flokli commented Nov 1, 2023

I decided to refactor the CLI parsing to clap derive first: #1292

flokli added a commit to flokli/josh that referenced this issue Nov 1, 2023
@flokli
josh-proxy: use clap derive
c4cb553 
This simplifies the argument parsing a lot - we can almost parse the
needed structure just with that, including all the manual default
handling.

The only thing that does change is the handling of upstreams - rather
than populating two fields in the Arg struct, it now contains a
`Vec<Remote>`.

We can use clap to ensure there's at least one element (same for local),
but comparison of individual args and further validation (max 2, not two
of the same type) is now left to `josh-proxy.rs`.

For this, a `make_upstream` is introduced, turning that list of enums
with URLs into a JoshProxyUpstream.

Error handling in run_proxy isn't awfully verbose, just exit nonzero, so
I opted to log *that* specific error with an eprintln!, but happy to
also add it for all errors (in main()).

This is in preparation for
josh-project#1288.
flokli added a commit to flokli/josh that referenced this issue Nov 1, 2023
@flokli
josh-proxy: use clap derive
18b36ba 
This simplifies the argument parsing a lot - we can almost parse the
needed structure just with that, including all the manual default
handling.

The only thing that does change is the handling of upstreams - rather
than populating two fields in the Arg struct, it now contains a
`Vec<Remote>`.

We can use clap to ensure there's at least one element (same for local),
but comparison of individual args and further validation (max 2, not two
of the same type) is now left to `josh-proxy.rs`.

For this, a `make_upstream` is introduced, turning that list of enums
with URLs into a JoshProxyUpstream.

Error handling in run_proxy isn't awfully verbose, just exit nonzero, so
I opted to log *that* specific error with an eprintln!, but happy to
also add it for all errors (in main()).

This is in preparation for
josh-project#1288.
christian-schilling pushed a commit that referenced this issue Nov 1, 2023
@flokli
josh-proxy: use clap derive (#1292)
465dd8f 
This simplifies the argument parsing a lot - we can almost parse the
needed structure just with that, including all the manual default
handling.

The only thing that does change is the handling of upstreams - rather
than populating two fields in the Arg struct, it now contains a
`Vec<Remote>`.

We can use clap to ensure there's at least one element (same for local),
but comparison of individual args and further validation (max 2, not two
of the same type) is now left to `josh-proxy.rs`.

For this, a `make_upstream` is introduced, turning that list of enums
with URLs into a JoshProxyUpstream.

Error handling in run_proxy isn't awfully verbose, just exit nonzero, so
I opted to log *that* specific error with an eprintln!, but happy to
also add it for all errors (in main()).

This is in preparation for
#1288.
@flokli
Copy link
Contributor Author

flokli commented Nov 6, 2023

This turned out to be a bit more complex, because of the whole logic in josh to create a symlink to itself as a git update hook, and then curling the server. If we end up supporting different listen methods, it doesn't necessarily know its "external URL".

I need to think more about this, we could add a --external-url CLI flag that'd somehow propagate down into the update hook, but it feels all a bit ugly. Do you have any ideas about that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@christian-schilling @flokli