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!
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é.