Was ist los?
Sie müssen Debian oder Ubuntu verwenden, da das Böse sites-available / die sites-enabledLogik nicht von der Upstream-Paketierung von Nginx von http://nginx.org/packages/ verwendet wird .
In beiden Fällen werden beide mit Hilfe der Standard- includeDirektive in als Konfigurationskonvention implementiert /etc/nginx/nginx.conf.
Hier ist ein Ausschnitt /etc/nginx/nginx.confaus einem offiziellen Upstream-Paket von nginx von nginx.org:
http {
…
include /etc/nginx/conf.d/*.conf;
}
Hier ist ein Ausschnitt /etc/nginx/nginx.confaus Debian / Ubuntu :
http {
…
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Aus Sicht von NGINX besteht der einzige Unterschied darin, dass Dateien von conf.dfrüher verarbeitet werden. Wenn Sie also Konfigurationen haben, die im Hintergrund miteinander in Konflikt stehen, haben diese conf.dmöglicherweise Vorrang vor denen in sites-enabled.
Best Practice ist conf.d.
Sie sollten verwenden /etc/nginx/conf.d, da dies eine Standardkonvention ist, und sollten überall funktionieren.
Wenn Sie eine Site deaktivieren müssen, benennen Sie den Dateinamen einfach so um, dass er kein .confSuffix mehr hat. Dies ist sehr einfach, unkompliziert und fehlerfrei:
sudo mv -i /etc/nginx/conf.d/default.conf{,.off}
Oder das Gegenteil, um eine Site zu aktivieren :
sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}
Vermeiden sites-available& sites-enabledum jeden Preis.
Ich sehe absolut keinen Grund, sites-available/ zu benutzen sites-enabled:
Einige Leute haben nginx_ensiteund nginx_dissiteSkripte erwähnt - die Namen dieser Skripte sind noch schlimmer als der Rest dieses Debakels - aber diese Skripte sind auch nirgends zu finden - sie fehlen nginxsogar in Debian (und wahrscheinlich auch in Ubuntu) im Paket , und auch nicht in einem eigenen Paket vorhanden. Benötigen Sie wirklich ein nicht standardmäßiges Drittanbieter-Skript, um die Dateien einfach zwischen den beiden Verzeichnissen zu verschieben und / oder zu verknüpfen ?!
Und wenn Sie die Skripte nicht verwenden (was in der Tat eine gute Wahl ist, wie oben beschrieben), stellt sich die Frage, wie Sie die Websites verwalten:
- Erstellen Sie symbolische Links von
sites-availablebis sites-enabled?
- Dateien kopieren?
- Verschieben Sie die Dateien?
- Bearbeiten Sie die Dateien an Ort und Stelle in
sites-enabled?
Das oben Genannte scheint ein paar kleinere Probleme anzugehen, bis einige Leute anfangen, das System zu verwalten, oder bis Sie eine schnelle Entscheidung treffen, nur um es Monate oder Jahre später zu vergessen ...
Welches bringt uns zu:
Ist es sicher, eine Datei von zu entfernen sites-enabled? Ist es eine weiche Verbindung? Eine harte Verbindung? Oder die einzige Kopie der Konfiguration? Ein Paradebeispiel für die Hölle der Konfiguration.
Welche Websites wurden deaktiviert? (Führen Sie conf.dmit nur eine Inversionssuche nach Dateien durch, die nicht mit .conf- enden find /etc/nginx/conf.d -not -name "*.conf", oder verwenden Sie grep -v.)
Nicht nur all das oben Genannte, sondern auch die spezielle includeAnweisung, die von Debian / Ubuntu verwendet wird - /etc/nginx/sites-enabled/*- für sites-enabledwird im Gegensatz zu für kein Dateinamensuffix angegeben conf.d.
- Was dies bedeutet ist , dass , wenn Sie ein Tag entscheiden , um schnell eine Datei oder zwei innerhalb zu bearbeiten
/etc/nginx/sites-enabledund Ihre emacsBackup - Datei erstellt , wie default~, dann plötzlich, haben Sie beide defaultund default~als aktive Konfiguration enthalten, die je Richtlinien verwendet wird , kann nicht einmal geben Sie alle Warnungen und führen zu einer längeren Debugging-Sitzung. (Ja, es ist mir passiert; es war während eines Hackathons und ich war total verwirrt darüber, warum meine Konferenz nicht funktioniert hat.)
Daher bin ich überzeugt, dass sites-enableddas reine Böse ist!
www-dataist ein separates Thema. Die meisten Betriebssysteme definieren einen separaten Benutzer mit niedrigeren Berechtigungen, als den der Prozess nach dem Binden an Port 80 als Root ausgeführt werden kann. Es ist in der Konfigurationsdatei definiert. Wenden Sie von dort aus grundlegende Sicherheitspraktiken an. Lassen Sie den Benutzer nicht auf etwas schreiben, auf das der Webserver nicht schreiben muss. Lassen Sie andere Benutzer nur dann auf die Dateien schreiben, wenn dies beabsichtigt ist.