Perché la directory principale su un server Web è impostata di default in "/ var / www"?


87

Tuxfiles dice quanto segue sulla struttura delle directory di Linux:

/var:

Questa directory contiene dati variabili che cambiano costantemente quando il sistema è in esecuzione.

FHS on/var dice quanto segue:

/varcontiene file di dati variabili. Ciò include directory e file di spooling, dati amministrativi e di registrazione e file temporanei e temporanei.

Quindi proseguono dicendo che cose come i registri, la posta e lo spooler vengono inseriti in quella cartella.

Tradizionalmente Un'installazione stock di Apache o Nginx su Ubuntu Linux posizionerà la directory in /var/www/.

Non mi sembra il posto ideale per mettere una directory con file o contenuti che dovrebbero essere quasi permanenti.

Perché è così spesso messo in /var?

Più soggettivamente, è qui che dovrebbe idealmente andare, secondo la struttura delle directory?


2
Questa è una buona domanda che mi sono posto spesso e mi sono accordato in qualche modo :).
lupo,

1
Secondo FHS /var/lib/wwwsarebbe stato più adatto ...
Nils

3
l'attuale FHS dice che la radice del web server dovrebbe essere da qualche parte in basso/srv
LogicDaemon

1
/varè per i dati non eseguibili non configurabili, non di proprietà di un utente reale che possono essere modificati o modificati (ad esempio, dovrebbero vivere su un volume riscrivibile). /var/libè specificamente per quel tipo di dati che dovrebbero sopravvivere un riavvio e non essere cancellato da un processo di manutenzione, isc-dhcp-serverutilizza /var/libper memorizzare il suo record di lease DHCP per esempio. Quindi sarebbe un punto logico per i file del server web.
LawrenceC,

@Nils, Perché lib?
Pacerier,

Risposte:


35

In realtà non è affatto la posizione "tradizionale". Tradizionalmente, qualsiasi cosa tu abbia installato dopo che il sistema operativo è entrato /usr/local, e in effetti questo è il "layout classico del percorso Apache" (le loro parole) fino ai giorni nostri. Per molto tempo lo è stato /home/httpd.

Quello che stai vedendo è che un Apache che è stato configurato per un particolare sistema operativo, che sia Red Hat Linux, Mac OS X, GNU, ecc., Personalizzerà la posizione. I sorgenti di Apache sono ben progettati per questo, infatti se traccia il valore per ServerRoot nei file sorgente, vedrai che inizia in questo file config.layout:

Alcuni estratti di quel file ti mostreranno che c'è molta varietà nella posizione di docroot.

IIRC, è /var/wwwentrato nella mia vita con le versioni 2000-2001 di Red Hat Linux 7.x (non Red Hat Enterprise Linux). Per tutte le ragioni che citi sopra, ho pensato che non avesse molto senso - ma la realtà è che nell'era moderna sono coinvolti così tanti altri strumenti e tecnologie che la posizione si sposta comunque.

#   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

33

L'uso di /var/wwwè confuso solo a prima vista.

Secondo l'FHS, i dati del web server dovrebbero andare a /srv. Questa è la regola principale.

Tuttavia, afferma anche che la decisione sulla struttura /srvè di esclusiva responsabilità dell'amministratore locale! Pertanto i pacchetti non devono inserire nulla /srve la radice del documento predefinita non deve esserlo /srv, poiché il pacchetto (apache) non sa cosa c'è dentro /srve sotto di esso. Forse un repository sovversivo con password in chiaro e altre cose. Quindi ci deve essere un valore predefinito al di fuori di /srv. Quel default diventa /var/www.

/var/wwwè principalmente un segnaposto. I pacchetti utilizzano /usr/shareper contenuto HTML statico o /var/libper contenuto variabile dinamico. Molte persone hanno erroneamente pensato che avrebbero dovuto inserire l'HTML /var/www. Questo è un problema, perché occasionalmente anche i pacchetti lo usano. Di recente hanno inventato /var/www/htmlper i pacchetti. Spero che le persone non inizieranno a usarlo perché, di nuovo, devono inventare una nuova directory ... e così via.

Riepilogo: è necessario utilizzare /srve configurare gli host virtuali Apache di conseguenza.


5
Questa risposta è davvero preziosa. "Spero che le persone non inizieranno a usarlo perché, di nuovo, devono inventare una nuova directory ... e così via." Mostra che molti amministratori dovrebbero prendere tempo e leggere alcune nozioni di base. (Come sto facendo adesso;))
Toastgeraet,

