6 ms·

What's the benefit of this being built on top of Caddy, which unless I'm mistaken has historically been an HTTP(S) server? Maybe there's someone intrinsically g

What's the benefit of this being built on top of Caddy, which unless I'm mistaken has historically been an HTTP(S) server? Maybe there's someone intrinsically great about how Caddy works for this, but on first glance it feels like the scope creep in servers like Apache, or Curl's support for querying every data source under the sun. It can be handy having a single tool that does everything, but at the same time that gives an ever larger attack surface where suddenly your machine has been compromised via instructions from an MQTT server because Curl was installed.

francislavoie 5y ago
Caddy v2 is actually designed as an "app platform". The HTTP app is just one such type of app, and is what Caddy ships with by default. But it can be extended to do _anything_. See https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture You don't have to run both the HTTP app and the SSH app in the same process, you could have two separate Caddy processes configured to each do their own thing, if you're at all concerned.
- pantulis 5y ago
  Isn't this like a super-server in the spirit of inetd?
  - francislavoie 5y ago
    I guess, except Caddy doesn't spawn any processes, it just "starts apps" which are configured in-process, pure Go. Another example Caddy app is https://github.com/mholt/caddy-l4 https://github.com/mholt/caddy-l4 which lets you do arbitrary TCP/UDP handling/proxying. There's a list of available apps here https://caddyserver.com/docs/json/apps/ https://caddyserver.com/docs/json/apps/ (the SSH app is not there yet, should be soon)
    - jrockway 5y ago
      I think it's fine for a conceptual understanding. The Go runtime looks a lot like an OS, mapping G (goroutines) to Ms (worker threads), removing goroutines from the workers when they block in syscalls, waking up goroutines when a lock they want is available or a syscall finishes, etc. In the end it really depends on what you think of inetd as. If you think of it as "I install this one server and now I have finger and gopher!" then that seems similar to Caddy's applications. If you think of it as "whenever a TCP connection arrives, the fork() syscall is used to create a process to handle that session, file descriptors 0 and 1 are connected to the TCP socket, and then exec() according to the global config is run to handle the protocol", then ... no it's not the same as inetd.

francislavoie 5y ago

Caddy v2 is actually designed as an "app platform". The HTTP app is just one such type of app, and is what Caddy ships with by default. But it can be extended to do _anything_. See https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture You don't have to run both the HTTP app and the SSH app in the same process, you could have two separate Caddy processes configured to each do their own thing, if you're at all concerned.

pantulis 5y ago
Isn't this like a super-server in the spirit of inetd?
- francislavoie 5y ago
  I guess, except Caddy doesn't spawn any processes, it just "starts apps" which are configured in-process, pure Go. Another example Caddy app is https://github.com/mholt/caddy-l4 https://github.com/mholt/caddy-l4 which lets you do arbitrary TCP/UDP handling/proxying. There's a list of available apps here https://caddyserver.com/docs/json/apps/ https://caddyserver.com/docs/json/apps/ (the SSH app is not there yet, should be soon)
  - jrockway 5y ago
    I think it's fine for a conceptual understanding. The Go runtime looks a lot like an OS, mapping G (goroutines) to Ms (worker threads), removing goroutines from the workers when they block in syscalls, waking up goroutines when a lock they want is available or a syscall finishes, etc. In the end it really depends on what you think of inetd as. If you think of it as "I install this one server and now I have finger and gopher!" then that seems similar to Caddy's applications. If you think of it as "whenever a TCP connection arrives, the fork() syscall is used to create a process to handle that session, file descriptors 0 and 1 are connected to the TCP socket, and then exec() according to the global config is run to handle the protocol", then ... no it's not the same as inetd.