☰

Bester Pfad für Nginx-Dateien

tag-icon • tag-icon nginx ssh permissions shell-scripting path
Bester Pfad für Nginx-Dateien

Ich habe immer mit verschiedenen Dateien gekämpft pathsund nginxwo sie positioniert werden sollten. Wie wir wissen, können wir ändern, wo wir sowohl diewwwVerzeichnisse für unsere web appsowie die zugehörigen logDateien.

Das Problem, das ich festgestellt habe, besteht darin, dass ich sowohl Benutzerskripte für Anrufe als auch bashSkripte habe , die Zugriff auf verschiedene Teile dieser Dateien benötigen, sowie geplante Netzwerkkopien verschiedener Dateien, ganz zu schweigen von Aktualisierungen dieser Dateien.RubySSHcrontabnginx

Ich habe mich an die statischen Pfade gehalten, die von der Paketinstallation nginxin verschiedenen Distributionen empfohlen werden, bin jedoch häufig auf permissionsProbleme gestoßen, da pathdie Zugänglichkeit nicht optimal war. Ich habe also die verschiedenen Hauptpfade untersucht linuxund etwas ausgewählt, das unter Berücksichtigung all dieser Punkte entwickelt wurde und gleichzeitig ein gutes Maß an Sicherheit bietet. Ich habe verschiedene Standorte gesehen und da ich jetzt wieder damit beschäftigt bin ( crontabsfunktioniert nicht, permissionsProbleme mit verschiedenen Elementen usw.), dachte ich, ich frage mal, wo das alles liegen sollte.

Meine Apps sind keine Standard static-HTML-Anwendungen. Ich habe eine RackAnwendung mit einem app serverlaufenden, einem Gemfilesowie allen eingehenden Uploads usw.

Die beiden Standorte, die ich bewerte, sind:

Das hier habe ich jedoch zum /usrVerzeichnis gelesen:

/usr ist der zweite Hauptabschnitt des Dateisystems. /usr enthält gemeinsam nutzbare, schreibgeschützte Daten. Das bedeutet, dass /usr zwischen verschiedenen FHS-kompatiblen Hosts gemeinsam genutzt werden kann und nicht beschrieben werden darf. Alle Informationen, die hostspezifisch sind oder sich mit der Zeit ändern, werden woanders gespeichert.

Große Softwarepakete dürfen kein direktes Unterverzeichnis unter der /usr-Hierarchie verwenden.

Ich bin also verloren. Kann mir jemand einen Speicherort für lesbare/beschreibbare Dateien empfehlen, der mir beim Skripten und Schreiben möglichst wenig Aufwand bereitet cron?

Antwort1

Der „auf jeden Fall“ richtige Ort zum Hosten von Website-Dateien ist /srv/www. Von dort aus „partitioniere“ ich diese normalerweise in domänenbezogene Verzeichnisse.

Alles in allem /srv/www/example.comgibt es also diese Struktur/Unterverzeichnisse:

  • publicspeichert alle öffentlich zugänglichen Dateien, die an diese Domäne/Website gebunden sind
  • logsspeichert alle an diese Domain gebundenen Logdateien (sei es NGINX, PHP-FPM usw.)
  • sessionsspeichert benutzerspezifische Sitzungen, z. B. PHP-Sitzungen

Egal, ob Sie PHP-FPM oder einen anderen „Skript-Daemon“ verwenden, Sie möchten die Berechtigungen richtig einstellen, indem Sie Ihre Daemon-Einstellungen anpassen und die Dateien richtig chmod/chownen. Es gibt keinen magischen Ort, der Sie davor bewahrt,Berechtigungsmodell konfigurieren. SehenNGINX und PHP-FPM. Welche Berechtigungen sollten ich haben?- dies trifft sehr gut auf die meisten Website-Setups zu, unabhängig von PHP-FPM:

  • Fügen Sie für jede Website einen eigenen Benutzer hinzu, um eine ordnungsgemäße Isolierung zu gewährleisten, z. B.example
  • Konfigurieren Sie Ihren Skript-Daemon so, dass er als dieser Benutzer ausgeführt wird
  • Lassen Sie Ihren Webserver-Benutzer (NGINX) das Gruppenmitglied Ihres Site-Benutzers sein: usermod -a -G example nginx. Dadurch kann NGINX Dateien lesen, für die die Gruppenberechtigung auf Lesen eingestellt ist, und Sie können Dateien, die Sie nicht lesen möchten (Konfigurationsdateien), schützen, indem Sie einfach das Gruppenberechtigungsbit auschmod

Letztendlich gibt es nie ein Problem mit den Berechtigungen: Alles gehört demselben Benutzer und wird von ihm „ausgeführt“!

Antwort2

Ich stimme dafür, dies zu schließen, da die Frage sehr vage ist. Außerdem versuchen Sie, Ihren Tools die Schuld für die Situation zu geben, obwohl sie nicht die Ursache des Problems sind. Sie sind in gewissem Maße durch das MAC-Subsystem in dem eingeschränkt, was Sie tun können/sollten, und auch durch die Art und Weise, wie das Paketverwaltungssystem mit Konfigurationsdateien umgeht. Da Sie uns jedoch nicht gesagt haben, um welche Distribution es sich handelt, wissen wir nicht, ob das relevant ist, geschweige denn, dass wir Vorschläge machen können.

Zu Beginn sollten Sie bei der Lösung dieses Problems umfassende Listen darüber erstellen, welche Benutzerkonten auf welche Dateien zugreifen müssen (bevor Sie sich überlegen, wo sich diese Dateien befinden), und ein entsprechendes Berechtigungsmodell ausarbeiten.

Es ist sicherlich HÖCHST unwahrscheinlich, dass es sinnvoll wäre, Skripte oder Inhalte unter /usr zu speichern.

verwandte Informationen