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?

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

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.

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.

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!