How to patch and/or upgrade Nginx from source in production environment?
teward at thomas-ward.net
Thu Oct 13 16:10:09 UTC 2022
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
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.
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?
> 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
> 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...
More information about the nginx