My intention: I would like to override default configuration defined in /etc/nginx/nginx.conf (in debian 8). The idea is to keep this file completely untouched to ease future system updates and be able to get the latest changes for the options I did not override.

What I did: I created a custom configuration in the /etc/nginx/conf.d/ the same way I did for several other debian services.

Problem: However, it seems impossible to override some configuration, because I get a "X" directive is duplicate error. Nginx does not seems to support configuration override the same way other services does.

Question: Is there a way to override and add new option to the nginx http context without getting the directive is duplicate error? Or should I completely abandon the idea and rampage the nginx.conf?

Many thanks for your help.

This similar question does not really solve my problem, because I also want to profit from default options nginx set automatically for me (e.g. worker_processes auto;)

  • 1
    Are you really set on using Debian? Their nginx configuration is quite different to upstream, and this might not be possible. – Michael Hampton Jan 10 '17 at 19:03
  • Yes. I have several production servers already running on Debian and this is about changing apache2 to nginx only. So, what you are telling me is that in other distribution, what I tried may be working? Is there a chance that it will work in the future with Debian? – Gui-Don Jan 11 '17 at 10:18
  • It's certainly possible that Debian will ship a more sensible nginx configuration in the future. You could also just create your own. – Michael Hampton Jan 11 '17 at 17:02

Or should I completely abandon the idea and rampage the nginx.conf?

Yes, you should.

The only changes that are ever done by package maintainers are either

  • more sensible defaults for parameters you should have setup yourself a looong time ago anyway
  • #-prefixed examples that would not be used without your action anyway

In the past, the only significant changes were ssl_protocols, ssl_prefer_server_ciphers and worker_processes. You should have been overriding those anyway years before setting them in the deb package seemed like a reasonable thing to do for the package maintainers.

In the past, the only real mitigation that could have been shipped with a system-wide nginx.conf, adding max_ranges 1; for CVE-2017-7529 was not shipped by any distribution i know of, they released the fix for he vulnerability before most admins even applied the mitigation.

You cannot expect package maintainers to be faster than you are in adding potentially breaking changes, thus you will probably not profit from inheriting their config. Package maintainers cannot know whats best for the millions of use cases out there and thus will be extremely conservative in changing values here.

As long as your backup system works properly, its likely still a good idea to keep the config in place, so that apt will ask you during interactive updates how to act upon maintainer changes to the config file.

How do you figure out what changes were applied between different releases? You can compare all (unverified, insecurely downloaded) available package versions like this:

(cd "$(mktemp -d)"; rmadison --url=debian nginx-common | awk '{print $3}' | while read a; do curl "http://ftp.debian.org/debian/pool/main/n/nginx/nginx-common_${a}_all.deb" | dpkg -x - x${a}; done; for a in x*/etc/nginx/nginx.conf; do [ -z "$la" ] && la="$a" && continue; diff -wus "$la" "$a";la="$a" ; done; pwd)
  • History does indeed brings valuable information in this case, so thanks for this very good answer. I understand your point, considering the importance of nginx worldwide, it’s highly improbable an important breaking change will occur in the lifetime of my HTTP servers. – Gui-Don Nov 8 '17 at 10:22
  • 2
    I disagree with this. Whilst it's unlikely that problems will occur because of maintainer's changes, having separate config will help reduce maintenance costs as well as have better structure and easier migration to different server, shall the need occur. – xZero Apr 9 '19 at 9:27
  • 1
    @xZero Are you saying that copying the file into another location will help reduce maintenance costs? If so, how so? – anx Apr 9 '19 at 9:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.