Pourquoi le répertoire racine d’un serveur Web est-il placé par défaut dans «/ var / www»?

87

Tuxfiles dit ce qui suit à propos de la structure de répertoires Linux:

/var:

Ce répertoire contient des données variables qui changent constamment lorsque le système est en cours d'exécution.

FHS on/var dit ce qui suit:

/varcontient des fichiers de données variables. Cela inclut les répertoires et fichiers de spool, les données administratives et de journalisation, ainsi que les fichiers temporaires et temporaires.

Ils continuent ensuite en disant que des éléments tels que les journaux, le courrier et le spouleur sont placés dans ce dossier.

Traditionnellement, une installation de base d’Apache ou de Nginx sur Ubuntu Linux placera le répertoire dans /var/www/.

Il ne me semble pas que ce soit l'endroit idéal pour mettre un répertoire avec des fichiers ou du contenu supposé être presque permanent.

Pourquoi est-il si souvent mis dans /var?

Plus subjectivement, s’agit-il de l’idéal, selon la structure des répertoires?

Jonallard
la source
2
C’est une bonne question que je me suis souvent posée et avec laquelle je me suis arrangée :).
loup
1
Selon FHS, /var/lib/wwwcela aurait été plus approprié ...
Nils
3
La FHS actuelle indique que la racine du serveur Web devrait se situer quelque part au- dessous/srv
LogicDaemon
1
/varIl s'agit de données non exécutables non configurables n'appartenant pas à un utilisateur réel mais pouvant être éditées ou modifiées (par exemple, doivent vivre sur un volume réinscriptible). /var/libest spécifiquement destiné à ce type de données qui devrait survivre à un redémarrage et ne pas être supprimé par un processus de maintenance, isc-dhcp-serversert /var/libà stocker son enregistrement de baux DHCP par exemple. Ce serait donc un endroit logique pour les fichiers de serveur Web.
LawrenceC
@Nils, pourquoi lib?
Pacerier

Réponses:

35

Ce n'est en fait pas l'emplacement "traditionnel" du tout. Traditionnellement, tout ce que vous avez installé après l’exploitation du système d’exploitation /usr/local, et c’est bien la "disposition de chemin classique Apache" (leurs mots) à ce jour. Pendant longtemps, c’était /home/httpd.

Ce que vous voyez, c'est qu'un Apache qui a été configuré pour un système d'exploitation particulier - qu'il s'agisse de Red Hat Linux, Mac OS X, GNU, etc. - va personnaliser l'emplacement. Les sources d'Apache sont bien conçues pour cela. En fait, si vous tracez la valeur de ServerRoot dans les fichiers source, vous verrez qu'elle commence dans ce fichier config.layout:

Certains extraits de ce fichier vous montreront qu'il y a beaucoup de variété dans l'emplacement docroot.

L’IIRC /var/wwwest entré dans ma vie avec les versions 2000-2001 de Red Hat Linux 7.x (et non de Red Hat Enterprise Linux). Pour toutes les raisons que vous avez citées ci-dessus, j’ai pensé que cela n’avait pas beaucoup de sens - mais la réalité est qu’à l’ère moderne, de nombreux autres outils et technologies sont impliqués, et que le lieu change quand même.

#   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
ckhan
la source
33

L'utilisation de /var/wwwest déroutant seulement à première vue.

Selon la FHS, les données du serveur Web devraient aller à /srv. C'est la règle principale.

Cependant, il est également indiqué que la décision concernant la structure de /srvest de la responsabilité exclusive de l'administrateur local! Par conséquent, les packages ne doivent rien insérer dans /srv, et la racine du document par défaut ne doit pas l'être /srv, car le package (apache) ne sait pas ce qu'il contient et ce qu'il contient /srv. Peut-être un référentiel de subversion avec un mot de passe en texte clair et d'autres éléments. Donc, il doit y avoir un défaut en dehors de /srv. Ce défaut devient /var/www.

/var/wwwest principalement un espace réservé. Les packages sont utilisés /usr/sharepour le contenu HTML statique ou /var/libpour le contenu de variable dynamique. De nombreuses personnes ont pensé, à tort, qu’elles devraient ensuite insérer du code HTML /var/www. C'est un problème, car les paquets l'utilisent aussi occasionnellement. Si récemment, ils ont inventé /var/www/htmlpour les paquets. Espérons que les gens ne commenceront pas à utiliser cela, car ils doivent à nouveau inventer un nouveau répertoire ... et ainsi de suite.

Résumé: vous devez utiliser /srvet configurer vos hôtes virtuels Apache en conséquence.

