Dlaczego katalog główny na serwerze WWW jest domyślnie umieszczony w „/ var / www”?

Tuxfiles mówi o strukturze katalogów systemu Linux:

/var:

Ten katalog zawiera zmienne dane, które stale się zmieniają podczas działania systemu.

FHS on/var mówi, co następuje:

/varzawiera zmienne pliki danych. Obejmuje to katalogi i pliki buforowania, dane administracyjne i rejestrujące oraz pliki przejściowe i tymczasowe.

Następnie mówią, że takie rzeczy, jak dzienniki, poczta i bufor są umieszczone w tym folderze.

Tradycyjnie standardowa instalacja Apache lub Nginx na Ubuntu Linux umieści katalog na /var/www/.

Nie wydaje mi się idealnym miejscem do umieszczenia katalogu z plikami lub innymi treściami, które powinny być prawie trwałe.

Dlaczego jest tak często wprowadzany /var?

Mówiąc bardziej subiektywnie, czy jest to miejsce, do którego powinno idealnie iść, zgodnie ze strukturą katalogów?

To wcale nie jest „tradycyjna” lokalizacja. Tradycyjnie wszystko, co zainstalowałeś po wejściu systemu operacyjnego /usr/local, i tak naprawdę jest to „klasyczny układ ścieżki Apache” (ich słowa) do dziś. Tak było przez długi czas /home/httpd.

To, co widzisz, to to, że Apache skonfigurowany dla konkretnego systemu operacyjnego - niezależnie od tego, czy jest to Red Hat Linux, Mac OS X, GNU itp. - dostosuje lokalizację. Źródło Apache jest do tego dobrze zaprojektowane, w rzeczywistości, jeśli prześledzisz wartość ServerRoot w plikach źródłowych, zobaczysz, że zaczyna się ona w tym pliku config.layout:

Niektóre fragmenty tego pliku pokażą, że istnieje duża różnorodność w lokalizacji docroot.

IIRC, /var/wwwpojawiło się w moim życiu wraz z wydaniami Red Hat Linux 7.x 2000-2001 (nie Red Hat Enterprise Linux). Ze wszystkich powodów, które przytaczasz powyżej, myślałem, że to nie ma większego sensu - ale w rzeczywistości w epoce nowożytnej tak wiele innych narzędzi i technologii jest zaangażowanych, a lokalizacja się zmienia.

#   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

Używanie /var/wwwjest mylące tylko na pierwszy rzut oka.

Według FHS dane serwera sieciowego powinny trafić do /srv. To jest główna zasada.

Jednak mówi również, że decyzja o strukturze /srvjest wyłączną odpowiedzialnością lokalnego administratora! Dlatego pakiety nie mogą niczego umieszczać /srv, a domyślny katalog główny nie może /srv, ponieważ pakiet (apache) nie wie, co jest w nim /srvi pod nim. Może repozytorium subversion z wyraźnym hasłem tekstowym i innymi rzeczami. Więc musi istnieć domyślna wartość poza /srv. To domyślne staje się /var/www.

/var/wwwjest głównie symbolem zastępczym. Pakiety używają /usr/sharedo statycznej treści HTML lub /var/libdo dynamicznej zawartości zmiennej. Wiele osób błędnie myślało, że powinni umieścić HTML /var/www. To jest problem, ponieważ paczki również czasami tego używają. Ostatnio wymyślili /var/www/htmldla pakietów. Mam nadzieję, że ludzie nie zaczną z tego korzystać, ponieważ znowu muszą wymyślić nowy katalog ... i tak dalej.

Podsumowanie: należy odpowiednio używać /srvi konfigurować wirtualnych hostów Apache.

Chociaż zgadzam się z odpowiedzią Akonda, myślę, że jest w tym ważniejszy aspekt. Większość innych lokalizacji (takich jak /usr/local) jest zazwyczaj zarządzana przez system (menedżer pakietów). /varjest zwykle tam, gdzie idą pliki, które nie są zarządzane przez menedżera pakietów (ogólnosystemowe „dane”).

Myślę też, że definicja z FHS jest nieco dokładniejsza (dane nie muszą być „ciągle zmieniane”):

/ var zawiera zmienne pliki danych. Obejmuje to katalogi i pliki buforowania, dane administracyjne i rejestrujące oraz pliki przejściowe i tymczasowe.

Jednak FHS określa również gatunki, w które powinny wchodzić dane www/srv

/ srv zawiera dane właściwe dla witryny, które są obsługiwane przez ten system.

Głównym celem określenia tego jest, aby użytkownicy mogli znaleźć lokalizację plików danych dla konkretnej usługi, a także aby usługi wymagające pojedynczego drzewa dla danych tylko do odczytu, danych zapisywalnych i skryptów (takich jak skrypty cgi) mogły być rozsądnie umieszczone.

