Quels sont les différents usages pour les sites disponibles par rapport au répertoire conf.d pour nginx

99

J'ai un peu d'expérience avec Linux, mais aucun avec 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 semble aller pour le mieux.

J'ai quelques questions.

Quelle est la différence entre le dossier sites-available et le dossier conf.d. Ces deux dossiers étaient inclus dans la configuration par défaut de nginx. Les tutoriels utilisent les deux. A quoi servent-ils et quelle est la meilleure pratique?

A quoi sert le dossier activé par sites? Comment puis-je l'utiliser?

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?

Seth Spearman
la source
Essayez d’éviter un glissement de la portée lorsque vous posez une question. www-dataest un sujet séparé. La plupart des systèmes d'exploitation définissent un utilisateur distinct disposant d'autorisations moins élevées que le processus peut exécuter après la liaison au port 80 en tant que root. C'est défini dans le fichier de configuration. Appliquer des pratiques de sécurité de base à partir de là; ne laissez pas l'utilisateur écrire dans quoi que ce soit sur le serveur Web, ni laisser les autres utilisateurs écrire dans les fichiers, à moins que ce ne soit délibéré.
Andrew B

Réponses:

94

Les dossiers sites- * sont gérés par nginx_ensiteet nginx_dissite. Pour les utilisateurs Apache httpd qui trouvent cela avec une recherche, l'équivalent est a2ensite/ a2dissite.

Le sites-availabledossier sert à stocker toutes vos configurations vhost, qu'elles soient actuellement activées ou non.

Le sites-enableddossier contient des liens symboliques vers des fichiers du dossier sites-available. Cela vous permet de désactiver sélectivement vhosts en supprimant le lien symbolique.

conf.dfait le travail, mais vous devez déplacer quelque chose hors du dossier, le supprimer ou le modifier lorsque vous avez besoin de désactiver quelque chose. L'abstraction de dossiers sites- * rend les choses un peu plus organisées et vous permet de les gérer avec des scripts de support distincts.

(sauf si vous êtes comme moi et l'un des nombreux administrateurs debian qui vient de gérer les liens symboliques directement, sans connaître les scripts ...)

Andrew B
la source
12
Ai-je eu quelque chose de mal? Ne pas comprendre le vote négatif.
Andrew B
1
Je suis curieux de savoir si cela est intégré à nginx? j'ai installé manuellement github.com/perusio/nginx_ensite
lfender6445
18
Il est important de noter que sites-available|sites-enabledc'est un Debian-ism et pas quelque chose que nginx ou Apache font. C'était probablement très utile dans le passé, mais son utilité est quelque peu limitée à l'ère de la gestion de la configuration et des conteneurs.
Michael Hampton
Pouvez-vous commenter comment la gestion de la configuration et les conteneurs limitent l'utilité des sites-available | sites-enabled?
Karthik Vee
1
@karthikvee Le fait est que de nos jours les serveurs apparaissent souvent comme des conteneurs éphémères ne servant qu'un site Web / service, ce qui permet de l'inclure nginx.confsans perte de lisibilité. C'est l'inverse de l'approche adoptée il y a quelques années, lorsque les serveurs stockaient normalement des dizaines de sites Web.
Adamczi
38

J'aimerais ajouter aux réponses précédentes que le plus important n'est pas comment vous appelez les répertoires (bien que ce soit une convention très utile), mais ce que vous avez réellement mis en place 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 eg 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 initiale: 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 donnés dans les autres réponses. Et s'il vous plaît, n'oubliez pas de choisir la «bonne» réponse.

Yaroslav Nikitenko
la source
1
Droite, sites-enableda été inventé par une certaine distribution, comme un intermédiaire agaçant. Allez chercher nginx de la source officielle : vous obtiendrez un produit à jour, ainsi que de vous débarrasser de cette configuration merde / enfer.
Bernard Rosset
2
Cela explique pourquoi il n’existe pas une seule référence de cette convention de noms dans la documentation officielle de Nginx. C'est un projet tiers! github.com/perusio/nginx_ensite
AxeEffect
30

En règle générale, le sites-enableddossier est utilisé pour les définitions d'hôte virtuel, tandis que conf.dpour la configuration du serveur global. Si vous prenez en charge plusieurs sites Web, c’est-à-dire des hôtes virtuels, chacun d’entre eux reçoit son propre fichier. Vous pouvez ainsi les activer et les désactiver très facilement en déplaçant des fichiers vers l’extérieur sites-enabled(ou en créant et supprimant des liens une meilleure idée).

Utilisez-le conf.dpour des tâches telles que le chargement de modules, les fichiers journaux et d'autres éléments non 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?

Nginx devrait s'exécuter en tant qu'utilisateur non root. Ceci est dans certains cas nommé www-data, mais vous pouvez le nommer comme vous voulez.

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

Je suis moins certain de la réponse à cette question (je ne tourne pas nginx pour le moment), mais si Apache ressemble à autre chose, la réponse est que l' www-datautilisateur n'a besoin que de permissions de lecture sur tous les fichiers statiques (et de lire + exécuter des répertoires ) que vous distribuez, ou que vous lisiez / exécutiez des autorisations sur des éléments tels que les scripts CGI, et qu’aucune autorisation n’ait été effectuée ailleurs.

alsacs
la source
1
Il est également important de disposer d'un utilisateur dédié à l'exécution du serveur Web en raison de la désactivation de la connexion pour cet utilisateur en supprimant un enregistrement shell valide.
DukeLion
> 'Vous devriez avoir nginx exécuté en tant qu'utilisateur non root' - pourriez-vous en dire plus à ce sujet?
lfender6445
1
Exécuter en tant qu'utilisateur non privilégié est un moyen de limiter les dommages pouvant résulter d'une compromission à distance. Si vous exécutez un serveur Web en tant que rootet qu’il existe un type de compromission à distance, l’attaquant dispose immédiatement d’un accès complet au système. Lorsqu'il est exécuté en tant qu'utilisateur non privilégié, l'accès administratif ne sera disponible qu'en combinaison avec une sorte d'exploit local.
larsks
14

Que se passe-t-il?

Vous devez utiliser Debian ou Ubuntu, car evil sites-available / sites-enabledlogic n'est pas utilisé par le paquetage en amont de nginx à partir de http://nginx.org/packages/ .

Dans les deux cas, les deux sont implémentés en tant que convention de configuration à l'aide de la includedirective standard de /etc/nginx/nginx.conf.

Voici un extrait d' /etc/nginx/nginx.confun paquet officiel en amont de nginx de nginx.org:

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

Voici un extrait de /etc/nginx/nginx.confDebian / Ubuntu :

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

Ainsi, du point de vue de NGINX, la seule différence serait que les fichiers conf.dsoient traités plus rapidement et, en tant que tels, si vous avez des configurations qui se font mutuellement conflit, alors celles-ci conf.dpeuvent avoir priorité sur celles de sites-enabled.


La meilleure pratique est conf.d.

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

Si vous devez désactiver un site, renommez simplement le nom du fichier pour qu'il ne soit plus doté d'un .confsuffixe, ce qui est très facile, simple et sans erreur:

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

Ou l'inverse pour activer un site:

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


Éviter sites-availableet sites-enabledà tout prix.

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

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

  • Et si vous n'utilisez pas les scripts (ce qui est en fait un choix judicieux, comme indiqué ci-dessus), la gestion de ces sites pose alors le problème suivant:

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

Ce qui précède peut sembler être un problème mineur à résoudre, jusqu'à ce que plusieurs personnes commencent à gérer le système ou jusqu'à ce que vous preniez une décision rapide, mais que vous l'oublieriez des mois ou des années plus tard…

Ce qui nous amène à:

  • Est-il prudent de supprimer un fichier sites-enabled? Est-ce un lien symbolique? Un lien dur? Ou la seule copie de la configuration? Un excellent exemple de configuration enfer.

  • 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 utilisez-les grep -v.)

