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 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?

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

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.

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.

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.

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.

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.

/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.

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.

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>