Metodologia stosowana do nazewnictwa podkatalogów / srv jest nieokreślona, ​​ponieważ obecnie nie ma zgody co do tego, jak należy to zrobić. Jedną z metod strukturyzacji danych w / srv jest protokół, np. ftp, rsync, www i cvs.

Powody są głównie historyczne, jak powiedzieli inni. /varbył używany do danych systemowych, które cały czas się zmieniają, na przykład pliki pamięci podręcznej, dzienniki, dane środowiska wykonawczego (na przykład pliki blokowania), pamięć serwera poczty, buforowanie drukarki itp. Zasadniczo do wszystkich rzeczy, których nie można umieścić /usr( ponieważ zawiera dane lokalne), nie są programami innych firm, które się do nich wprowadzają /opt, a także nie są usuwalne i niestabilne /tmp.

W miarę rozwoju systemu Unix / Linux stało się to nieporządne miejsce z mnóstwem różnych niepowiązanych katalogów. W ostatnich latach pojawiła się tendencja do przenoszenia niektórych rzeczy, w szczególności treści obsługiwanych przez maszynę (które zgodnie z [ Fileystem Hierarchy Standard 2.3, str. 15 ] powinny wchodzić /srv, a nie wchodzić /var/www).

Podobnie rzecz się do /var/runkilku lat wstecz - ze skoncentrowanego wysiłku kilku dystrybucjach, został przeniesiony z /var/runpod /runktórego zrośnięte funkcje wcześniej używany /var/lock, /var/runi /dev/shm.

Z mojego doświadczenia (jestem programistą) zawartość witryny jest daleka od stabilności. Nawet w przypadku plików HTML (bez względu na dynamicznie generowaną treść) podlegają one ciągłym zmianom (poprawki, pominięcia itp.).

Z mojego punktu widzenia są to zmienne. Dlatego idealnie pasują do katalogu / var i nie ma w tym nic złego.

IIRC w dawnych czasach zawsze montowaliśmy /varjako własny system plików (oddzielny dysk lub jego fragment).

Jednym z powodów tego, jak stwierdzili inni, jest duży odczyt / zapis w tym systemie plików (logs / et al). Mając na osobnym dysku / kawałek oznacza, że może być lepiej dostosowana do tego typu I / O (w porównaniu z najczęściej czytać /, /usritp ...).

Innym powodem jest to, że w tamtych czasach, jeśli system ulegał awarii podczas operacji zapisu, istniała bardzo duża szansa, że ​​główny system plików może zostać uszkodzony, pozostawiając go w trudnym do naprawy stanie. Zatem potrzeba oddzielenia od /.

Technologia plików i dysków uległa znacznej poprawie w czasie, więc jest to znacznie mniej prawdopodobne zjawisko.

/var jest przyzwoitym wyborem dla neutralnej dla użytkownika „podstawowej” lokalizacji dla dostępu dla wielu użytkowników, w przypadku gdy masz witrynę z wieloma wirtualnymi hostami, która umożliwia FTP lub inne przesyłanie, tj. jeśli jesteś hostem internetowym lub podobnym.

/homeJest to prawdopodobnie nie jest optymalny, ponieważ złe rzeczy mogą się zdarzyć na inne konto shell użytkownik Jeżeli bezmyślne lub złośliwe przesłane przez użytkownika do /homegranicy rozdzielającej (zakładając tradycyjną konfigurację /var, /homeitd będąc na oddzielnych partycjach) może wpływać na inne konta użytkowników.

Oczywiście myślę, że /srvjest to lepsze, ale /varjest już dłużej w tradycji UNIX.

Chciałbym tutaj dodać, że umieszczenie internetowego „roota” w / usr powoduje konflikt z tą częścią FHS, która wskazuje, że / usr może być udostępniany tylko do odczytu, ponieważ różne serwery sieciowe, nawet w tym samym „klastrze” może mieć różne pliki zawierające różne konfiguracje, co nie czyni go idealnym dla / usr.

Ponadto niektóre aplikacje internetowe (MediaWiki i PhpBB, aby wymienić te z góry mojej głowy) oczekują możliwej do zapisu lokalizacji pod drzewem katalogów WWW do przesyłania załączników / plików multimedialnych. Tak więc umieszczenie drzewa w katalogu / usr byłoby sprzeczne, jeśli chcesz zastosować definicję / usr tylko do odczytu.

Serwer WWW Apache ma domyślną stronę pod / var / www /, ale sugeruje się umieszczenie innych stron pod / srv /

Zauważyłem to na Ubuntu Server 14.04 LTS. Domyślny plik apache2.conf zawiera skomentowany blok:

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