Warum befindet sich das Stammverzeichnis eines Webservers standardmäßig in „/ var / www“?

Tuxfiles sagt Folgendes über die Linux-Verzeichnisstruktur:

/var:

Dieses Verzeichnis enthält variable Daten, die sich bei laufendem System ständig ändern.

FHS on/var sagt Folgendes:

/varenthält variable Datendateien. Dies umfasst Spool-Verzeichnisse und -Dateien, Verwaltungs- und Protokollierungsdaten sowie vorübergehende und temporäre Dateien.

Dann sagen sie, dass Dinge wie Protokolle, E-Mails und der Spooler in diesem Ordner abgelegt werden.

Traditionell findet eine Stamm Installation von Apache oder Nginx auf Ubuntu Linux das Verzeichnis an /var/www/.

Es scheint mir nicht der ideale Ort zu sein, um ein Verzeichnis mit Dateien oder anderen Inhalten zu erstellen, die beinahe permanent sein sollen.

Warum wird es so oft hineingesteckt /var?

Ist dies subjektiv gesehen der Ort, an dem es nach der Verzeichnisstruktur im Idealfall gehen sollte?

Es ist eigentlich gar nicht der "traditionelle" Ort. Traditionell ist alles, was Sie nach dem Betriebssystem installiert haben /usr/local, das "klassische Apache-Pfadlayout" (ihre Worte) bis heute. Lange Zeit war es das /home/httpd.

Was Sie sehen, ist, dass ein Apache, der für ein bestimmtes Betriebssystem konfiguriert wurde - egal, ob es sich um Red Hat Linux, Mac OS X, GNU usw. handelt - den Speicherort anpasst. Apaches Quelle ist dafür gut geeignet. Wenn Sie den Wert für ServerRoot in den Quelldateien verfolgen, werden Sie feststellen, dass er in dieser Datei beginnt config.layout:

Einige Auszüge aus dieser Datei werden Ihnen zeigen, dass der Speicherort der Doku sehr abwechslungsreich ist.

IIRC ist /var/wwwmit den Releases 2000-2001 von Red Hat Linux 7.x (nicht Red Hat Enterprise Linux) in mein Leben getreten . Aus all den Gründen, die Sie oben zitiert haben, fand ich es nicht sehr sinnvoll - aber die Realität ist, dass in der Neuzeit so viele andere Tools und Technologien involviert sind, dass sich der Standort trotzdem bewegt.

#   Classical Apache path layout.
<Layout Apache>
    prefix:        /usr/local/apache2
    datadir:       ${prefix}

#   GNU standards conforming path layout.
#   See FSF's GNU project `make-stds' document for details.
<Layout GNU>
    exec_prefix:   ${prefix}
    datadir:       ${prefix}/share+

#   Mac OS X Server (Rhapsody)
<Layout Mac OS X Server>
    prefix:        /Local/Library/WebServer
    datadir:       ${prefix}

#   Darwin/Mac OS Layout
<Layout Darwin>
    prefix:        /usr
    datadir:       /Library/WebServer

#   Red Hat Linux 7.x layout
<Layout RedHat>
    prefix:        /usr
    datadir:       /var/www

#   SuSE 6.x layout
<Layout SuSE>
    prefix:        /usr
    datadir:       /usr/local/httpd

#   BSD/OS layout
<Layout BSDI>
    prefix:        /var/www
    datadir:       ${prefix}

#   Solaris 8 Layout
<Layout Solaris>
    prefix:        /usr/apache
    datadir:       /var/apache

Die Verwendung von /var/wwwist nur auf den ersten Blick verwirrend.

Laut FHS sollten Webserver-Daten an gehen /srv. Das ist die Hauptregel.

Es heißt jedoch auch, dass die Entscheidung über die Struktur von /srvin der alleinigen Verantwortung des lokalen Administrators liegt! Daher dürfen Pakete nichts einfügen /srv, und der Standard- Dokumentenstamm darf es nicht sein /srv, da das (Apache-) Paket nicht weiß, was sich darin /srvund darunter befindet. Vielleicht ein Subversion-Repository mit Klartext-Passwort und anderen Dingen. Es muss also einen Standard außerhalb von geben /srv. Das ist Standard geworden /var/www.

/var/wwwist meist ein Platzhalter. Pakete werden /usr/sharefür statischen HTML-Inhalt oder /var/libfür dynamischen variablen Inhalt verwendet. Viele Leute dachten fälschlicherweise, dass sie HTML in dieses Format einfügen sollten /var/www. Das ist ein Problem, weil Pakete das gelegentlich auch verwenden. So erfanden sie vor kurzem /var/www/htmlfür Pakete. Hoffentlich werden die Leute nicht damit anfangen, weil sie dann wieder ein neues Verzeichnis erfinden müssen ... und so weiter.

Zusammenfassung: Sie sollten /srvIhre virtuellen Apache-Hosts entsprechend verwenden und konfigurieren.

Ich bin mit der Antwort von akond einverstanden, denke aber, dass es einen wichtigeren Aspekt gibt. Die meisten anderen Speicherorte (z. B. /usr/local) werden normalerweise vom System (dem Paketmanager) verwaltet. /varIn der Regel werden dort Dateien abgelegt, die nicht vom Paketmanager verwaltet werden (systemweite 'Daten').

Ich denke auch, dass die Definition aus dem FHS etwas genauer ist (die Daten müssen sich nicht "ständig ändern"):

/ var enthält variable Datendateien. Dies umfasst Spool-Verzeichnisse und -Dateien, Verwaltungs- und Protokollierungsdaten sowie vorübergehende und temporäre Dateien.