Hontvári Levente
la source
5
Cette réponse est vraiment précieuse. "Espérons que les gens ne commenceront pas à utiliser ça, car encore une fois, ils doivent inventer un nouveau répertoire ... et ainsi de suite." Indique que de nombreux administrateurs devraient prendre le temps de lire quelques notions de base. (comme je le fais en ce moment;))
Toastgeraet
Cela s'est déjà produit dans les versions Ubuntu. La racine par défaut du document apache est / var / www / html. J'ai lu quelque part que la raison du changement était qu'il était plus sécurisé. Je ne peux pas contester cela car je ne sais pas. Je peux vous dire que je n'utiliserai pas ce chemin. et je vais continuer avec la configuration que j'utilise depuis un moment. Je monte un disque spécifiquement pour les hôtes virtuels dans / sites Web. Je conserve une structure similaire à celle de l'hébergement cpanel et je sers depuis / websites / vhostname / public_html. De cette façon, je peux utiliser le vhost pour conserver du courrier ou autre pour le vhost spécifique.
Chris
J'envisage actuellement de partitionner un disque et de monter les partitions dans le répertoire vhost pour une sauvegarde individuelle. ce qui me donnerait / websites / vhost / backup dans chaque vhost (j'en exécute quelques-uns et le serai probablement plus tard)
Chris
24

Bien que je sois d’accord avec la réponse d’Akond, je pense qu’elle revêt un aspect plus important. La plupart des autres emplacements (tels que /usr/local) sont généralement gérés par le système (le gestionnaire de packages). /varest généralement l'endroit où vont les fichiers qui ne sont pas gérés par le gestionnaire de paquets («données» à l'échelle du système).

Je pense aussi que la définition de la FHS est un peu plus précise (les données ne doivent pas nécessairement "changer constamment"):

/ var contient des fichiers de données variables. Cela inclut les répertoires et fichiers de spool, les données administratives et de journalisation, ainsi que les fichiers temporaires et temporaires.


Cependant, la FHS indique également que les données www devraient être utilisées/srv

/ srv contient des données spécifiques au site qui sont servies par ce système.

Le principal objectif de cette spécification est de permettre aux utilisateurs de trouver l'emplacement des fichiers de données pour un service donné et de placer raisonnablement les services nécessitant une seule arborescence pour les données en lecture seule, les données inscriptibles et les scripts (tels que les scripts cgi).

La méthodologie utilisée pour nommer les sous-répertoires de / srv n’est pas spécifiée car il n’existe actuellement aucun consensus sur la manière de procéder. Une méthode pour structurer les données sous / srv est par protocole, par exemple. ftp, rsync, www et cvs.

Patrick
la source
7
Euh, l’important, /usr/localc’est que ce n’est pas géré par le gestionnaire de paquets.
derobert
@derobert / usr / local est beaucoup utilisé par les paquets tiers (paquets non fournis par le dépôt de la distribution). Il est également courant que les entreprises qui construisent leurs propres paquets les y mettent (bien que cela relève toujours des paquets non fournis par la distribution). Ceci est également soutenu par la FHS, voir la note 27 au bas de pathname.com/fhs/pub/fhs-2.3.html
Patrick
3
/srv/wwwétait le chemin classique sur les systèmes SuSE (jusqu’à SLES10).
Nils
1
@nils attend, ils étaient conformes à la FHS et l'ont délibérément abandonnée ??? soupir
Patrick
1
@ Patrick donc c'est vrai - j'ai été assez étonné quand j'ai réalisé cela. Ils voulaient probablement ressembler davantage aux autres variantes de Linux ...
Nils
13

Les raisons sont principalement historiques, comme d'autres l'ont dit. /vara été utilisé pour les données système qui changent tout le temps, par exemple les fichiers de cache, les journaux, les données d’exécution (fichiers de verrouillage, par exemple), le stockage du serveur de messagerie, le spooling de l’imprimante, etc. En gros, pour tout ce qui ne peut pas être inséré /usr( parce qu’il contient des données locales), ne sont pas des programmes tiers qui entrent dans /opt, et ne sont pas jetables et volatiles comme ils entrent /tmp.

Au fur et à mesure que Unix / Linux se développait, il devenait un endroit désordonné avec un mélange de plusieurs répertoires différents. Il y a eu une tendance ces dernières années pour passer certaines choses de là, en particulier le contenu servi par la machine (qui maintenant par [ Système de fichiers Hiérarchie standard 2.3, p.15 devrait aller] /srv, non /var/www).

Chose semblable est arrivé à /var/runquelques années - avec l'effort concentré de plusieurs distributions, il a été déplacé de /var/rundans /runlaquelle fusionné les fonctions du utilisé précédemment /var/lock, /var/runet /dev/shm.

mindcorrosif
la source
6

D'après mon expérience (je suis un développeur Web), le contenu du site Web est loin d'être stable. Même dans le cas de fichiers HTML (nevermind, contenu généré dynamiquement), ils sont soumis à des modifications constantes (modifications, omissions, etc.).

Donc, de mon point de vue, ce sont des variables. Ainsi, ils sont parfaitement adaptés dans le répertoire / var et il n’ya rien de mal à cela.

