How to patch and/or upgrade Nginx from source in production environment?

[Thomas Ward]

If you're on Ubuntu you have some tradeoffs by doing this yourself.

You can surely uninstall the packages of nginx from Ubuntu and then 
compile and install it yourself on each system.  However, you will then 
need to redo this compiling and patch software yourself.  This is why 
the packaging exists in Ubuntu - to allow easy installation and patching 
of security vulns from the Security team (yes, Ubuntu Security Team and 
Ubuntu Server Team both work to patch nginx in the various releases of 
Ubuntu!).

You will lose that automated security patching, etc. and will have to 
recompile your software on every machine every time there's a security 
update if you do this yourself.

You can do the packaging yourself in a private repository (which will be 
basically a 'from source' compile with the configure options, etc. YOU 
want there to be), and then that package installs the compiled binaries, 
etc. to whatever system you install that package on, but again you then 
have to patch it yourself.


There's pros and cons to every approach, especially security related 
concerns for software patching.  The question is, how big is this 
'production environment' and do you want to have to recompile and 
reinstall every time there's a patch for a security problem.



Thomas


On 10/13/22 12:02, edflecko wrote:
> Thank you for your reply!
>
> I should have mentioned that I'm running in an Ubuntu environment so 
> I'm not sure if that makes much difference? I like the idea of 
> installing from source because I can control all of the options, but 
> I'm wondering if it's worth going that route in a production environment?
>
> Thoughts? Opinions?
>
> Ed
>
> On Thu, Oct 13, 2022 at 3:49 PM PGNet Dev <pgnet.dev at gmail.com> wrote:
>
>     Nginx is an easy build from source, thankfully.
>
>     Deploying tarbal'd local source-builds to other machines is not
>     terrible at all if you isolate your install DIR (e.g, 'everything'
>     under /opt/nginx); ansible is your friend.
>
>     But, it's a bit of a slog to deploy into usual distro env, avoid
>     collisions, and if needed, cleanly uninstall.  Certainly doable,
>     but can be messy.
>
>     To solve for that inconvenience, build your own packages from own
>     sources on an open build system (e.g., SUSE's OBS, Fedora's COPR,
>     etc), and install those packages via rpms.
>     Or for that matter, even local rpmbuilds should be portable, as
>     long as you correctly account for differences in target deployment
>     ENVs.
>
>     yes, rpm .spec files can be annoying. it's a trade-off.
>
>
>     > I'm curious how many people run Nginx in a production
>     environment that was installed from source and not a package.
>     >
>     > For those people who are running Nginx in this manner, how do
>     you keep Nginx patched when patches are released?
>     >
>     > How do you upgrade your existing Nginx in your production
>     environment while minimizing downtime?
>     >
>     > Thank you,
>     > Ed
>     >
>     > _______________________________________________
>     > nginx mailing list -- nginx at nginx.org
>     > To unsubscribe send an email to nginx-leave at nginx.org
>
>
> _______________________________________________
> nginx mailing list --nginx at nginx.org
> To unsubscribe send an email tonginx-leave at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221013/8a7cb7b6/attachment.htm>