My primary driving reason for considering the deployment of Nginx from
source is to use ModSecurity WAF with Nginx. I'm under the impression that
it's much easier to use ModSecurity with Nginx when compiled from source.
My only goal of installing patches would simply be to keep the install up
to date from a security and/or stability perspective.
Finally, in part this install would be a goal of mine to learn to patch and
maintain a source installation.
Ed
On Thu, Oct 13, 2022 at 5:09 PM PGNet Dev <pgnet.dev@gmail.com> wrote:
> > I don't know the process to install patches.
>
> That's a big ol' red flag. Personally, I'd strongly recommend against
> building/installing into a *production* env, until you're up to snuff with
> managing the sources, including patches.
>
> That said, are you solving for a real/existing production problem you
> have? Or more a want-to-learn-how-to-build exercise?
>
> Looking here
>
> https://packages.ubuntu.com/search?keywords=nginx
>
> https://changelogs.ubuntu.com/changelogs/pool/main/n/nginx/nginx_1.18.0-6ubuntu14.2/changelog
>
> https://changelogs.ubuntu.com/changelogs/pool/main/n/nginx/nginx_1.22.0-1ubuntu1/changelog
>
> at first glance it sure looks like sources/packages are actively patched &
> maintained
>
> Is there a specific example of an nginx patch your production environment
> needed that isn't/wasn't acted upon?
> If so, had your raised it first with the maintainers, and they refused or
> failed to act?
> Or is there a version that you need for valid reasons that isn't available
> to you?
>
>
> > pkgsrc [1] is the one of the good choices to automate builds and manage
> dependences in a non-root environment on your favorite operating system.
>
> +1
>
> there are many.
>
> each is its own rabbit-hole, with its own infrastructure & process
> gotchas. i.e., another layer of stuff/complexity. once mastered, sure --
> great to have.
>
>
>
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org