akond
la source
6
Je ne suis pas d'accord. Je ne vois toujours pas les fichiers HTML comme "changeant constamment". Les modifications qui y sont apportées sont délibérées et devraient idéalement être intégrées dans un contrôle de révision pour le suivi des modifications.
jonallard
2
Les modifications apportées à la base de données Mysql sont également délibérées, mais les fichiers de base de données se trouvent dans / var / db. Ne vous dérange pas?
akond
5
Bien sûr, mais je dirais que sur le continuum de variable à constante, la base de données serait plus variable que l'application HTML / what / / web, car il existe moins de versions des pages Web que de la base de données. Les pages ayant des versions relativement peu différentes, je ne mettrais pas dans /var. Mais je pense que c'est une question d'opinion et de débat plutôt que des faits concrets.
jonallard
1
Que diriez-vous si je vous montrais une base de données qui n'a pas été modifiée depuis deux ans?
akond
2
D'après les arguments donnés ici, les répertoires de base appartiennent à / var. D'ailleurs, il en va de même de / usr car il est mis à jour constamment pour les correctifs de sécurité, etc. / var est utilisé pour les fichiers qui changent "fréquemment", ce qui permet de monter un système de fichiers optimisé pour les écritures lourdes de petits fichiers. Faire valoir qu'une base de données n'appartient pas à / var ne renforce pas le cas des sites Web, mais le fait vraiment. Les sites Web sont très lus et n'apportent aucun avantage à être sur / var, et peuvent en fait ralentir les processus système essentiels tels que la journalisation et la messagerie électronique.
Duncan
6

IIRC, jadis, nous montions toujours /varcomme son propre système de fichiers (disque séparé ou tranche de disque).

Une des raisons de ceci, comme d'autres l'ont dit, est qu'il y a beaucoup de lecture / écriture sur ce système de fichiers (logs / et al). Avoir un disque / tranche séparée signifie qu'il peut être mieux à l' écoute pour ce type d'E / S (par rapport lu principalement sur /, /usr, etc ...).

L'autre raison est que, à cette époque, si votre système tombait en panne au cours d'une opération d'écriture, il était très probable que votre système de fichiers racine soit corrompu, le laissant ainsi difficile à réparer. Ainsi, le besoin de séparation de /.

La technologie des systèmes de fichiers et des disques s’est considérablement améliorée avec le temps, c’est donc un événement beaucoup moins probable.

Brian
la source
1
/ var en tant que partition séparée est toujours une bonne pratique si vous ne voulez pas arrêter votre machine lorsque vos journaux deviennent fous, à cause de / étant pleine
Duncan
3

/var est un choix décent pour un emplacement "de base" indépendant de l'utilisateur pour un accès multi-utilisateur, si vous avez un site Web avec plusieurs hôtes virtuels en fonctionnement permettant le téléchargement par FTP ou autre, c'est-à-dire si vous êtes un hôte Web ou similaire.

/homeest peut - être pas optimal parce que les mauvaises choses pourraient se produire à d' autres comptes shell utilisateur si un utilisateur télécharge irréfléchis ou malveillants à la /homelimite de la partition ( en supposant la configuration traditionnelle de /var, /home, etc. étant sur des partitions distinctes) elle peut affecter d' autres comptes d'utilisateurs.

Bien sûr, je pense que /srvc'est mieux pour cela, mais cela /varfait plus longtemps dans la tradition UNIX.

LawrenceC
la source
Les distributions et les packages distribués doivent être conformes à la FHS. L’utilisateur final (sysadmin s’il s’agit d’un serveur) peut faire ce qu’il veut et placer le site Web n’importe où. J'ai mis des sites Web dans / home / pub ou / home / web depuis avant qu'il y ait / srv. Mais si je distribuais aujourd'hui un projet de logiciel de serveur Web, / srv / www ou tout ce que FHS dit serait la valeur par défaut, bien que l'administrateur puisse le changer.
Skaperen
@ultrasawblade, pourquoi pas /home/http?
Pacerier
1

Ce que j'aimerais ajouter ici, c'est que placer la racine Web dans / usr est en conflit avec la partie de la FHS qui indique que / usr est partageable et en lecture seule, car différents serveurs Web, même sur le même "cluster". peut avoir différents fichiers contenant différentes configurations, ce qui ne le rend pas idéal pour / usr.

De plus, certaines applications Web (MediaWiki et PhpBB pour nommer celles qui me viennent à l’esprit) s’attendent à un emplacement en écriture dans l’arborescence de répertoires Web pour le téléchargement de pièces jointes / fichiers multimédias. Donc, placer l’arborescence Web sous / usr créerait un conflit si vous souhaitez adhérer à la définition en lecture seule / usr.

Didi Kohen
la source
1

Le serveur Web Apache a un site Web par défaut sous / var / www /, mais il suggère de placer d’autres sites Web sous / srv /.

J'ai remarqué cela sur Ubuntu Server 14.04 LTS. Son fichier apache2.conf par défaut contient un bloc commenté:

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted
#</Directory>
Maris B.
la source