Questo è già successo nelle versioni di Ubuntu. la radice del documento apache per impostazione predefinita è / var / www / html ho letto da qualche parte che il motivo della modifica era che era più sicuro. non posso contestarlo perché non lo so. Posso dirti che in realtà non userò quel percorso. e continuerò con l'installazione che uso da un po 'di tempo. Montare un disco appositamente per host virtuali in / siti Web. Mantengo una struttura simile all'hosting cpanel e servo da / website / vhostname / public_html. In questo modo posso usare il vhost per contenere la posta o qualunque altra cosa per il vhost specifico.
Chris,

In realtà sto considerando di partizionare un disco e montare le partizioni nella directory del vhost per il backup del singolo vhost. che mi darebbe / siti web / vhost / backup in ogni vhost (ne eseguo alcuni e probabilmente funzionerò di più in un secondo momento)
Chris

24

Mentre sono d'accordo con la risposta di Akond, penso che ci sia un aspetto più importante. La maggior parte delle altre posizioni (come /usr/local) sono in genere gestite dal sistema (il gestore pacchetti). /vardi solito è dove vanno i file che non sono gestiti dal gestore dei pacchetti ("dati" di sistema).

Penso anche che la definizione dall'FHS sia un po 'più accurata (i dati non devono essere "in costante cambiamento"):

/ var contiene file di dati variabili. Ciò include directory e file di spooling, dati amministrativi e di registrazione e file temporanei e temporanei.


Tuttavia, l' FHS specifica anche le specie in cui dovrebbero essere inseriti i dati www/srv

/ srv contiene dati specifici del sito forniti da questo sistema.

Questo scopo principale di specificare ciò è che gli utenti possano trovare la posizione dei file di dati per un particolare servizio e che i servizi che richiedono un singolo albero per dati di sola lettura, dati scrivibili e script (come gli script cgi) possano essere ragionevolmente posizionati.

La metodologia usata per nominare le sottodirectory di / srv non è specificata poiché al momento non vi è consenso su come farlo. Un metodo per strutturare i dati in / srv è tramite protocollo, ad es. ftp, rsync, www e cvs.


7
Errr, il punto /usr/localè che non è gestito dal gestore pacchetti.
derobert,

@derobert / usr / local viene usato molto dai pacchetti di terze parti (pacchetti non forniti dal repository della distro). È anche comune per le aziende che costruiscono i propri pacchetti inserirli (anche se ciò rientra ancora nei pacchetti non forniti dalla distribuzione). Questo è supportato anche da FHS, vedere la nota # 27 in fondo a pathname.com/fhs/pub/fhs-2.3.html
Patrick

3
/srv/wwwera il percorso classico sui sistemi SuSE (fino a SLES10).
Nils,

1
@nils aspetta, erano conformi a FHS e poi l'hanno lasciato deliberatamente ??? sospiro
Patrick,

1
@Patrick così è - Sono rimasto piuttosto stupito quando me ne sono reso conto. Probabilmente volevano essere più simili alle altre varianti di Linux ...
Nils,

13

Le ragioni sono per lo più storiche, come dicevano altri. /varè stato utilizzato per i dati di sistema che cambiano continuamente, ad esempio file di cache, registri, dati di runtime (file di blocco, ad esempio), archiviazione del server di posta, spooling della stampante, ecc. Fondamentalmente per tutto ciò che non può essere inserito /usr( perché contiene dati locali), non sono programmi di terze parti che entrano /opte non sono scartabili e volatili man mano che entrano /tmp.

Man mano che Unix / Linux si sviluppava, divenne un luogo disordinato con un miscuglio di varie directory diverse messe insieme. Negli ultimi anni c'è stata una tendenza a spostare alcune cose fuori da lì, in particolare i contenuti forniti dalla macchina (che ora secondo [ Filesystem Hierarchy Standard 2.3, p.15 ] dovrebbe entrare /srv, non in /var/www).

Cosa simile è successo a /var/runqualche anno fa - con lo sforzo concentrato di diverse distribuzioni, è stato spostato da /var/runin /runche fuse insieme le funzioni del usato in precedenza /var/lock, /var/rune /dev/shm.


6

Dalla mia esperienza (sono uno sviluppatore web) il contenuto del sito web è tutt'altro che stabile. Anche nel caso di file HTML (non importa mai contenuti generati dinamicamente) sono soggetti a costanti cambiamenti (modifiche, omissioni, ecc.).

Quindi dal mio punto di vista, sono variabili. Pertanto, sono perfettamente adatti nella directory / var e non c'è nulla di sbagliato in questo.


