Frage Was sind die verschiedenen Verwendungen für Sites, die im Vergleich zum Verzeichnis conf.d für nginx verfügbar sind?


Ich habe einige Erfahrung mit Linux, aber keine mit Nginx. Ich wurde beauftragt, Load-Balancing-Optionen für einen Anwendungsserver zu untersuchen.

Ich habe apt-get verwendet, um nginx zu installieren, und alles scheint in Ordnung zu sein.

Ich habe ein paar Fragen.

Was ist der Unterschied zwischen dem Ordner sites-available und dem Ordner conf.d? Diese beiden Ordner wurden im Standardkonfigurations-Setup für nginx eingeschlossen. Tutorials verwenden beide. Wozu dienen sie und was ist die beste Praxis?

Wofür wird der für Websites aktivierte Ordner verwendet? Wie benutze ich es?

Die Standardkonfiguration referenziert einen www-Daten Benutzer? Muss ich diesen Benutzer erstellen? Wie gebe ich diesem Benutzer optimale Berechtigungen zum Ausführen von nginx?


73
2017-07-31 14:20


Ursprung


Versuchen Sie zu vermeiden, dass der Umfang bei der Frage nachgibt; www-data ist ein separates Thema. Die meisten Betriebssysteme definieren einen separaten Benutzer mit niedrigeren Berechtigungen, nach denen der Prozess ausgeführt werden kann, nachdem er als Root an Port 80 gebunden wurde. Es ist in der Konfigurationsdatei definiert. Wenden Sie grundlegende Sicherheitsmaßnahmen von dort an. Lassen Sie den Benutzer nichts schreiben, auf das der Webserver nicht schreiben soll. Lassen Sie andere Benutzer nicht in die Dateien schreiben, es sei denn, sie sind bewusst. - Andrew B


Antworten:


Die Seiten- * Ordner werden von verwaltet nginx_ensite und nginx_dissite. Für Apache httpd Benutzer, die dies mit einer Suche finden, ist das Äquivalent a2ensite/a2dissite.

Das sites-available Ordner dient zum Speichern alles Ihrer vhost-Konfigurationen, unabhängig davon, ob sie derzeit aktiviert sind oder nicht.

Das sites-enabled Der Ordner enthält symbolische Verknüpfungen zu Dateien im Ordner sites-available. Auf diese Weise können Sie vhosts selektiv deaktivieren, indem Sie den Symlink entfernen.

conf.d macht den Job, aber Sie müssen etwas aus dem Ordner verschieben, löschen oder Änderungen daran vornehmen, wenn Sie etwas deaktivieren müssen. Die Site- * Ordner-Abstraktion macht die Dinge ein wenig organisierter und erlaubt es Ihnen, sie mit separaten Support-Skripten zu verwalten.

(es sei denn, du bist wie ich, und einer von vielen Debian-Admins, die die Symlinks direkt verwaltet haben, ohne etwas über die Skripts zu wissen ...)


69
2017-07-31 15:01



Habe ich etwas falsch gemacht? Den Downvote nicht verstehen. - Andrew B
Ich bin neugierig, ist das in Nginx eingebaut? Ich habe es manuell installiert github.com/perusio/nginx_ensite - lfender6445
Es ist wichtig das zu beachten sites-available|sites-enabled ist ein Debian-ism und ist nicht etwas, was nginx oder Apache tun. Es war wahrscheinlich in der Vergangenheit ziemlich nützlich, aber seine Verwendbarkeit ist in einem Zeitalter von Konfigurationsmanagement und Containern etwas eingeschränkt. - Michael Hampton♦


Ich möchte zu den vorherigen Antworten hinzufügen, dass das Wichtigste nicht ist, wie Sie die Verzeichnisse nennen (obwohl das eine sehr nützliche Konvention ist), aber was Sie tatsächlich tun nginx.conf. Beispielkonfiguration:

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

Die einzige hier verwendete Richtlinie ist umfassenDaher gibt es keinen internen Unterschied zwischen z.B. conf.d/ und sites-enabled/.

Aus der obigen Dokumentation:

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.

Also, um die ursprüngliche Frage zu beantworten: Es gibt keinen inneren Unterschied, und Sie können sie so gut wie möglich verwenden, indem Sie sich an Ratschläge aus den anderen Antworten erinnern. Vergessen Sie bitte nicht, die richtige Antwort zu wählen.


28
2018-04-16 20:29



Recht, sites-enabled Es ist etwas erfunden worden durch etwas Zuteilung, herumfummeln als ein lästiges Zwischenprodukt tut. Geh nginx aus die offizielle Quelle: Sie werden ein aktuelles Produkt bekommen, sowie diese Konfiguration Mist / Hölle loswerden. - Bernard Rosset
Dies erklärt, warum es in der offiziellen Nginx-Dokumentation keine einzige Referenz dieser Namenskonvention gibt. Es ist ein Drittparteiprojekt! github.com/perusio/nginx_ensite - AxeEffect


