3 ms·

Nice work, tons of extra stuff vs the original. Had a thought: imagine if it were a subcommand of nginx (whichever fork will accept it) - that’d give it a much

Nice work, tons of extra stuff vs the original. 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.

k1kingy 2y ago
'nginx -t' exists as a general syntax checker, would be neat to expand it further to include these in depth checks.
- progbits 2y ago
  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.
  - zelphirkalt 2y ago
    On the other hand, if it never checked those, you would run into problems, when you rely on those being available and somehow they are not.
  - ndsipa_pomu 2y ago
    Put the proxy settings into variables and you can sidestep that. It also allows NgINX to start up when the backends may not be running. e.g. set $upstream_app backend; set $upstream_port 8888; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port;
tetha 2y ago
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.

k1kingy 2y ago

'nginx -t' exists as a general syntax checker, would be neat to expand it further to include these in depth checks.

progbits 2y ago
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.
- zelphirkalt 2y ago
  On the other hand, if it never checked those, you would run into problems, when you rely on those being available and somehow they are not.
- ndsipa_pomu 2y ago
  Put the proxy settings into variables and you can sidestep that. It also allows NgINX to start up when the backends may not be running. e.g. set $upstream_app backend; set $upstream_port 8888; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port;

tetha 2y ago

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.