web-dev-qa-db-fra.com

Quelles sont les différentes utilisations des sites disponibles par rapport au répertoire conf.d pour nginx

J'ai une certaine expérience en utilisant Linux mais aucune en utilisant Nginx. J'ai été chargé de rechercher des options d'équilibrage de charge pour un serveur d'applications.

J'ai utilisé apt-get pour installer nginx et tout va bien.

J'ai quelques questions.

Quelle est la différence entre le dossier sites disponibles et le dossier conf.d. Ces deux dossiers ont été INCLUS dans la configuration de configuration par défaut pour nginx. Les didacticiels utilisent les deux. À quoi servent-ils et quelle est la meilleure pratique?

À quoi sert le dossier compatible avec les sites? Comment est-ce que je l'utilise?

La configuration par défaut fait référence à un utilisateur www-data? Dois-je créer cet utilisateur? Comment donner à cet utilisateur des autorisations optimales pour exécuter nginx?

linuxubuntunginxweb-serverconfiguration
112
Seth Spearman

Les dossiers sites- * sont gérés par nginx_ensite Et nginx_dissite. Pour les utilisateurs Apache httpd qui trouvent cela avec une recherche, les équivalents sont a2ensite/a2dissite.

Le dossier sites-available Est destiné au stockage tous de vos configurations vhost, qu'elles soient actuellement activées ou non.

Le dossier sites-enabled Contient des liens symboliques vers des fichiers dans le dossier des sites disponibles. Cela vous permet de désactiver sélectivement les hôtes virtuels en supprimant le lien symbolique.

conf.d Fait le travail, mais vous devez déplacer quelque chose hors du dossier, le supprimer ou y apporter des modifications lorsque vous devez désactiver quelque chose. L'abstraction du dossier sites- * rend les choses un peu plus organisées et vous permet de les gérer avec des scripts de support séparés.

(sauf si vous êtes comme moi, et l'un des nombreux administrateurs Debian qui ont juste géré les liens symboliques directement, ne connaissant pas les scripts ...)

103
Andrew B

Je voudrais ajouter aux réponses précédentes que le plus important n'est pas la façon dont vous appelez les répertoires (bien que ce soit une convention très utile), mais ce que vous avez réellement mis dans nginx.conf. Exemple de configuration:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;
...
}

La seule directive utilisée ici est include , il n'y a donc pas de différence interne entre par exemple conf.d/ et sites-enabled/.

De la documentation ci-dessus:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

Donc, pour répondre à la question d'origine: il n'y a pas de différence interne, et vous pouvez les utiliser de la meilleure façon possible, en vous souvenant des conseils des autres réponses. Et n'oubliez pas de choisir la "bonne" réponse.

42
Yaroslav Nikitenko

En règle générale, le sites-enabled le dossier est utilisé pour les définitions d'hôte virtuel, tandis que conf.d est utilisé pour la configuration globale du serveur. Si vous prenez en charge plusieurs sites Web, c'est-à-dire des hôtes virtuels, alors chacun obtient son propre fichier, vous pouvez donc les activer et les désactiver très facilement en déplaçant des fichiers dans et hors de sites-enabled (ou créer et supprimer des liens symboliques, ce qui est probablement une meilleure idée).

Utilisation conf.d pour des choses comme le chargement de modules, les fichiers journaux et d'autres choses qui ne sont pas spécifiques à un seul hôte virtuel.

La configuration par défaut fait référence à un utilisateur www-data? Dois-je créer cet utilisateur?

Vous devriez avoir nginx en cours d'exécution en tant qu'utilisateur non root. Il s'agit dans certains cas de www-data, mais vous pouvez le nommer comme vous voulez.

Comment donner à cet utilisateur des autorisations optimales pour exécuter nginx?

Je ne suis pas certain de la réponse à cette question (je ne lance pas nginx pour le moment), mais si c'est quelque chose comme Apache, la réponse est que le www-data l'utilisateur n'a besoin que des autorisations de lecture sur tous les fichiers statiques (et lecture + exécution sur les répertoires) que vous servez, ou des autorisations de lecture/exécution sur des choses comme les scripts CGI, et aucune autorisation nulle part ailleurs.

