Had a thought: imagine if it were a subcommand of nginx (whichever fork will accept it) - that’d give it a much wider audience.
Even more impactful would be if analysis always ran at nginx startup. Wouldn’t have to be blocking but getting warned about risks would help more folks configure things more correctly more often.
Either way great to have tools to help with correctly configuring the parts of your infra that are exposed to the wild internet.
What's annoying about the built-in checker is that it attempts to connect proxypass backends. So if you want to run this in CI you will get connection refused errors.
On the other hand, I've grown to like these tools being separate, since it allows the check-tool to move faster. Updating the thing all of your production requests go through always has a bit of aprehension. Updating a config linter with no prod-impact? Meh, just do it.
However, this would be great if a distribution wanted to integrate it into their default nginx package (and maybe have a nginx-minimal package around to install nginx without it). Though e.g. debian has gotten hilarious amounts of flak in the past for attempting things like this.
Had a thought: imagine if it were a subcommand of nginx (whichever fork will accept it) - that’d give it a much wider audience.
Even more impactful would be if analysis always ran at nginx startup. Wouldn’t have to be blocking but getting warned about risks would help more folks configure things more correctly more often.
Either way great to have tools to help with correctly configuring the parts of your infra that are exposed to the wild internet.