Normalerweise sites-enabled Ordner wird für virtuelle Host-Definitionen verwendet, während conf.d wird für die globale Serverkonfiguration verwendet. Wenn Sie mehrere Websites - d. H. Virtuelle Hosts - unterstützen, erhält jeder eine eigene Datei, sodass Sie diese sehr einfach aktivieren und deaktivieren können, indem Sie Dateien ein- und ausblenden sites-enabled (oder Symlinks erstellen und entfernen, was wahrscheinlich eine bessere Idee ist).

Benutzen conf.d B. für das Laden von Modulen, Protokolldateien und andere Dinge, die nicht für einen einzelnen virtuellen Host spezifisch sind.

Die Standardkonfiguration referenziert einen www-Daten Benutzer? Muss ich   diesen Benutzer erstellen?

Sie sollten nginx als Benutzer ohne Rootberechtigung ausführen. Dies wird in einigen Fällen genannt www-data, aber Sie können es nennen, was Sie wollen.

Wie gebe ich diesem Benutzer optimale Berechtigungen für?   läuft nginx?

Ich bin mir weniger sicher über die Antwort auf diese Frage (ich laufe im Moment nicht Nginx), aber wenn es so etwas wie Apache ist, ist die Antwort, dass die www-data Benutzer benötigt nur Leseberechtigungen für alle statischen Dateien (und lesen + ausführen auf Verzeichnissen), die Sie bedienen, oder lesen / ausführen Berechtigungen für Dinge wie CGI-Skripte, und nirgendwo sonst Berechtigungen.


25
2017-07-31 14:59



Es ist auch wichtig, einen dedizierten Benutzer zum Ausführen des Webservers zu haben, da die Anmeldefunktion für diesen Benutzer durch Entfernen des gültigen Shell-Datensatzes deaktiviert wird. - DukeLion
> "Sie sollten Nginx als Nicht-Root-Benutzer ausführen" - können Sie mehr darüber erfahren? - lfender6445
Das Ausführen als nicht privilegierter Benutzer ist eine Möglichkeit, den Schaden einzudämmen, der durch eine Remote-Kompromittierung entstehen könnte. Wenn Sie einen Webserver als ausführen root und da es sich um eine entfernte Kompromittierung handelt, hat der Angreifer sofort vollen Zugriff auf das System. Bei der Ausführung als nicht privilegierter Benutzer wäre der administrative Zugriff nur in Kombination mit einer Art lokalem Exploit verfügbar. - larsks


Was ist los?

Sie müssen Debian oder Ubuntu verwenden, da die böse  sites-available / sites-enabled Logik wird nicht von der verwendet Upstream-Verpackung von Nginx von http://nginx.org/packages/.

In beiden Fällen werden beide mit Hilfe des Standards als Konfigurationskonvention implementiert include Richtlinie in /etc/nginx/nginx.conf.

Hier ist ein Ausschnitt von /etc/nginx/nginx.conf von einem offiziellen Upstream-Paket von nginx von nginx.org:

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

Hier ist ein Ausschnitt von /etc/nginx/nginx.conf von Debian / Ubuntu:

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

Also, aus der Sicht von NGINX, der einzige Unterschied wäre, dass Dateien von conf.d früher verarbeitet werden, und als solche, wenn Sie Konfigurationen haben, die still miteinander kollidieren, dann die von conf.d Vorrang vor denen in sites-enabled.


Best Practice ist conf.d.

Sie sollten verwenden /etc/nginx/conf.dDas ist eine Standardkonvention und sollte überall funktionieren.

Wenn Sie eine Site deaktivieren müssen, benennen Sie den Dateinamen einfach so um, dass er kein a mehr hat .conf Suffix, sehr einfach, unkompliziert und fehlerfrei:

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

Oder das Gegenteil von aktivieren eine Seite:

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


Vermeiden sites-available & sites-enabled Um jeden Preis.