32
larsks

Que se passe-t-il?

Vous devez utiliser Debian ou Ubuntu, car le evilsites-available/sites-enabled la logique n'est pas utilisée par le empaquetage en amont de nginx de http://nginx.org/packages/ .

Dans les deux cas, les deux sont implémentés comme une convention de configuration à l'aide de la directive standard include dans /etc/nginx/nginx.conf.

Voici un extrait de /etc/nginx/nginx.conf à partir d'un package amont officiel de nginx de nginx.org:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

Voici un extrait de /etc/nginx/nginx.conf de Debian/Ubunt :

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Donc, du point de vue de NGINX, la seule différence serait que les fichiers de conf.d doit être traité plus tôt et, en tant que tel, si vous avez des configurations qui entrent en conflit silencieusement, alors celles de conf.d peut prévaloir sur ceux de sites-enabled.

La meilleure pratique est conf.d.

Vous devez utiliser /etc/nginx/conf.d, car c'est une convention standard, et devrait fonctionner n'importe où.

Si vous devez désactiver un site, renommez simplement le nom de fichier pour ne plus avoir de .conf suffixe, très simple, simple et sans erreur:

Sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

Ou l'inverse de activer un site:

Sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}

Éviter sites-available & sites-enabled À tout prix.

Je ne vois absolument aucune raison d'utiliser sites-available/sites-enabled:

  • Certaines personnes ont mentionné nginx_ensite et nginx_dissite scripts - les noms de ces scripts sont encore pires que le reste de cette débâcle - mais ces scripts sont également introuvables - ils sont absents du package nginx même dans Debian (et probablement dans Ubuntu , également), et non présent dans un package qui leur est propre, en plus, avez-vous vraiment besoin d'un script tiers non standard pour déplacer et/ou lier simplement les fichiers entre les deux répertoires?!

  • Et si vous n'utilisez pas les scripts (ce qui est, en fait, un choix intelligent comme ci-dessus), il se pose alors la question de savoir comment gérer les sites:

    • Créez-vous des liens symboliques à partir de sites-available à sites-enabled?
    • Copiez les fichiers?
    • Déplacer les fichiers?
    • Modifiez les fichiers en place dans sites-enabled?

Ce qui précède peut sembler quelques problèmes mineurs à résoudre, jusqu'à ce que plusieurs personnes commencent à gérer le système, ou jusqu'à ce que vous preniez une décision rapide, pour ne l'oublier que des mois ou des années plus tard ...

Ce qui nous amène à:

  • Est-il sûr de supprimer un fichier de sites-enabled? Est-ce un lien souple? Un lien dur? Ou la seule copie de la configuration? Un excellent exemple d'enfer de configuration.

  • Quels sites ont été désactivés? (Avec conf.d, faites simplement une recherche d'inversion pour les fichiers ne se terminant pas par .conf - find /etc/nginx/conf.d -not -name "*.conf", Ou utiliser grep -v .)

Non seulement tout ce qui précède, mais notez également la directive include spécifique utilisée par Debian/Ubuntu - /etc/nginx/sites-enabled/* - aucun suffixe de nom de fichier n'est spécifié pour sites-enabled, contrairement à conf.d.

  • Cela signifie que si un jour vous décidez de modifier rapidement un fichier ou deux dans /etc/nginx/sites-enabled, et votre emacs crée un fichier de sauvegarde comme default~, puis, tout à coup, vous avez à la fois default et default~ inclus en tant que configuration active qui, selon les directives utilisées, peut même ne pas vous avertir et entraîner une session de débogage prolongée. (Oui, cela m'est arrivé; c'était pendant un hackathon, et j'étais totalement perplexe de savoir pourquoi ma conf ne fonctionnait pas.)

Ainsi, je suis convaincu que sites-enabled est du mal pur!

19
cnst