Allerdings sollte die FHS auch Arten, auf die www-Daten eingehen sollen/srv

/ srv enthält standortspezifische Daten, die von diesem System bereitgestellt werden.

Der Hauptzweck dieser Angabe besteht darin, dass Benutzer den Speicherort der Datendateien für einen bestimmten Dienst finden und dass Dienste, die einen einzigen Baum für schreibgeschützte Daten, beschreibbare Daten und Skripte (z. B. CGI-Skripte) benötigen, sinnvoll platziert werden können.

Die Methode zur Benennung der Unterverzeichnisse von / srv ist nicht festgelegt, da derzeit kein Konsens darüber besteht, wie dies erfolgen soll. Eine Methode zur Strukturierung von Daten unter / srv ist das Protokoll, z. ftp, rsync, www und cvs.

Die Gründe sind meist historisch, wie andere sagten. /varwurde für Systemdaten verwendet, die sich ständig ändern, z. B. Cache-Dateien, Protokolle, Laufzeitdaten (z. B. Sperrdateien), Mail-Server-Speicher, Druckerspooling usw. Grundsätzlich für alle Dinge, die nicht eingegeben werden können /usr( Da es lokale Daten enthält, handelt es sich nicht um Programme von Drittanbietern, die eingehen /opt, und es ist nicht verwerfbar und flüchtig, wenn diese eingehen /tmp.

Mit der Entwicklung von Unix / Linux wurde es zu einem chaotischen Ort, an dem eine Vielzahl verschiedener unterschiedlicher Verzeichnisse zusammengestellt wurde. In den letzten Jahren gab es eine Tendenz, einige Dinge aus dem System zu entfernen, insbesondere Inhalte, die von der Maschine bereitgestellt werden (die nun gemäß [ Dateisystem-Hierarchie-Standard 2.3, S.15 ] eingehen sollten /srv, nicht eingehen/var/www ).

Ähnliches , was zu geschehen vor /var/runein paar Jahren - mit der konzentrierten Anstrengung von mehreren Verteilungen, wurde aus bewegt , /var/runin /runder die Funktionen der zuvor verwendeten miteinander verschmolzen /var/lock, /var/runund /dev/shm.

Nach meiner Erfahrung (ich bin ein Webentwickler) ist der Inhalt der Website alles andere als stabil. Auch bei HTML-Dateien (egal, welcher Inhalt dynamisch generiert wird) unterliegen sie ständigen Änderungen (Ergänzungen, Auslassungen usw.).

Aus meiner Sicht sind sie also Variablen. Sie passen also perfekt in das Verzeichnis / var und daran ist nichts auszusetzen.

IIRC, in den alten Tagen, wir montierten immer /varals sein eigenes Dateisystem (separate Festplatte oder Scheibe einer Scheibe) ist.

Einer der Gründe dafür ist, wie andere angegeben haben, dass das Dateisystem (logs / et al.) Viel gelesen / geschrieben wird. Eine separate Scheibe / Scheibe zu haben bedeutet , kann es besser für diese Art von I / O (lesen Sie weiter im Vergleich meist abgestimmt werden /, /usrusw ...).

Der andere Grund ist, dass in jenen Tagen, wenn Ihr System während eines Schreibvorgangs abstürzte, die Wahrscheinlichkeit sehr hoch war, dass Ihr Root-Dateisystem beschädigt wurde und es sich in einem schwer zu reparierenden Zustand befand. Somit ist die Notwendigkeit der Trennung von /.

Die Dateisystem- und Festplattentechnologie hat sich im Laufe der Zeit erheblich verbessert, so dass dies weit weniger wahrscheinlich ist.

/var ist eine gute Wahl für einen benutzerneutralen "Basis" -Standort für den Mehrbenutzerzugriff, falls Sie eine Website mit mehreren virtuellen Hosts haben, auf der FTP oder andere Uploads möglich sind, z. B. wenn Sie ein Webhost oder ähnliches sind.

/homemöglicherweise nicht optimal ist , weil schlechte Dinge für andere Benutzer - Shell - Konten passieren könnten , wenn ein gedankenlos oder böswillige Benutzer Uploads in die /homePartitionsgrenze (traditionelle Einrichtung unter der Annahme /var, /homeusw. auf separate Partitionen sind) es andere Benutzerkonten beeinflussen kann.

Natürlich denke ich, dass dies /srvbesser ist, aber es gibt es /varschon länger in der UNIX-Tradition.

Was ich hier hinzufügen möchte, ist, dass das Setzen des Web "root" in / usr Konflikte mit dem Teil des FHS verursacht, der angibt, dass / usr gemeinsam genutzt werden kann und nur gelesen werden kann, da sich verschiedene Webserver sogar auf demselben "Cluster" befinden. Es kann unterschiedliche Dateien mit unterschiedlichen Konfigurationen geben, was es nicht ideal für / usr macht.

Darüber hinaus erwarten einige Webanwendungen (MediaWiki und PhpBB, um nur einige zu nennen) einen beschreibbaren Speicherort unter dem Webverzeichnisbaum für das Hochladen von Anhängen / Mediendateien. Wenn Sie den Webbaum unter / usr platzieren, kann dies zu Konflikten führen, wenn Sie die schreibgeschützte / usr-Definition einhalten möchten.

Auf Apache-Webservern befindet sich die Standardwebsite unter / var / www /. Es wird jedoch empfohlen , andere Websites unter / srv / zu platzieren.

Ich habe dies auf Ubuntu Server 14.04 LTS bemerkt. Die Standarddatei apache2.conf enthält einen kommentierten Block:

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted
#</Directory>