11 ms·
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 rec
by 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 agoDo you recall which AWS services are like this? Thinking I better check a few things!
- jbverschoor 3y agoAnd 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 agoDisagree, 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.