4 ms·

PSA: systemctl reload caddy will call this api. If you disable it, then reloading the server will no longer work.

mozey 3y ago
This default behaviour makes sense. If you're going to be using it for hosting in production, then read the documentation, and it's trivial to disable. If I recall, AWS has a similar default for some services. That is, access to the subnet (VPC) gives you full access to the attached service, no password required.
- jarym 3y ago
  Do you recall which AWS services are like this? Thinking I better check a few things!
  - rekoil 3y ago
    If you have any old S3 buckets, listing the index used to (in relative terms quite a long time ago) be enabled by default.
    - jarym 3y ago
      Thanks!
- jbverschoor 3y ago
  And mongo, and many others packages with insane defaults. What if rm would by default just delete everything, as it assumes that makes sense? Stupid comparison, I know, also a stupid default.
- bravetraveler 3y ago
  Disagree, to a degree. It's fine to offer this for extended use cases (ie: restarting from a second, trusted, host) It would be more appropriate to handle signals, particularly SIGHUP. That's how most services have been handling reloads. It's fine to offer an admin API, especially if I want a peer to be able to affect the local instance, but this shouldn't be the position init is placed in. Put simply, the init process is what we depend on if everything else fails.
bravetraveler 3y ago
Too good for sighup? I deplore an API when signals should work perfectly fine
- francislavoie 3y ago
  Signals don't work on Windows. We want a unified API for all platforms. Also signals don't carry arguments, which is necessary to push a new config. At runtime, Caddy doesn't know where the config came from because config is just data.
  - bravetraveler 3y ago
    Apologies in advance, I'm not trying to be mean spirited or too critical. I'm limited in my ability to express at the moment, on mobile. The API can still be there, I'm just asking for better integration where feasible. Signal handling on Linux/similar It's silly to tell my init process to go out 'to the network' to do something it can do directly against the child. I would not expect turning off an admin API to effectively limit my way to administer the process. Services will generally ordain a path for a config, overridable with arguments. The same file used then is what is re-read on reload. Argument/command line changing during a reload isn't a thing, that's restarting. We give it config files as an argument (or implicit default) so that can be reloaded. It's uncommon to start a process with one file, decide you want a new file path, but keep the PID.
    - francislavoie 3y ago
      See https://news.ycombinator.com/item?id=37482096 https://news.ycombinator.com/item?id=37482096, the plan is to switch to unix socket by default on certain distributions of Caddy. But it won't be possible to add signals support. We've thought hard about it but it's simply not a fit. There's discussion in GitHub: https://github.com/caddyserver/caddy/issues/3967 https://github.com/caddyserver/caddy/issues/3967
      - bravetraveler 3y ago

This default behaviour makes sense. If you're going to be using it for hosting in production, then read the documentation, and it's trivial to disable. If I recall, AWS has a similar default for some services. That is, access to the subnet (VPC) gives you full access to the attached service, no password required.

jarym 3y ago
Do you recall which AWS services are like this? Thinking I better check a few things!
- rekoil 3y ago
  If you have any old S3 buckets, listing the index used to (in relative terms quite a long time ago) be enabled by default.
  - jarym 3y ago
    Thanks!
jbverschoor 3y ago
And mongo, and many others packages with insane defaults. What if rm would by default just delete everything, as it assumes that makes sense? Stupid comparison, I know, also a stupid default.
bravetraveler 3y ago
Disagree, to a degree. It's fine to offer this for extended use cases (ie: restarting from a second, trusted, host) It would be more appropriate to handle signals, particularly SIGHUP. That's how most services have been handling reloads. It's fine to offer an admin API, especially if I want a peer to be able to affect the local instance, but this shouldn't be the position init is placed in. Put simply, the init process is what we depend on if everything else fails.

bravetraveler 3y ago

Too good for sighup? I deplore an API when signals should work perfectly fine

francislavoie 3y ago
Signals don't work on Windows. We want a unified API for all platforms. Also signals don't carry arguments, which is necessary to push a new config. At runtime, Caddy doesn't know where the config came from because config is just data.
- bravetraveler 3y ago
  Apologies in advance, I'm not trying to be mean spirited or too critical. I'm limited in my ability to express at the moment, on mobile. The API can still be there, I'm just asking for better integration where feasible. Signal handling on Linux/similar It's silly to tell my init process to go out 'to the network' to do something it can do directly against the child. I would not expect turning off an admin API to effectively limit my way to administer the process. Services will generally ordain a path for a config, overridable with arguments. The same file used then is what is re-read on reload. Argument/command line changing during a reload isn't a thing, that's restarting. We give it config files as an argument (or implicit default) so that can be reloaded. It's uncommon to start a process with one file, decide you want a new file path, but keep the PID.
  - francislavoie 3y ago
    See https://news.ycombinator.com/item?id=37482096 https://news.ycombinator.com/item?id=37482096, the plan is to switch to unix socket by default on certain distributions of Caddy. But it won't be possible to add signals support. We've thought hard about it but it's simply not a fit. There's discussion in GitHub: https://github.com/caddyserver/caddy/issues/3967 https://github.com/caddyserver/caddy/issues/3967
    - bravetraveler 3y ago