6
Non sarei d'accordo. Non vedo ancora i file HTML come "in continua evoluzione". Le modifiche apportate sono deliberate e verrebbero idealmente controllate in un controllo di revisione per il rilevamento delle modifiche.
jonallard,

2
Anche le modifiche al database Mysql sono intenzionali, ma i file del database si trovano in / var / db. Non ti dà fastidio?
akond

5
Certo che lo so, ma direi che sul continuum da variabile a costante, il DB sarebbe più variabile dell'applicazione HTML / qualunque / web, poiché ci sono meno versioni delle pagine web di quante ce ne siano del database. Le pagine che hanno relativamente poche versioni diverse, non vorrei inserirle /var. Ma penso che sia una questione di opinioni e dibattiti piuttosto che fatti concreti.
jonallard,

1
Cosa diresti se ti mostrassi un database che non è stato modificato per due anni?
akond

2
Con gli argomenti forniti qui, le home directory appartengono a / var. Del resto, lo stesso fa / usr perché viene costantemente aggiornato per le patch di sicurezza, ecc. / Var è per i file che cambiano "frequentemente", il che consente di montare un filesystem ottimizzato per le scritture pesanti di piccoli file. Sostenere che un database non appartiene a / var non rafforza il caso dei siti Web, ma sostiene che non lo fanno. I siti Web sono molto letti e non ottengono alcun vantaggio dall'essere on / var e possono effettivamente rallentare i processi di sistema essenziali come la registrazione e la posta elettronica.
Duncan,

6

IIRC, ai vecchi tempi, montavamo sempre /varcome proprio file system (disco separato o slice di un disco).

Uno dei motivi di ciò, come altri hanno affermato, è che ci sono pesanti letture / scritture su quel filesystem (logs / et al). Avere un disco / slice separata significa che può essere meglio ottimizzato per questo tipo di I / O (contro lo più leggere /, /usrecc ...).

L'altro motivo è che a quei tempi, se il tuo sistema si arrestava in modo anomalo durante un'operazione di scrittura, c'erano ottime possibilità che il tuo filesystem di root potesse corrompersi lasciandolo in uno stato difficile da riparare. Quindi la necessità di separazione da /.

La tecnologia del filesystem e del disco è notevolmente migliorata nel tempo, quindi questo è un evento molto meno probabile.


1
/ var come una partizione separata è comunque una buona pratica se non si desidera arrestare il computer quando i registri diventano selvaggi, a causa / essendo pieno
Duncan

3

/var è una scelta decente per una posizione "base" neutra dall'utente per l'accesso multiutente, nel caso in cui tu abbia un sito Web con più host virtuali in esecuzione che consente FTP o altri caricamenti, vale a dire se sei un host web o simile.

/homeè forse non ottimale perché le cose cattive potrebbe accadere ad altre shell account utente se un irriflessive o dannosi caricamenti utente al /homelimite partizione (supponendo impostazione tradizionale /var, /homeecc essendo su partizioni separate) può influenzare altri account utente.

Naturalmente penso che /srvsia meglio per questo, ma /varè stato in giro più a lungo nella tradizione UNIX.


Le distribuzioni e i pacchetti distribuiti dovrebbero aderire all'FHS. L '"utente" finale (sysadmin se è un server) può fare ciò che vuole e collocare il sito Web ovunque. Ho messo i siti Web in / home / pub o / home / web da prima che esistesse / srv. Ma se dovessi distribuire un progetto software per server Web oggi, / srv / www o qualunque cosa FHS affermi sarebbe l'impostazione predefinita, anche se l'amministratore può cambiarlo.
Skaperen,

@ultrasawblade, perché no /home/http?
Pacerier,

1

Quello che vorrei aggiungere qui è che mettere il web "root" in / usr è in conflitto con la parte dell'FHS che indica / usr come condivisibile e di sola lettura, poiché server Web diversi, anche sullo stesso "cluster" può avere file diversi che contengono diverse configurazioni e questo non lo rende ideale per / usr.

Inoltre, alcune applicazioni web (MediaWiki e PhpBB per nominare quelle in cima alla mia testa) si aspettano una posizione scrivibile sotto l'albero della directory web per i caricamenti di file multimediali / allegati. Quindi mettere il web tree sotto / usr sarebbe in conflitto se si desidera aderire alla definizione di sola lettura / usr.


1

Il server Web Apache ha un sito Web predefinito in / var / www / ma suggerisce di mettere altri siti Web in / srv /

L'ho notato su Ubuntu Server 14.04 LTS. Il suo file apache2.conf predefinito contiene un blocco commentato:

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted
#</Directory>
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.