Remplacer la configuration http nginx par défaut sans modifier nginx.conf par défaut


14

Mon intention : je voudrais remplacer la configuration par défaut définie dans /etc/nginx/nginx.conf(dans debian 8). L'idée est de garder ce fichier complètement intact pour faciliter les futures mises à jour du système et pouvoir obtenir les dernières modifications pour les options que je n'ai pas remplacées.

Ce que j'ai fait : j'ai créé une configuration personnalisée de /etc/nginx/conf.d/la même manière que pour plusieurs autres services Debian.

Problème : Cependant, il semble impossible de remplacer une configuration, car je reçois une directive "X" est une erreur en double . Nginx ne semble pas prendre en charge la substitution de configuration de la même manière que les autres services.

Question : Existe-t-il un moyen de remplacer et d'ajouter une nouvelle option au contexte http nginx sans obtenir la directive est une erreur en double ? Ou devrais-je abandonner complètement l'idée et déchaîner nginx.conf?

Merci beaucoup pour votre aide.

Cette question similaire ne résout pas vraiment mon problème, car je veux également profiter des options par défaut nginx définies automatiquement pour moi (par exemple worker_processes auto;)


1
Êtes-vous vraiment prêt à utiliser Debian? Leur configuration nginx est assez différente de l'amont, et cela pourrait ne pas être possible.
Michael Hampton

Oui. J'ai plusieurs serveurs de production fonctionnant déjà sur Debian et il s'agit de changer apache2 en nginx uniquement. Donc, ce que vous me dites, c'est que dans une autre distribution, ce que j'ai essayé peut fonctionner? Y a-t-il une chance que cela fonctionne à l'avenir avec Debian?
Gui-Don

Il est certainement possible que Debian fournisse une configuration nginx plus sensible à l'avenir. Vous pouvez également créer le vôtre.
Michael Hampton

Réponses:


2

Ou devrais-je abandonner complètement l'idée et déchaîner le nginx.conf?

Oui tu devrais.

Les seuls changements jamais effectués par les mainteneurs de packages sont soit

  • des valeurs par défaut plus sensibles pour les paramètres que vous auriez dû configurer vous-même il y a très longtemps
  • #-exemples préfixés qui ne seraient pas utilisés sans votre action de toute façon

Dans le passé, les seuls changements importants étaient ssl_protocols, ssl_prefer_server_cipherset worker_processes. Vous auriez dû les remplacer de toute façon des années avant de les définir dans le paquet deb semblait une chose raisonnable à faire pour les responsables du paquet.

Dans le passé, la seule véritable atténuation qui aurait pu être fournie avec un nginx.conf à l'échelle du système, ajoutant max_ranges 1;pour CVE-2017-7529 n'a été fournie par aucune distribution à ma connaissance, ils ont publié le correctif de la vulnérabilité avant la plupart des administrateurs, même appliqué l'atténuation.

Vous ne pouvez pas vous attendre à ce que les mainteneurs de paquets soient plus rapides que vous ne le faites en ajoutant des modifications potentiellement cassantes, vous ne profiterez donc probablement pas de l'héritage de leur configuration. Les responsables de packages ne peuvent pas savoir ce qui est le mieux pour les millions de cas d'utilisation et seront donc extrêmement prudents en modifiant les valeurs ici.

Tant que votre système de sauvegarde fonctionne correctement, c'est probablement une bonne idée de garder la configuration en place, de sorte qu'apt vous demandera pendant les mises à jour interactives comment agir sur les modifications du responsable du fichier de configuration.


Comment déterminez-vous quelles modifications ont été appliquées entre les différentes versions? Vous pouvez comparer toutes les versions de packages disponibles (non vérifiées, téléchargées de manière non sécurisée) comme ceci:

(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)

L'histoire apporte en effet des informations précieuses dans ce cas, alors merci pour cette très bonne réponse. Je comprends votre point de vue, compte tenu de l'importance de nginx dans le monde, il est hautement improbable qu'un changement de rupture important se produise pendant la durée de vie de mes serveurs HTTP.
Gui-Don

1
Je suis en désaccord avec cela. Bien qu'il soit peu probable que des problèmes surviennent à cause des changements du responsable, une configuration distincte aidera à réduire les coûts de maintenance ainsi qu'à avoir une meilleure structure et une migration plus facile vers différents serveurs, si le besoin se produit.
xZero

1
@xZero Êtes-vous en train de dire que la copie du fichier dans un autre emplacement contribuera à réduire les coûts de maintenance? Si oui, comment?
anx
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.