Non seulement tout ce qui précède, mais aussi la includedirective 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 à l'intérieur /etc/nginx/sites-enabled, et que vous emacscréez un fichier de sauvegarde default~, alors, vous avez soudainement les deux defaultet default~inclus en tant que configuration active, qui, selon les directives utilisées, peut même ne pas donner vous avertissez et provoquez une session de débogage prolongée. (Oui, cela m'est arrivé; c'était lors d'un hackathon et j'étais totalement perplexe de savoir pourquoi ma conférence ne fonctionnait pas.)

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

cnst
la source
En plus de tout ce qui précède, apparemment, il est également très courant de créer des liens symboliques incorrects! stackoverflow.com/a/14107803/1122270 Juste au cas où vous ne pensiez pas que sites-enabledc'était assez maléfique!
cnst
Ou, parfois, il peut arriver que quelqu'un décide d'éditer les fichiers sites-enabled, mais une autre personne décide de le désactiver en le supprimant, pensant peut-être qu'il ne s'agissait que d'un lien symbolique, nécessitant un dump mémoire ultérieur de nginx heap pour récupérer le fichier conf: stackoverflow.com/q/45852224/1122270
cnst
Je suis en désaccord avec les affirmations concernant sites-availableet sites-enabled; il est important de pouvoir préparer des fichiers de configuration en dehors du répertoire de collecte «en direct», de telle sorte que si nginx était rechargé ou redémarré, il ne récupérerait pas les fichiers de configuration partiels. Il peut également être utile de conserver les fichiers de configuration qui ne sont plus utilisés activement. Créer des liens symboliques n’est pas une tâche particulièrement difficile si vous avez suffisamment d’expérience pour gérer nginx, IMO.
BE77Y
@ BE77Y vous prenez une approche plus compliquée. En programmation, il est considéré comme la meilleure pratique de supprimer complètement le code inutilisé, pas simplement de le désactiver ou de le commenter. Je ne vois aucune raison pour que DevOps soit différent - si une configuration n'est plus nécessaire, supprimez-la (elle devrait toujours exister dans votre VCS). Idem pour les fichiers de configuration partiels - pourquoi les éditeriez-vous et laisseriez-vous rechargé nginx dans votre dos? ( USR1, qui rouvre les journaux, ne recharge pas la conf.) Je trouve votre commentaire "d'expérience" de lien symbolique mal dirigé - le problème est une question de cohérence, qui a peu à voir avec l'expérience.
cnst
2
Il est clair que a) ce n’est pas le support approprié pour cette discussion et peut-être plus important encore, b) que cela sera probablement stérile dans tous les cas. Disons que l'on n'est pas d'accord.
BE77Y