Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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.


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;


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: