3 ms·
Existing or everyone-collaborates-on-a-single-upstream nginx packages are just as much of a risk, though. Things can fail subtly based on the order of the comp
by btown 11y ago
Existing or everyone-collaborates-on-a-single-upstream nginx packages are just as much of a risk, though.
Things can fail subtly based on the order of the compilation flags used in, for instance, mainline https://packages.debian.org/sid/nginx-extras https://packages.debian.org/sid/nginx-extras ... because the order of compilation flags, not the order of directives in the nginx config files, determines (for instance) whether gunzipping is done before or after string substitution.
I'd much rather know and document exactly what flags are going in, in what order, and when, rather than accept defaults that might not even work for my given case. Make this into an Ansible role, make sure all source code is coming from a trusted location (maybe a fork you own), and you've got a reproducible way to generate a reliable nginx deployment.
- cm3 11y agoFair enough but a ports or portage recipe with use flags that are known to work are more likely to produce the expected results and do so for everyone rather one for the few custom builders who do it right. My concern is based on the fact that I see rebuilding nginx as part of getting started guides for many things, including rtmp streaming and since these guides are usually followed by less knowledgeable nginx users who say just want to stream, the numbers of broken or vulnerable nginx setups increases substantially. How many of those setups would be up to date if they were installed via a ports tree compared to the current manual configure and make steps and need to follow nginx upstream for new releases. In pkgsrc, gentoo, nix, etc. others already took care of that and you just have to run e.g. emerge.