Pourquoi le répertoire racine d'un serveur Web est-il placé par défaut dans "/ var / www"?
Tuxfiles dit ce qui suit à propos de la structure du répertoire Linux:
/var:Ce répertoire contient des données variables qui changent constamment lorsque le système est en cours d'exécution.
FHS le /var dit le texte suivant:
/varcontient des fichiers de données variables. Cela inclut les répertoires et fichiers spoule, les données administratives et de journalisation, ainsi que les fichiers transitoires et temporaires.
Ils continuent ensuite en disant que des choses comme les journaux, le courrier et le spouleur sont placés dans ce dossier.
Traditionnellement Une installation standard d'Apache ou de Nginx sur Ubuntu Linux placera le répertoire à /var/www/.
Cela ne me semble pas être l'endroit idéal pour mettre un répertoire avec des fichiers ou autrement un contenu qui est censé être presque permanent.
Pourquoi est-il si souvent mis dans /var?
Plus subjectivement, est-ce là que cela devrait idéalement aller, selon la structure du répertoire?
L'utilisation de /var/www ne prête à confusion qu'à première vue.
Selon le FHS, les données du serveur Web devraient aller à /srv. Telle est la règle principale.
Cependant, il indique également que décider de la structure de /srv est de la seule responsabilité de l'administrateur local! Par conséquent, les packages ne doivent rien mettre dans /srv, et la racine du document par défaut ne doit pas être /srv, car le package (Apache) ne sait pas ce qu'il y a dans /srv et en dessous. Peut-être un dépôt Subversion avec un mot de passe en texte clair et d'autres choses aussi. Il doit donc y avoir une valeur par défaut en dehors de /srv. Ce défaut devient /var/www.
/var/www est principalement un espace réservé. Les packages utilisent /usr/share pour le contenu HTML statique ou /var/lib pour le contenu de variable dynamique. Beaucoup de gens pensaient à tort qu'ils devraient ensuite mettre du HTML dans /var/www. C'est un problème, car les packages l'utilisent parfois aussi. Alors récemment, ils ont inventé /var/www/html pour les packages. Avec un peu de chance, les gens ne commenceront pas à utiliser cela parce qu'encore une fois ils doivent inventer un nouveau répertoire ... et ainsi de suite.
Résumé: vous devez utiliser /srv et configurez vos hôtes virtuels Apache en conséquence.
Ce n'est pas du tout l'emplacement "traditionnel". Traditionnellement, tout ce que vous avez installé après que le système d'exploitation est entré dans /usr/local, et c'est bien la "disposition du chemin Apache classique" (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 - que ce soit Red Hat Linux, Mac OS X, GNU, etc. - personnalisera l'emplacement. La source d'Apache est bien conçue 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.
IIRC, /var/www est entré dans ma vie avec les versions 2000-2001 de Red Hat Linux 7.x (pas Red Hat Enterprise Linux). Pour toutes les raisons que vous citez ci-dessus, je pensais 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, l'emplacement change de toute façon.
# 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
Bien que je sois d'accord avec la réponse d'Akond, je pense qu'il y a 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). /var correspond généralement aux fichiers qui ne sont pas gérés par le gestionnaire de packages ("données" à l'échelle du système).
Je pense aussi que la définition du FHS est un peu plus précise (les données ne doivent pas être "en constante évolution"):
/ var contient des fichiers de données variables. Cela inclut les répertoires et fichiers spoule, les données administratives et de journalisation, ainsi que les fichiers transitoires et temporaires.
Cependant, les FHS espèces également dans lesquelles les données www devraient entrer /srv
/ srv contient des données spécifiques au site qui sont servies par ce système.
Le but principal de cette spécification est de permettre aux utilisateurs de trouver l'emplacement des fichiers de données pour un service particulier et de pouvoir placer raisonnablement les services qui nécessitent 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'y a 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.
Les raisons sont principalement historiques, comme d'autres l'ont dit. /var A é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, la mise en file d'attente de l'imprimante, etc. Fondamentalement pour toutes les choses qui peuvent ne doit pas être placé dans /usr (car il contient des données locales), ne sont pas des programmes tiers qui vont dans /opt, et ne sont pas jetables et volatils car ils vont dans /tmp.
Au fur et à mesure que Unix/Linux se développait, il est devenu un endroit en désordre avec un méli-mélo de divers répertoires différents mis en place. Ces dernières années, il y a eu une tendance à déplacer certaines choses, en particulier le contenu servi par la machine (qui, selon [ Filesystem Hierarchy Standard 2.3, p.15 ] devrait aller dans /srv, Pas dans /var/www).
Une chose similaire est arrivée à /var/run Il y a quelques années - avec l'effort concentré de plusieurs distributions, il a été déplacé de /var/run Vers /run Qui fusionnait les fonctions de celles précédemment utilisées. /var/lock, /var/run Et /dev/shm.
D'après mon expérience (je suis développeur Web), le contenu du site Web est loin d'être stable. Même dans le cas de fichiers html (contenu généré dynamiquement par nevermind), ils sont sujets à des changements constants (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'y a rien de mal à cela.
IIRC, dans les temps anciens, nous avons toujours monté /var comme son propre système de fichiers (disque séparé ou tranche de disque).
Une des raisons pour cela, comme d'autres l'ont dit, est qu'il y a beaucoup de lecture/écriture sur ce système de fichiers (logs/et al). Le fait d'avoir un disque/tranche séparé signifie qu'il peut être mieux réglé pour ce type d'E/S (par rapport à la plupart du temps lu sur /, /usr, etc...).
L'autre raison est qu'à cette époque, si votre système tombait en panne lors d'une opération d'écriture, il y avait de très bonnes chances que votre système de fichiers racine soit corrompu, le laissant dans un état difficile à réparer. Ainsi, la nécessité d'une séparation de /.
La technologie des systèmes de fichiers et des disques s'est considérablement améliorée au fil du temps, c'est donc beaucoup moins probable.
/var est un choix décent pour un emplacement "de base" neutre pour l'utilisateur pour un accès multi-utilisateur, dans le cas où vous avez un site Web avec plusieurs hôtes virtuels en cours d'exécution qui permet FTP ou d'autres téléchargements, c'est-à-dire si vous êtes un hébergeur ou similaire.
/home n'est peut-être pas optimal car de mauvaises choses pourraient arriver à d'autres comptes Shell d'utilisateurs si un utilisateur irréfléchi ou malveillant télécharge sur le /home limite de partition (en supposant une configuration traditionnelle de /var, /home, etc. étant sur des partitions séparées), cela peut affecter d'autres comptes d'utilisateurs.
Bien sûr, je pense que /srv c'est mieux pour ça mais /var existe depuis plus longtemps dans la tradition UNIX.
Ce que je voudrais ajouter ici, c'est que mettre le "root" web dans/usr entre en conflit avec la partie du FHS qui indique/usr comme étant partageable et en lecture seule, puisque 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 du haut de ma tête) s'attendent à un emplacement accessible en écriture sous l'arborescence du répertoire Web pour les pièces jointes/les téléchargements de fichiers multimédias. Donc, mettre l'arborescence Web sous/usr serait en conflit si vous souhaitez respecter la définition/usr en lecture seule.
Le serveur Web Apache a un site Web par défaut sous / var/www / mais il suggère de mettre 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>