Ich sehe absolut keinen Grund zu verwenden sites-available / sites-enabled:

  • Einige Leute haben erwähnt nginx_ensite und nginx_dissite Skripte - die Namen dieser Skripte sind noch schlimmer als der Rest dieses Debakels - aber diese Skripte sind auch nirgends zu finden - sie fehlen in der nginx Paket sogar in Debian (und wahrscheinlich auch in Ubuntu) und auch nicht in einem eigenen Paket vorhanden, plus, brauchst du wirklich ein ganzes nicht standardmäßiges Skript von Drittanbietern, um die Dateien einfach zu verschieben und / oder zu verlinken die zwei Verzeichnisse ?!

  • Und wenn Sie nicht die Skripte verwenden (was in der Tat eine kluge Wahl wie oben ist), dann kommt das Problem, wie Sie die Seiten verwalten:

    • Erstellst du symbolische Links von sites-available zu sites-enabled?
    • Kopieren Sie die Dateien?
    • Verschieben Sie die Dateien?
    • Bearbeiten Sie die Dateien an Ort und Stelle in sites-enabled?

Das oben Gesagte mag wie kleine Probleme erscheinen, bis mehrere Leute anfangen, das System zu verwalten, oder bis Sie eine schnelle Entscheidung treffen, nur um es Monate oder Jahre später zu vergessen ...

Das bringt uns zu:

  • Ist es sicher, eine Datei zu entfernen? sites-enabled? Ist es eine weiche Verbindung? Eine harte Verbindung? Oder die einzige Kopie der Konfiguration? Ein Paradebeispiel für Konfigurationshölle.

  • Welche Websites wurden deaktiviert? (Mit conf.dMachen Sie einfach eine Inversionssuche nach Dateien, die nicht enden .conf - find /etc/nginx/conf.d -not -name "*.conf"oder verwenden grep -v.)

Nicht nur alle oben genannten, sondern auch die spezifischen include Direktive von Debian / Ubuntu - /etc/nginx/sites-enabled/*- Es ist kein Dateinamensuffix angegeben sites-enabled, anders als für conf.d.

  • Das bedeutet, dass Sie eines Tages entscheiden, eine oder zwei Dateien schnell zu bearbeiten /etc/nginx/sites-enabled, und dein emacs erstellt eine Sicherungsdatei wie default~Dann hast du plötzlich beides default und default~ Als aktive Konfiguration enthalten, die, abhängig von den verwendeten Anweisungen, möglicherweise nicht einmal Warnungen ausgeben und eine längere Debugsitzung verursachen. (Ja, es ist mir passiert; es war während eines Hackathons, und ich war total verwirrt darüber, warum mein Conf nicht funktionierte.)

So bin ich davon überzeugt sites-enabled ist das reine Böse!


6
2017-08-27 20:08



Zusätzlich zu all dem oben genannten, ist es auch sehr üblich, falsche Symlinks zu erstellen! stackoverflow.com/a/14107803/1122270  Nur für den Fall, dass Sie nicht gedacht haben sites-enabled war böse genug! - cnst
Manchmal kann es auch passieren, dass jemand beschließt, die Dateien zu bearbeiten sites-enabled, doch dann entscheidet eine andere Person, sie zu deaktivieren, indem sie es löscht, möglicherweise denkend, dass es nur ein symbolischer Link war, was einen nachfolgenden Speicherabzug von nginx-Heap erfordert, um die conf-Datei wiederherzustellen: stackoverflow.com/q/45852224/1122270 - cnst
Ich muss den Behauptungen widersprechen sites-available und sites-enabled; es ist wichtig, Config in der Lage sein, Dateien außerhalb des ‚Live‘ Pickup-Verzeichnis, so dass, wenn nginx wurden neu geladen oder neu gestartet aufzubereiten, dass es nicht Teil-Konfigurationsdateien abholen würde. Es kann auch nützlich sein, Konfigurationsdateien zu behalten, die nicht mehr aktiv verwendet werden. Das Erstellen von Symlinks ist keine besonders schwierige Aufgabe, wenn Sie genug Erfahrung haben, um nginx von Anfang an zu managen, IMO. - BE77Y
@ BE77Y Du nimmst einen komplizierteren Ansatz. Bei der Programmierung gilt es als bewährte Methode, nicht verwendeten Code vollständig zu entfernen, nicht nur zu deaktivieren oder zu kommentieren; Ich sehe keinen Grund, warum DevOps anders sein sollte - wenn eine Konfiguration nicht mehr benötigt wird, entferne sie (sie sollte noch in deinem VCS existieren). Das Gleiche gilt für partielle conf-Dateien - warum würdest du sie bearbeiten und nginx hinter deinem Rücken nachladen lassen? (USR1, Die wieder öffnet logs, reload nicht conf) ich Ihre Symlink „Erfahrung“ Kommentare misdirected finden -. Die Frage eine Frage der Konsequenz ist, die wenig mit Erfahrung zu tun hat. - cnst
Es ist klar, dass a) dies nicht das geeignete Medium für diese Diskussion und vielleicht noch wichtiger ist, b) es wahrscheinlich sowieso fruchtlos sein wird. Lassen Sie uns zustimmen, nicht zuzustimmen. - BE77Y