









       Norme de hirarchie du systme de fichiers -- Version 2.0

       Groupe pour la norme de hirarchie du systme de fichiers
                       dite par Daniel Quinlan


                                ABSTRACT

          Cette norme consiste en un ensemble d'exigences et de
     suggestions concernant la disposition des fichiers et des
     rpertoires dans un systme d'exploitation de type UNIX. Les
     suggestions servent  faciliter l'interoprabilit des
     applications, des outils d'administration systme, des outils
     de dveloppement et des scripts, ainsi qu' avoir une
     documentation plus uniforme pour ces systmes.



January 16, 19100








































Norme de hirarchie du systme de fichiers              1er fvrier 1998



Toutes les marques dposes et les copyrights appartiennent  leurs
propritaires, sauf notification spcifique. L'utilisation d'un terme
dans ce document ne devrait pas tre considre comme affectant la
validit de toute marque dpose ou marque de fabrique.
































Copyright  1994, 1995, 1996, 1997 Daniel Quinlan

Nous accordons la permission de faire et de distribuer des copies
exactes de cette norme  la condition que le copyright et cette note de
permission soient prserves sur toutes les copies.

Nous accordons la permission de copier et distribuer des versions
modifies de cette norme sous les conditions de copie exacte, 
condition que la page de titre indique qu'elle a t modifie en
incluant une rfrence  la norme d'origine,  condition que soient
incluses les informations ncessaires  la recherche de la norme
d'origine, et  condition que le travail driv complet soit distribu
sous les termes d'une note de permission identique  celle-ci.

Nous accordons la permission de copier et de distribuer des traductions
de cette norme dans une autre langue, avec les conditions ci-dessus pour
les versions modifies,  part le fait que cette note de permission soit
donne dans une traduction approuve par le tenant du copyright.


                                  - i -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



1.  Introduction



1.1  tat de la norme

Voici la version 2.0 de la norme de hirarchie du systme de fichiers
(FHS 2.0).

Les commentaires sur cette norme sont les bienvenus de la part des
personnes intresses. Les suggestions de modifications devraient tre
faites sous la forme d'une proposition de changement du texte,
accompagne de commentaires explicatifs appropris.

Les suggestions de cette norme sont sujettes  modification.
L'utilisation des informations incluses dans ce document se fait  vos
risques et prils.



1.2  Organisation de la norme

Cette norme est divise entre les sections suivantes :


  1.  introduction ;

  2.  le systme de fichiers : tablissement de quelques principes cls
      ;

  3.  le rpertoire racine ;

  4.  la hirarchie /usr ;

  5.  la hirarchie /var ;

  6.  annexe spcifique au systme d'exploitation.


1.3  Conventions

Nous recommandons que lisiez une version mise en pages de ce documents
plutt que la version texte. Dans la version mise en pages, les noms de
fichiers et de rpertoire sont affichs dans une police  taille fixe.

Les parties variables des noms de fichiers sont reprsentes par une
description de leur contenu  l'intrieur des caractres chevrons "<" et
">", <ainsi>. Les adresses de courrier lectronique sont aussi entoures
de chevrons "<" et ">" mais sont indiques dans la police habituelle.

Les parties optionnelles des noms de fichiers sont entoures des
caractres crochet "[" et "]" et peuvent tre combines avec la
convention "<" et ">". Par exemple, si on pouvait trouver un fichier
existant avec ou sans extension, on pourrait le reprsenter par <nom de


                                  - 1 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



fichier>[.<extension>].

Les parties de chanes variables des noms de rpertoires et de fichiers
sont indiques par une toile : "*".




















































                                  - 2 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



1.4  Historique de la FHS

Le processus de dveloppement d'une hirarchie de systme de fichiers
standard a dbut en aot 1993 dans un effort de restructuration de la
structure de fichiers et de rpertoires de Linux. La FSSTND, norme pour
une hirarchie du systme de fichiers spcifique au systme
d'exploitation Linux, est sortie le 14 fvrier 1994. Des versions
successives sont sorties le 9 octobre 1994 et le 28 mars 1995.

Au dbut de 1995, avec l'aide de membres de la communaut de
dveloppement BSD, il a t dcid de dvelopper une version de FSSTND
plus complte pour englober non seulement Linux mais aussi les autres
systmes de type UNIX. En dfinitive, nous avons fait un effort concert
pour nous concentrer sur des problmes gnraux aux systmes de type
UNIX. En reconnaissance de cette ouverture, le nom de la norme a t
modifi pour devenir Norme de hirarchie du systme de fichiers ou FHS
en abrg. (NDT : en anglais, FHS veut dire Filesystem Hierarchy
Standard.)

Les noms des volontaires qui ont contribu activement  cette norme sont
indiqus  la fin de ce document. Cette norme reprsente un consensus
entre les points de vue de ceux-ci et d'autres contributeurs.


1.5  tendue

Ce document spcifie une hirarchie de systme de fichiers standard pour
les systmes de fichiers FHS en indiquant l'emplacement des fichiers et
rpertoires, et le contenu de certains fichiers systme.

Cette norme a t faite pour tre utilise par les intgrateurs de
systmes, les dveloppeurs de paquets et les administrateurs systme
dans la construction et la maintenance de systmes de fichiers se
conformant  FHS. Elle est tout d'abord destine  servir de rfrence
et n'est pas un tutoriel sur la manire de grer une hirarchie de
systme de fichiers conforme.

La FHS est base sur des travaux prliminaires sur FSSTND, une norme
d'organisation du systme de fichiers pour le systme d'exploitation
Linux. Elle est base sur la FSSTND pour pallier  des problmes
d'interoprabilit non seulement dans la communaut Linux mais dans un
horizon plus vaste comprenant les systmes d'exploitation bass sur
4.4BSD. Elle incorpore les leons concernant le support de plusieurs
architectures et les demandes en matire de rseaux htrognes, leons
apprises dans le monde BSD ou ailleurs.

Bien que cette norme soit plus complte que les tentatives prcdentes
sur la normalisation de la hirarchie de systmes de fichiers, des mises
 jour priodiques peuvent s'avrer ncessaires  mesure que les
demandes changent par rapport  la technologie mergeante. Il est aussi
possible que de meilleures solutions aux problmes voqus ici soient
dcouvertes ou que nos solutions ne soient plus les meilleures
possibles. Des brouillons supplmentaires pourront tre apports en plus
des mises  jour priodiques de ce document. Cependant, l'un des buts


                                  - 3 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



suivis est la compatibilit ascendante entre une version de ce document
et la suivante.

Les commentaires relatifs  cette norme sont les bienvenus. Tout
commentaire ou suggestion de modification devraient tre adresss 
l'diteur de la FHS (Daniel Quinlan <quinlan@pathname.com>), ou si vous
prfrez,  la liste de diffusion FHS. Les commentaires de nature
typographique ou grammaticale doivent tre adresss directement 
l'diteur de la FHS.

Nous vous demandons de contacter en premier l'diteur de la FHS avant
d'envoyer un courrier  la liste de diffusion afin d'viter un nouveau
dbat sur des sujets anciens. Les messages mal conus ne seront pas bien
vus sur la liste de diffusion.

Des questions concernant l'interprtation des objets de ce document
peuvent se poser de temps en temps. Si vous avez besoin de prcisions,
veuillez contacter l'diteur de la FHS. Puisque cette norme reprsente
le consensus de nombreux participants, il est important de s'assurer que
toute interprtation reprsente aussi l'opinion collective. Pour cette
raison, il peut ne pas tre possible de fournir une rponse immdiate
sauf si la demande a dj fait l'objet d'une discussion.


1.6  Indications gnrales

Voici quelques-unes des suggestions qui ont t utilises dans le
dveloppement de cette norme :


    rsoudre des problmes techniques tout en limitant les difficults
     de la transition ;

    faire une spcification suffisamment stable ;

    obtenir l'approbation des distributeurs, des dveloppeurs, et
     autres dcideurs dans les groupes de dveloppement adquats et
     encourager leur participation ;

    fournir une norme attractive pour les implmenteurs des diffrents
     systmes de type UNIX.


1.7  Audience vise

L'audience vise par cette norme comprend, mais n'est pas limite aux
groupes de personnes suivants :


    dveloppeurs de systmes ;

    intgrateurs et distributeurs de systmes ;




                                  - 4 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



    dveloppeurs d'applications ;

    auteurs de documentations ;

    administrateurs systme et autres personnes intresses ( des fins
     d'information).


1.8  Conformit avec ce document

Cette section dfinit la signification des termes "conforme" et
"compatible" en ce qui concerne cette norme, et de conformit et
compatibilit "partielle".

Une "implmentation" fait ici rfrence  une distribution, un systme
install, un programme, un paquet (ou toute partie similaire d'un
logiciel ou de donnes), ou tout composant de ceux-ci.

Une implmentation est totalement conforme  cette norme si chaque
exigence de cette norme est satisfaite. Chaque fichier ou rpertoire
faisant partie de l'implmentation doit tre situ comme il est spcifi
dans ce document. Si le contenu d'un fichier est dcrit ici, le contenu
vritable doit correspondre  la description. L'implmentation doit
aussi tenter de trouver tout fichier ou rpertoire (extrieur  elle-
mme) en premier lieu ou exclusivement  l'endroit spcifi dans cette
norme.


Une implmentation est totalement compatible avec cette norme si chaque
fichier ou rpertoire qu'elle contient peut tre trouv en regardant 
l'endroit spcifi ici et sera trouv avec un contenu identique  ce qui
est spcifi ici, mme si ce n'est pas l'emplacement de base ou physique
du fichier ou du rpertoire en question. L'implmentation doit, quand
elle essaie de trouver un fichier ou un rpertoire n'en faisant pas
partie, le faire  l'endroit spcifi dans cette norme, bien qu'elle
puisse aussi tenter de le trouver  d'autres endroits (non standards).

Une implmentation est partiellement conforme ou compatible si elle est
conforme  ou compatible avec une partie significative de ce document.
La conformit ou compatibilit partielle n'est faite pour s'appliquer
qu'aux distributions et non  des programmes spars. L'expression "une
partie significative" est effectivement subjective, et dans les cas
limites, la personne concerne devrait contacter l'diteur de la FHS.
Nous avons anticip le fait que des drapages soient tolrs dans les
cas limites.

Afin de se dfinir comme partiellement conforme  la FHS ou
partiellement compatible avec la FHS, une implmentation doit fournir
une liste de tous les endroits auxquels elle et le document FHS
diffrent, en plus d'une courte explication de la raison de cette
diffrence. Cette liste sera fournie avec l'implmentation en question,
et aussi mise  disposition de la liste de diffusion FHS ou de l'diteur
de la FHS.



                                  - 5 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Les termes "doit", "devrait", "contient", "est" et ainsi de suite
doivent tre lus comme des exigences pour la conformit ou la
compatibilit.

Notez qu'une implmentation n'a pas besoin de contenir tous les fichiers
et rpertoires spcifis dans cette norme pour tre conforme ou
compatible. Il est simplement ncessaire que les fichiers qu'elle
contient soient placs correctement. Par exemple, si le systme de
fichiers minix n'est pas support par une distribution, les outils minix
n'ont pas besoin d'tre inclus, mme s'ils sont mentionns explicitement
dans la section sur /sbin.

De plus, certaines parties de ce document sont optionnelles. Dans ce
cas, ceci sera dit explicitement, ou indiqu  l'aide d'un ou plusieurs
mots parmi "peut", "recommande" ou "suggre". Les objets indiqus comme
optionnels n'ont pas de porte sur la conformit ou la compatibilit
d'une implmentation ; ce sont des suggestions faites pour encourager la
pratique courante, mais ils peuvent tre situs n'importe o au gr de
l'implmenteur.





































                                  - 6 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



2.  Le systme de fichiers

Le systme de fichiers UNIX est caractris par :


    une structure hirarchique ;

    le traitement uniforme des fichiers de donnes ;

    la protection des fichiers de donnes.

Cette norme suppose que le systme d'exploitation sous-jacent  un
systme de fichiers conforme  la FHS supporte les mmes possibilits de
scurit de base que l'on trouve dans la plupart des systmes de
fichiers UNIX. Notez que cette norme n'essaie pas d'tre en accord au
mieux possible avec une implmentation quelconque d'un systme UNIX.
Cependant, beaucoup d'aspects de cette norme sont bass sur des ides
que l'on trouve dans UNIX et autres systmes de type UNIX.

Ceci aprs une considration attentive d'autres facteurs, comprenant :


    des pratiques courantes et saines dans les systmes de type UNIX ;

    l'implmentation d'autres structures de systmes de fichiers ;

    les normes applicables.

On peut dfinir deux catgories orthogonales de fichiers : partageables
contre non partageables, et variables contre statiques.

Les donnes partageables sont celles que l'on peut partager entre
plusieurs machines diffrentes ; non partageables, celles spcifiques 
une machine particulire. Par exemple, les rpertoires personnels des
utilisateurs sont des donnes partageables, mais les fichiers de verrou
de priphriques (locks), ne le sont pas.

Les donnes statiques comprennent les binaires, les bibliothques, la
documentation, et tout ce qui ne change pas sans l'intervention de
l'administrateur systme ; les donnes variables reprsentent tout le
reste qui change sans l'intervention de l'administrateur systme.

Pour faciliter la sauvegarde, l'administration et le partage de fichiers
sur des rseaux de systmes htrognes, il est prfrable d'tablir une
correspondance simple et aisment comprhensible entre les rpertoires
(surtout les rpertoires considrs comment des points de montage
potentiels) et le type de donnes qu'ils contiennent.

 travers ce document, et dans tout systme de fichiers bien organis,
la comprhension de ce principe de base aidera  diriger la structure et
lui apporter une cohrence supplmentaire.

La distinction entre donnes partageables et non partageables est
ncessaire pour plusieurs raisons :


                                  - 7 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



    dans un environnement en rseau (par exemple, plus d'un hte par
     site), une bonne partie des donnes peuvent tre partages entre
     diffrentes machines pour conomiser de la place et faciliter la
     tche de maintenance ;

    dans un environnement en rseau, certains fichiers contiennent des
     informations spcifiques  une seule machine. Par consquent ces
     systmes de fichiers ne peuvent tre partags (sans prendre des
     mesures spciales) ;

    historiquement, certaines implmentations des systmes de fichiers
     de type UNIX ont mlang des donnes partageables et non
     partageables dans la mme hirarchie, rendant difficile le partage
     de grandes parties du systme de fichiers.

La distinction "partageable" permet de supporter, par exemple :


    une partition /usr (ou des composants de /usr) monts (en lecture
     seule)  travers le rseau (en utilisant NFS) ;

    une partition /usr (ou des composants de /usr) monts  partir d'un
     support en lecture seule. Un CD-ROM peut tre considr comme un
     systme de fichiers en lecture seule partag avec d'autres systmes
     conformes  la FHS, en utilisant le systme de courrier comme un
     "rseau".


La distinction "statique" contre "variable" affecte le systme de
fichiers de deux manires principales :


    puisque / contient  la fois des donnes statiques et variables, il
     doit tre mont en lecture-criture ;

    puisque le traditionnel /usr contient  la fois des donnes
     variables et statiques, et puisque nous voudrons le monter en
     lecture seule (voir ci-dessus), il est ncessaire de fournir une
     mthode pour monter /usr en lecture seule. Ceci est obtenu par la
     cration d'une hirarchie /var qui est monte en lecture-criture
     (ou qui fait partie d'une autre partition en lecture-criture,
     telle que /), qui remplace bien des fonctions traditionnelles de la
     partition /usr.

Voici un tableau pour rsumer le tout. Puisque ce graphique contient des
exemples gnraliss, il peut ne pas s'appliquer  chaque implmentation
possible d'un systme conforme  la FHS.









                                  - 8 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



             +---------+-----------------+-----------------+
             |         | partageable     | non partageable |
             +---------+-----------------+-----------------+
             |statique | /usr            | /etc            |
             |         | /opt            | /boot           |
             +---------+-----------------+-----------------+
             |variable | /var/mail       | /var/run        |
             |         | /var/spool/news | /var/lock       |
             +---------+-----------------+-----------------+















































                                  - 9 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



3.  Le rpertoire racine

Cette section dcrit la structure du rpertoire racine (root). Le
contenu du systme de fichiers racine doit tre adquat pour dmarrer,
reconstituer, rtablir et/ou rparer le systme :


    pour dmarrer un systme, il doit y avoir suffisamment de choses
     sur la partition racine pour monter d'autres systmes de fichiers.
     Ceci comprend les utilitaires, la configuration, les informations
     du chargeur de dmarrage, et d'autres donnes de dmarrage
     importantes.  /usr, /opt et /var sont faits pour pouvoir tre
     situs sur d'autres systmes de fichiers ;

    pour permettre le rtablissement et/ou la rparation d'un systme,
     les utilitaires ncessaires au mainteneur expriment pour
     diagnostiquer et reconstruire un systme endommag doivent tre
     prsents sur le systme de fichiers racine ;

    pour reconstituer un systme, les utilitaires ncessaires  la
     reconstitution  partir des sauvegardes systme (sur disque, bande,
     etc.) doivent tre prsents sur le systme de fichiers racine.

Le principal argument utilis pour contrer ces considrations, qui
tendent  mettre beaucoup de choses sur le systme de fichiers racine,
est le but de garder la racine aussi petite que possible dans les
limites du raisonnable. Pour plusieurs raisons, il est souhaitable de
limiter la taille du systme de fichiers racine :


    il est mont de temps en temps  partir d'un moyen de stockage trs
     petit ;

    le systme de fichiers racine contient beaucoup de fichiers de
     configuration spcifiques au systme. Les exemples possibles
     comprennent un noyau spcifique au systme, un nom d'hte
     diffrent, etc. Ceci veut dire que le systme de fichiers racine
     n'est pas toujours partageable entre des systmes en rseau.
     Limiter sa taille sur des systmes en rseau minimise l'espace
     perdu en fichiers non-partageables sur les serveurs. Cela permet
     aussi d'avoir des stations de travail avec des disques durs locaux
     plus petits ;

    bien que vous puissiez avoir un systme de fichiers racine sur une
     grande partition, et pouvez le remplir  votre aise, il y aura des
     gens avec des partitions plus petites. Si vous avez plus de
     fichiers installs, vous pourrez trouver des incompatibilits avec
     d'autres systmes qui utilisent des systmes de fichiers racine sur
     des partitions plus petites. Si vous tes dveloppeur vous risquez
     de changer votre hypothse en un problme pour un grand nombre
     d'utilisateurs ;

    les erreurs de disque qui corrompent les donnes sur le systme de
     fichiers racine posent un problme plus important que les erreurs


                                 - 10 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



     sur tout autre partition. Un systme de fichiers racine petit est
     moins sujet  la corruption  la suite d'un plantage systme ;
les logiciels ne doivent jamais crer ou demander des fichiers spciaux
ou des sous-rpertoires dans le rpertoire racine. D'autres emplacements
dans la hirarchie FHS fournissent plus de flexibilit qu'il n'en faut
pour tout paquet.


Raison d'tre

Il y a plusieurs raisons pour lesquelles l'introduction d'un nouveau
rpertoire dans le systme de fichiers racine est interdit :

    ceci demande de la place sur une partition racine que
     l'administrateur systme veut garder petite et simple pour des
     raisons de performance ou de scurit ;

    ceci contredit toute logique que l'administrateur systme a pu
     mettre en place pour distribuer des hirarchies de fichiers
     standards sur des volumes montables.

/ -- le rpertoire racine
|
+-bin       binaires des commandes importantes
+-boot      fichiers statiques du chargeur de dmarrage
+-dev       fichiers de priphriques
+-etc       configuration systme spcifique  la machine
+-home      rpertoires personnels des utilisateurs
+-lib       bibliothques partages importantes et modules du noyau
+-mnt       point de montage des partitions temporaires
+-opt       paquets de logiciels applicatifs supplmentaires
+-root      rpertoire personnel de l'utilisateur root
+-sbin      binaires systmes importants
+-tmp       fichiers temporaires
+-usr       hirarchie secondaire
+-var       donnes variables


Chaque rpertoire list ci-dessus est spcifi en dtail dans des sous-
sections spares ci-dessous. /usr et /var ont chacun une section
complte dans ce document  cause de la complexit de ces rpertoires.

L'image du noyau du systme d'exploitation doit tre situ soit dans /,
soit dans /boot. Les informations supplmentaires sur l'emplacement du
noyau se trouvent dans la section concernant /boot ci-dessous.


3.1  /bin : binaires de commandes utilisateurs importantes (pour tous
les utilisateurs)

/bin contient des commandes  l'usage  la fois de l'administrateur
systme et des utilisateurs, mais qui sont obligatoires en mode
utilisateur simple. Il peut aussi contenir des commandes utilises
indirectement par des scripts.


                                 - 11 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Il ne devrait pas y avoir de sous-rpertoires  l'intrieur de /bin.

Les binaires des commandes qui ne sont pas suffisamment importantes pour
rester dans /bin doivent tre mises dans /usr/bin,  la place. Les
objets qui ne sont utiliss que par des utilisateurs non root (mail,
chsh, etc.) ne sont en gnral pas assez importants pour tre placs
dans la partition racine.



Fichiers obligatoires pour /bin :

    commandes gnrales :

     Les commandes suivantes ont t incluses parce qu'elles sont
     importantes. Certaines sont prsentes  cause de leur emplacement
     traditionnel dans /bin.


     { cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, ed,
       false, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps,
       pwd, rm, rmdir, sed, setserial, sh, stty, su, sync, true, umount,
       uname }

     Si /bin/sh est le Bash, alors /bin/sh devrait tre un lien
     symbolique ou en dur vers /bin/bash puisque Bash se comporte de
     manire diffrente quand il est appel en tant que sh ou bash.
     pdksh, qui peut tre /bin/sh sur certains disques d'installation,
     devrait tre arrang de la sorte, /bin/sh pointant vers /bin/ksh.
     L'utilisation d'un lien symbolique dans ces cas permet aux
     utilisateurs de voir aisment que /bin/sh n'est pas un vrai shell
     de Bourne.

     Puisque l'emplacement standard de facto du shell C est /bin/csh, si
     et seulement si un shell C ou quivalent (comme tcsh) est
     disponible sur le systme, il devrait tre disponible par le nom
     /bin/csh. /bin/csh peut tre un lien symbolique vers /bin/tcsh ou
     /usr/bin/tcsh.

     Note : les commandes [ et test sont intgres dans les
     remplacements du shell de Bourne (/bin/sh) les plus couramment
     utiliss. Ces deux commandes ne doivent pas tre places dans /bin
     ; elles peuvent tre places dans /usr/bin. Elles doivent tre
     incluses comme binaires spars sur tout systme UNIX ou de type
     UNIX essayant de se conformer  la norme POSIX.2.


    commandes de remise en tat :

     Ces commandes ont t ajoutes pour permettre la remise en tat
     d'un systme (en supposant que / soit intact).

     { tar, gzip, gunzip (lien vers gzip), zcat (lien vers gzip) }



                                 - 12 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



     Si les sauvegardes systme sont faites en utilisant des programmes
     autres que gzip et tar, alors la partition racine devrait contenir
     le minimum requis par les composants de remise en tat.  Par
     exemple, beaucoup de systmes devraient inclure cpio puisque c'est
     l'utilitaire de sauvegarde le plus couramment utilis aprs tar.
     Inversement, si l'on est sr de ne jamais faire aucune remise en
     tat de la partition racine, on peut alors omettre ces binaires
     (par exemple, une partition racine en ROM, montant /usr en NFS). Si
     la remise en tat d'un systme est prvue  travers le rseau,
     alors ftp ou tftp (avec tout ce qui est ncessaire 
     l'tablissement d'une connexion ftp) doit tre disponible sur la
     partition racine.

     Les commandes de remise en tat peuvent apparatre soit dans /bin,
     soit dans /usr/bin sur des systmes diffrents.


    commandes rseau :

     Voici les seuls binaires ncessaires pour le rseau, autres que
     ceux de /usr/bin ou /usr/local/bin, et que  la fois root et les
     utilisateurs voudront ou auront besoin d'excuter.

     { domainname, hostname, netstat, ping }


3.2  /boot : fichiers statiques du chargeur de dmarrage

Ce rpertoire contient tout ce qu'il faut pour le processus de dmarrage
 part les fichiers de configuration et l'installeur de carte. Ainsi,
/boot stocke les donnes utilises avant que le noyau ne commence 
excuter des programmes en mode utilisateur. Ceci peut comprendre les
secteurs de dmarrage principaux sauvegards, les fichiers de cartes des
secteurs, et tout autre donne qui n'est pas directement dite  la
main. Les programmes ncessaires  ce que le chargeur de dmarrage soit
capable de dmarrer sur un fichier doivent tre placs dans /sbin. Les
fichiers de configuration pour les chargeurs de dmarrage doivent tre
placs dans /etc.

Le noyau du systme d'exploitation doit tre situ soit dans /, soit
dans  /boot.

Note : sur certaines machines i386, il peut tre ncessaire que /boot
soit situ sur une partition spare situe compltement en-dessous du
cylindre 1024 du priphrique de dmarrage  cause de contraintes
matrielles.



3.3  /dev : fichiers de priphriques

Le rpertoire /dev est l'emplacement des fichiers spciaux ou de
priphriques.



                                 - 13 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



S'il est possible que des priphriques dans /dev aient besoin d'tre
crs  la main, /dev contiendra une commande nomme MAKEDEV, qui pourra
crer les priphriques au besoin. Il peut aussi disposer d'une commande
MAKEDEV.local pour tout priphrique local.

Au besoin, MAKEDEV doit avoir de quoi crer n'importe quel priphrique
qu'on pourrait trouver dans le systme, et non pas simplement ceux
qu'une implmentation particulire installe.


3.4  /etc : configuration systme spcifique  la machine

/etc contient les fichiers et les rpertoires de configuration
spcifiques au systme en cours.

Aucun binaire ne devrait tre situ dans /etc.

/etc -- configuration systme spcifique  la machine
|
+-X11       configuration pour le systme X Window
+-opt       configuration pour /opt


La section suivante sert surtout  illustrer la description du contenu
de /etc avec un certain nombre d'exemples ; ce n'est surtout pas une
liste exhaustive.


Fichiers obligatoires pour /etc :

    fichiers gnraux :

     { adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group,
       inittab, confissue, ld.so.conf, lilo.conf, motd, mtab, mtools,
       passwd, profile, securetty, shells, syslog.conf, ttytype }


    fichiers de rseau :

     { exports, ftpusers, gateways, host.conf, hosts, hosts.allow,
       hosts.deny, hosts.equiv, hosts.lpd, inetd.conf, networks,
       printcap, protocols, resolv.conf, rpc, services }

Notes :

La mise en place des scripts de commandes invoqus au dmarrage peut
ressembler aux modles System V ou BSD. Des spcifications
supplmentaires dans ce domaine pourront tre ajoutes  une version
future de la norme.

Les systmes qui utilisent la suite shadow password auront des fichiers
de configuration supplmentaires dans /etc (/etc/shadow et autres) et
des programmes dans /usr/sbin (useradd, usermod, et autres).



                                 - 14 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



3.4.1  /etc/X11 : configuration du systme X Window

/etc/X11 est l'emplacement recommand pour toute configuration X11
spcifique  la machine. Ce rpertoire est ncessaire pour permettre un
contrle local si /usr est mont en lecture seule. Les fichiers qui
devraient tre dans ce rpertoire comprennent Xconfig (et/ou XF86Config)
et Xmodmap.

Les sous-rpertoires de /etc/X11 peuvent inclure ceux pour xdm et pour
tout autre programme (certains gestionnaires de fentres, par exemple)
qui en a besoin. Nous recommandons que les gestionnaires de fentres qui
n'ont qu'un fichier de configuration par dfaut .*wmrc le nomment
system.*wmrc (sauf s'il existe un nom de rechange largement reconnu) et
n'utilisent pas de sous-rpertoire. Tout sous-rpertoire de gestionnaire
de fentres devrait tre nomm du mme nom que le binaire rel du
gestionnaire de fentres.

/etc/X11/xdm contient les fichiers de configuration de xdm. Ce sont la
plupart des fichiers que l'on trouve habituellement dans
/usr/lib/X11/xdm. Certaines donnes variables et locales pour xdm sont
stockes dans /var/state/xdm.


3.4.2  /etc/opt : fichiers de configuration pour /opt

Les fichiers de configuration spcifiques  la machine pour les paquets
des logiciels applicatifs supplmentaires seront installs dans le
rpertoire /etc/opt/<paquet>, o <paquet> est le nom du sous-rpertoire
de /opt o sont stockes les donnes statiques de ce paquet. Aucune
structure n'est impose sur la disposition interne de /etc/opt/<paquet>.

Si un fichier de configuration doit rsider dans un endroit diffrent
pour que le paquet ou le systme fonctionne correctement, on peut le
placer dans un endroit diffrent de /etc/opt/<paquet>.


Raison d'tre :

Voir la raison d'tre pour /opt.


3.5  /home : rpertoires personnels des utilisateurs (optionnel)

/home est un concept trs standard, mais c'est clairement un systme de
fichiers spcifique au site. Sa mise en place sera diffrente d'une
machine  l'autre. Cette section ne dcrit qu'un ordonnancement suggr
des rpertoires personnels des utilisateurs ; nanmoins nous
recommandons que toutes les distributions conformes  la FHS l'utilisent
comme emplacement par dfaut des rpertoires utilisateurs.

Sur les petits systmes, chaque rpertoire utilisateur est en gnral
l'un des nombreux sous-rpertoires de /home comme /home/dupont,
/home/torvalds, /home/admin, etc.



                                 - 15 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Sur des grands systmes (surtout quand les rpertoires /home sont
partags entre beaucoup d'htes par NFS) il est utile de subdiviser les
rpertoires personnels des utilisateurs. Le partage peut se faire en
utilisant des sous-rpertoires comme /home/equipe, /home/invites,
/home/eleves, etc.

D'autres personnes prfrent placer les comptes utilisateurs  divers
autres endroits. Par consquent, aucun programme ne devrait se fier 
cet emplacement. Si vous voulez trouver le rpertoire personnel d'un
utilisateur, vous devriez utiliser la fonction de bibliothque
getpwent(3) plutt que de compter sur /etc/passwd parce que les
informations sur les utilisateurs peuvent tre stockes  distance en
utilisant des systmes tels que NIS.


3.6  /lib : bibliothques partages importantes et modules du noyau


Le rpertoire /lib contient les images des bibliothques partages
ncessaires au dmarrage du systme et au lancement des commandes du
systme de fichiers racine.

/lib -- bibliothques partages importantes et modules du noyau
|
+-modules   modules chargeables du noyau


Ceci comprend /lib/libc.so.*, /lib/libm.so.*, l'diteur de liens
dynamiques partags /lib/ld.so, et d'autres bibliothques partages
ncessaires aux binaires de /bin et /sbin.

Les bibliothques partages ncessaires uniquement aux binaires de /usr
(comme n'importe quel binaire X Window) n'appartiennent pas  /lib.
Seules les bibliothques partages ncessaires au fonctionnement des
binaires de /bin et /sbin doivent se trouver ici. La bibliothque
libm.so.* peut aussi se trouver dans /usr/lib si elle n'est pas
ncessaire dans /bin ou /sbin.

Pour des raisons de compatibilit, /lib/cpp doit exister et se rfrer
au pr-processeur C install sur le systme. L'emplacement traditionnel
de ce binaire est /usr/lib/gcc-lib/<cible>/<version>/cpp. /lib/cpp peut
pointer soit vers ce binaire, soit vers toute rfrence  ce binaire qui
existe dans le systme de fichiers. (Par exemple, on utilise souvent
/usr/bin/cpp.)

La spcification pour /lib/modules est en cours d'laboration.


3.7  /mnt : point de montage pour les systmes de fichiers monts
temporairement

Ce rpertoire est fourni pour que l'administrateur systme puisse monter
de manire temporaire et au besoin des systmes de fichiers. Le contenu
de ce rpertoire est une affaire locale et ne devrait pas affecter la


                                 - 16 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



manire dont n'importe quel programme est lanc.

Nous sommes opposs  l'utilisation de ce rpertoire par les programmes
d'installation, et nous suggrons qu'un rpertoire temporaire convenable
non utilis par le systme soit utilis  la place.


3.8  /opt : paquets de logiciels applicatifs supplmentaires

/opt -- paquets de logiciels d'applications supplmentaires
|
+-<paquet>  objets statiques du paquet

/opt est rserv  l'installation de paquets de logiciels applicatifs
supplmentaires.

Un paquet qui s'installe dans /opt devra mettre ses fichiers statiques
dans une arborescence /opt/<paquet> spare, o <paquet> est un nom
dcrivant le paquet logiciel.

Les programmes devant tre lancs par les utilisateurs seront situs
dans le rpertoire /opt/<paquet>/bin. Si le paquet comprend des pages de
manuel UNIX, elle seront situes dans /opt/<paquet>/man et la mme
structure que /usr/share/man sera utilise.

Les rpertoires /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib et
/opt/man sont rservs  l'usage local de l'administrateur systme. Les
paquets peuvent fournir des fichiers de "lancement" (front-end) faits
pour qu'un administrateur systme local les place (en faisant un lien ou
en les copiant) dans ces rpertoires rservs, mais ils devront
fonctionner normalement en l'absence de ces rpertoires rservs.

Les fichiers variables d'un paquet (qui changent pendant l'utilisation
normale) devraient tre installs dans /var/opt. Voyez la section sur
/var/opt pour plus d'informations.

Les fichiers de configuration spcifiques  la machine devraient tre
installs dans /etc/opt. Voyez la section sur /etc/opt pour plus
d'informations.

Aucun autre fichier de paquet ne devrait exister en dehors des
hirarchies /opt, /var/opt et /etc/opt sauf pour les fichiers de paquet
qui doivent rsider dans des endroits spcifiques  l'intrieur de
l'arborescence du systme de fichiers afin de fonctionner correctement.
Par exemple, les fichiers de verrou des priphriques doivent tre
placs dans /var/lock et les priphriques dans /dev.


Raison d'tre

L'utilisation de /opt pour les logiciels supplmentaires est une
pratique bien tablie dans la communaut UNIX. L'interface Binaire
d'Applications (ABI) System V [AT&T 1990], base sur la Dfinition
d'Interface System V (troisime dition) fournit une structure /opt trs


                                 - 17 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



similaire  celle dcrite ici.

La Norme de Compatibilit Binaire Intel version 2 (iBCS2) fournit aussi
une structure similaire pour /opt.

En gnral, toutes les donnes ncessaires au support d'un paquet sur un
systme doivent tre prsentes dans /opt/<paquet>, y compris les
fichiers destins  tre copis dans /etc/opt/<paquet> et
/var/opt/<paquet> ainsi que dans les rpertoires rservs de /opt.


3.9  /root : rpertoire personnel de l'utilisateur root (optionnel)

/ est traditionnellement le rpertoire personnel du compte root sur les
systmes UNIX. /root est utilis sur de nombreux systmes Linux et sur
certains systmes UNIX (afin de rduire l'encombrement du rpertoire /).
Le rpertoire personnel du compte root peut tre dtermin par une
prfrence au niveau du dveloppeur ou locale. Les possibilits
videntes comprennent /, /root et /home/root.

Si le rpertoire personnel du compte root n'est pas stock sur la
partition racine il sera ncessaire de s'assurer qu'il prendra la valeur
/ par dfaut si on ne peut le trouver.

Note : nous nous opposons  l'utilisation du compte root pour des choses
simples comme le courrier lectronique ou les forums de discussion, et
recommandons qu'il ne soit utilis qu'au titre de l'administration
systme. Pour cette raison, nous recommandons que les sous-rpertoires
tels que Mail et News n'apparaissent pas dans le rpertoire personnel du
compte root, et que le courrier  destination des rles administratifs
comme root, postmaster ou webmaster soient redirigs vers un utilisateur
appropri.


3.10  /sbin : binaires systmes (qui se trouvaient autrefois dans /etc)

Les utilitaires utiliss pour l'administration systme (et autres
commandes faites uniquement pour le super-utilisateur) sont stocks dans
/sbin, /usr/sbin et /usr/local/sbin.  /sbin contient typiquement des
binaires importants au dmarrage du systme en plus des binaires de
/bin. Tout ce qui est excut aprs qu'il soit sr que /usr soit mont
(quand il n'y a pas de problmes) devrait aller dans /usr/sbin. Les
binaires d'administration systme spcifiques au systme devraient tre
installs dans /usr/local/sbin.

Dcider de ce qui va dans les rpertoires "sbin" est simple : si un
utilisateur normal (pas un administrateur systme) doit le lancer
directement, il devrait alors aller dans l'un des rpertoires "bin". Les
utilisateurs ordinaires ne devraient mettre aucun des rpertoires sbin
dans leur chemin d'accs (path).

Note : par exemple, les fichiers tels que chfn que les utilisateurs
n'utilisent que de temps en temps devraient quand mme tre placs dans
/usr/bin. ping, bien qu'il ne soit absolument ncessaire que pour root


                                 - 18 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



(remise en tat et diagnostic rseau) est souvent utilis par les
utilisateurs et pour cette raison devrait exister dans /bin.

Nous recommandons que les utilisateurs aient les permissions de lecture
et d'excution pour tout ce qui se trouve dans /sbin mis  part,
peut-tre, certains programmes setuid et setgid. La division entre /bin
et /sbin n'a pas t cre pour des raisons de scurit ou pour empcher
les utilisateurs de voir le systme d'exploitation, mais pour fournir
une bonne sparation entre les binaires que tout le monde utilise et
ceux qui sont tout d'abord utiliss pour des tches d'administration. Il
n'y a pas d'avantage spcifique pour la scurit  rendre /sbin
inaccessible aux utilisateurs.


Fichiers obligatoires pour /sbin :

    commandes gnrales :

     { clock, getty, init, update, mkswap, swapon, swapoff, telinit }


    commandes d'extinction :

     { fastboot, fasthalt, halt, reboot, shutdown }
     (ou toute combinaison des fichiers ci-dessus, pourvu que shutdown
     soit inclus.)


    commandes de gestion du systme de fichiers :

     { fdisk, fsck, fsck.*, mkfs, mkfs.* }
     * = un ou plus parmi ext, ext2, minix, msdos, xia et peut-tre
     d'autres


    commandes rseau :

     { ifconfig, route }


3.11  /tmp : fichiers temporaires

Le rpertoire /tmp devra re mis  la disposition des programmes qui ont
besoin de crer des fichiers temporaires.

Bien que les donnes stockes dans /tmp puissent tre effaces d'une
manire spcifique  chaque site, il est recommand que les fichiers et
rpertoires situs dans /tmp soient effacs  chaque dmarrage du
systme.

Les programmes ne devront pas supposer que tout fichier ou rpertoire de
/tmp est prserv entre deux lancements de ces programmes.




                                 - 19 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Raison d'tre :

La norme IEEE P1003.2 (POSIX, partie 2) donne des obligations similaires
 la section ci-dessus.

FHS a ajout la recommandation du nettoyage de /tmp au dmarrage sur la
base de prcdents historiques et de pratique commune, mais n'en a pas
fait une obligation parce que l'administration systme n'entre pas dans
l'objectif de cette norme.















































                                 - 20 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



4.  La hirarchie /usr

/usr est la deuxime grande partie du systme de fichiers.  /usr
contient des donnes partageables, en lecture seule. Ceci veut dire
qu'on devrait pouvoir partager /usr entre plusieurs machines diffrentes
se conformant  la FHS et on ne devrait pas y crire. Toute information
spcifique  la machine ou qui varie avec le temps est stocke autre
part.

Aucun grand paquet logiciel ne devrait utiliser un sous-rpertoire
direct sous la hirarchie /usr. Exception est faite du systme X Window
 cause d'un norme prcdent et d'une pratique largement suivie.  Cette
section de la norme spcifie l'emplacement de la plupart de ces paquets.

/usr -- hirarchie secondaire
|
+-X11R6     systme X Window, version 11 release 6
+-X386      systme X Window, version 11 release 5 sur des plates-formes x86
+-bin       la plupart des commandes utilisateurs
+-games     binaires de jeux et d'apprentissage
+-include   fichiers d'en-ttes inclus par les programmes C
+-lib       bibliothques
+-local     hirarchie locale (vide aprs l'installation principale)
+-sbin      binaires systmes non importants
+-share     donnes indpendantes de l'architecture
+-src       code source


Les liens symboliques vers les rpertoires suivants peuvent exister.
Cette possibilit est base sur le besoin de prserver la compatibilit
avec les vieux systmes jusqu' ce qu'on soit sr que toutes les
implmentations utilisent la hirarchie /var.

    /usr/spool -> /var/spool
    /usr/tmp -> /var/tmp
    /usr/spool/locks -> /var/lock

Une fois qu'un systme n'a plus besoin de l'un des liens symboliques ci-
dessus, le lien peut tre enlev si dsir.

















                                 - 21 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



4.1  /usr/X11R6 : systme X Window, version 11 release 6

Cette hirarchie est rserve au systme X Window, version 11 release 6,
et aux fichiers apparents.

Pour simplifier les choses et rendre XFree86 plus compatible avec le
systme X Window sur les autres systmes, les liens symboliques suivants
doivent tre prsents :

    /usr/bin/X11 -> /usr/X11R6/bin
    /usr/lib/X11 -> /usr/X11R6/lib/X11
    /usr/include/X11 -> /usr/X11R6/include/X11

En gnral, les logiciels ne devraient pas tre installs ou grs par
l'intermdiaire de ces liens symboliques. Ils ne sont destins qu' une
utilisation par les utilisateurs. La difficult est lie  la version de
sortie du systme X Window -- dans les priodes de transition, il est
impossible de savoir quelle version de X11 est en cours d'utilisation.

Les donnes spcifiques  la machine dans /usr/X11R6/lib/X11 devraient
tre considres comme des fichiers de dmonstration. Les applications
ayant besoin d'informations sur la machine courante (grce  des
fichiers comme Xconfig, XF86Config ou system.twmrc) doivent se rfrer 
un fichier de configuration dans /etc/X11, qui peut tre un lien vers un
fichier de /usr/X11R6/lib.


4.2  /usr/X386 : systme X Window, version 11 release 5, sur les plates-
formes x86

Cette hirarchie est en gnral identique  /usr/X11R6 ; les liens
symboliques de /usr pour X11 devraient pointer vers la version du
systme X Window dsire.


4.3  /usr/bin : la plupart des commandes utilisateurs

Voici le rpertoire principal des commandes excutables sur le systme.

/usr/bin -- binaires non ncessaires en mode utilisateur unique
|
+-mh        commandes pour le systme de gestion de courrier MH
+-X11       lien symbolique vers /usr/X11R6/bin


Les interprteurs de scripts shell (qu'on lance avec #!<chemin> sur la
premire ligne d'un script shell) ne pouvant pas compter sur un chemin,
il est avantageux de normaliser leur emplacement. Les interprteurs du
shell de Bourne et du shell C sont dj fixs dans /bin, mais on trouve
souvent Perl, Python et Tcl dans maints endroits diffrents.
/usr/bin/perl, /usr/bin/python et /usr/bin/tcl devraient faire rfrence
respectivement aux interprteurs de shell perl, python et tcl. Il peut y
avoir des liens symboliques vers l'emplacement vritable des
interprteurs shell.


                                 - 22 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



4.4  /usr/include : rpertoire pour les fichiers d'en-ttes standards.

Voici l'endroit o tous les fichiers d'en-ttes  usage gnral pour les
langages de programmation C et C++ devraient tre placs.

/usr/include -- fichiers d'en-ttes
|
+-X11       lien symbolique vers /usr/X11R6/include/X11
+-bsd       fichiers d'en-ttes de compatibilit BSD (si ncessaire)
+-g++       fichiers d'en-ttes pour le GNU C++



4.5  /usr/lib : bibliothques pour la programmation et les paquets

/usr/lib contient des fichiers objets, des bibliothques et des binaires
internes qui ne sont pas destins  tre excuts directement par les
utilisateurs ou les scripts shell.

Les applications peuvent utiliser un sous-rpertoire unique sous
/usr/lib. Si une application utilise un sous-rpertoire, toutes les
donnes dpendantes de l'architecture utilises exclusivement par cette
application devraient tre places dans ce sous-rpertoire. Par exemple,
le sous-rpertoire perl5 pour les modules et les bibliothques de Perl
5.

Les fichiers et rpertoires divers, statiques, indpendants de
l'architecure et spcifiques  une application devraient aller dans
/usr/share.

Certaines commandes excutables telles que makewhatis et sendmail ont
aussi t places de manire traditionnelle dans /usr/lib. makewhatis
est un binaire interne et devrait tre plac dans un rpertoire de
binaires ; les utilisateurs n'utilisent que catman. Les nouveaux
binaires sendmail sont maintenant placs par dfaut dans /usr/sbin ; un
lien symbolique devrait rester depuis /usr/lib. En plus, les systmes
qui utilisent Smail devraient placer Smail dans /usr/sbin/smail et
/usr/sbin/sendmail devrait tre un lien symbolique vers celui-ci.

Un lien symbolique /usr/lib/X11 pointant vers le rpertoire lib/X11 de
la distribution X par dfaut est ncessaire si X est install.

Note : aucune donne spcifique  la machine pour le systme X Window ne
devrait tre stock dans /usr/lib/X11. Les fichiers de configuration
spcifiques  la machine tels que Xconfig ou XF86Config devraient se
trouver dans /etc/X11. Ceci devrait comprendre les donnes de
configuration tels que system.twmrc mme si l'on n'en fait qu'un lien
symbolique vers un fichier de configuration plus global (probablement
dans /usr/X11R6/lib/X11).







                                 - 23 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



4.6  /usr/local : hirarchie locale

La hirarchie /usr/local est destine  l'usage de l'administrateur
systme quand il installe des logiciels localement. Il doit tre mis 
l'abri de tout crasement lors de la mise  jour du logiciel systme. On
peut l'utiliser pour des programmes et des donnes qu'on peut partager
parmi un groupe de machines, mais qu'on ne trouve pas dans /usr.

/usr/local -- hirarchie locale
|
+-bin       binaires locaux
+-games     binaires de jeux locaux
+-include   fichiers d'en-ttes C locaux
+-lib       bibliothques locales
+-sbin      binaires systme locaux
+-share     hirarchie indpendante de la machine locale
+-src       code source local


Ce rpertoire devrait toujours tre vide aprs la premire installation
d'un systme se conformant  la FHS. Aucune exception  cette rgle ne
devrait tre faite  part les morceaux de rpertoires lists.

Un logiciel install localement devrait tre plac dans /usr/local
plutt que dans /usr sauf si on l'installe pour remplacer ou mettre 
jour un logiciel de /usr.

Notez que les logiciels placs dans / ou /usr peuvent tre crass par
les mises  jour systmes (bien que nous recommandons que les
distributions n'crasent pas les donnes de /etc dans ces
circonstances). Pour cette raison, les logiciels locaux ne devraient pas
se trouver en dehors de /usr/local sans une bonne raison.


4.7  /usr/sbin : binaires systmes normaux non importants

Ce rpertoire contient tous les binaires non importants utiliss
exclusivement par l'administrateur systme. Les programmes
d'administration systme ncessaires  la rparation du systme, sa
remise en route, le montage de /usr ou d'autres fonctions importantes
devraient plutt tre placs dans /sbin.

Typiquement, /usr/sbin contient les dmons rseau, tous les outils
d'administration non importants et les binaires pour les programmes
serveurs non critiques.

Ces programmes serveurs sont utiliss pendant le passage  l'tat System
V connu sous le nom de "run level 2" (niveau d'excution, tat multi-
utilisateurs) et "run level 3" (niveau d'excution, tat en rseau) ou
dans l'tat BSD connu sous le nom de "mode multi-utilisateurs".  ce
point, le systme met certains services  la disposition des
utilisateurs (par exemple, les impressions) et  d'autres machines (par
exemple, l'exportation NFS).



                                 - 24 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Les programmes d'administration systme installs en local devraient se
trouver dans /usr/local/sbin.


4.8  /usr/share : donnes indpendantes de l'architecture


/usr/share -- donnes indpendantes de l'architecture
|
+-dict      listes de mots
+-doc       documentations diverses
+-games     fichiers de donnes statiques pour /usr/games
+-info      rpertoire principal du systme Info de GNU
+-locale    informations pour Locale
+-man       pages de manuel en ligne
+-nls       support pour la langue natale
+-misc      donnes diverses indpendantes de la machine
+-terminfo  rpertoires pour la base de donnes terminfo
+-tmac      macros troff non distribues avec groff
+-zoneinfo  information et configuration pour le fuseau horaire


La hirarchie /usr/share contient tous les fichiers de donnes
indpendantes de l'architecture en lecture seule. La plupart de ces
donnes se trouvaient  l'origine dans /usr (man, doc) ou /usr/lib
(dict, terminfo, zoneinfo). Cette hirarchie est destine  tre
partage entre toutes les plates-formes et architectures d'un systme
d'exploitation donn ; ainsi, par exemple, un site avec des plates-
formes i386, Alpha et PPC peut maintenir un seul rpertoire /usr/share
mont de manire centrale. Notez, cependant, que /usr/share n'est en
gnral pas fait pour tre partag par des systmes d'exploitation
diffrents ou par diffrentes versions du mme systme d'exploitation.

Tout programme ou paquet qui contient ou ncessite des donnes ne
ncessitant pas de modification devrait stocker ces donnes dans
/usr/share (ou /usr/local/share en cas d'installation locale). Il est
recommand d'utiliser un sous-rpertoire de /usr/share  cet effet.

Notez que Linux utilise pour le moment des fichiers de bases de donnes
au format DBM. Bien que ceux-ci ne soient pas indpendants de
l'architecture, ils sont autoriss dans /usr/share en anticipation d'un
passage au format DB 2.0 indpendant de l'architecture. (NdT : il semble
que la plupart des distributions aient maintenant -- janvier 2000 --
inclus le format DB 2.0.)

Les donnes de jeux stockes dans /usr/share/games devraient tre des
donnes purement statiques. Tout fichier modifiable, comme les fichiers
de scores, les enregistrements de parties et ainsi de suite, devraient
se trouver dans /var/games.

Il est recommand que les rpertoire spcifiques  une application,
indpendants de l'architecture soient placs ici. De tels rpertoires
comprennent groff, perl, ghostscript, texmf et kbd (Linux) ou syscons
(BSD). On peut, cependant, les placer dans /usr/lib pour des raisons de


                                 - 25 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



compatibilit ascendante,  la discrtion du distributeur. De mme, on
peut utiliser une hirarchie /usr/lib/games en plus de la hirarchie
/usr/share/games si le distributeur dsire placer quelques donnes de
jeux  cet endroit.



4.8.1  /usr/share/dict : listes de mots


Fichiers recommands pour /usr/share/dict :

{ words }

Traditionnellement, ce rpertoire ne contient que le fichier anglais
words, utilis par look(1) et divers programmes de correction
orthographique. words peut utiliser l'orthographe amricaine ou
britannique. Les sites qui veulent les deux peuvent faire un lien words
vers /usr/share/dict/american-english ou
/usr/share/dict/british-english.

On peut ajouter des listes de mots pour d'autres langues en utilisant le
nom anglais de cette langue, par exemple /usr/share/dict/french,
/usr/share/dict/danish, etc. Ils devraient, si possible, utiliser un jeu
de caractres ISO 8859 appropri  la langue en question ; si possible
en utilisant le jeu de caractres Latin1 (ISO 8859-1) -- ce n'est
souvent pas possible.

D'autres listes de mots, comme le "dictionnaire" web2 devraient y tre
inclus, s'ils existent.


Raison d'tre :

La raison pour laquelle seules les listes de mots sont situes ici est
que ce sont les seuls fichiers communs  tous les correcteurs
d'orthographe.


4.8.2  /usr/share/man : pages de manuel

Cette section parcourt en dtail l'organisation des pages de manuel pour
le systme entier, en incluant /usr/share/man. Reportez-vous aussi  la
section sur /var/cache/man.

Les pages de manuel sont stockes dans
<manrep>/<locale>/man<section>/<arch>. <manrep>, <locale>, <section> et
<arch> sont expliqus ci-dessous.








                                 - 26 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



<manrep>/<locale> -- hirarchie de pages de manuel
|
+-man1      programmes utilisateurs
+-man2      appels systme
+-man3      appels de bibliothque
+-man4      fichiers spciaux
+-man5      formats de fichiers
+-man6      jeux
+-man7      divers
+-man8      administration systme

Le <manrep> principal du systme est /usr/share/man.  /usr/share/man
contient des informations du manuel pour les commandes et les donnes
des systmes de fichiers / et /usr. videmment, il n'y a pas de pages de
manuel dans / parce qu'elles ne sont pas utiles au dmarrage, ni dans
les situations d'urgence.

La <section> dcrit la section du manuel.

Il faut s'assurer de faire de la place dans la structure de
/usr/share/man pour supporter les pages de manuel crites en des langues
diffrentes (ou multiples). Cette place doit prendre en compte le
stockage et la rfrence  ces pages de manuel. Les facteurs pertinents
comprennent la langue (avec les diffrences gographiques), et le codage
des caractres.

Le nommage des sous-rpertoires spcifiques  la langue dans
/usr/share/man est bas sur l'annexe E de la norme POSIX 1003.1 qui
dcrit la chane d'identification locale -- la mthode la mieux accepte
pour dcrire un environnement culturel. La chane <locale> est :


     <langue>[_<territoire>][.<code_caractre>][,<version>]

Le champ <langue> sera tir d'ISO 639 (un code de reprsentation des
noms de langues). Il sera constitu de deux caractres et spcifi en
lettres minuscules uniquement.

Le champ <territoire> sera le code  deux lettres d'ISO 3166
(spcification des reprsentations de pays) si possible. (La plupart des
personnes sont familires avec les codes  deux lettres utiliss pour
les codes de pays des adresses lectroniques1.) Il sera constitu de
deux caractres spcifis en lettres majuscules uniquement.

Le champ <code_caractre> devrait reprsenter la norme dcrivant le code
de caractres. Si le champ <code_caractre> est une simple indication
numrique, le nombre reprsente le numro de la norme internationale
dcrivant le code de caractres. Il est recommand que ce soit une
reprsentation numrique si possible (surtout pour les normes ISO),
qu'il n'inclue pas de symboles de ponctuation supplmentaires et que

____________________

1. Une  exception majeure  cette rgle est le Royaume-Uni, qui est `GB'
   dans ISO 3166, mais `UK' pour la plupart des adresses  lectroniques.

                                 - 27 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



toute lettre soit en minuscule.

Un paramtre spcifiant la <version> du profil peut tre plac aprs le
champ <code_caractre>, spar par une virgule. Ceci peut servir 
diffrencier plusieurs besoins culturels ; par exemple, l'ordre du
dictionnaire compar  un ordre d'assemblage plus orient systme. Cette
norme recommande de ne pas utiliser le champ <version>, sauf si c'est
ncessaire.

Les systmes utilisant une langue et un code de caractres uniques pour
toutes les pages de manuel peuvent omettre la sous-chane <locale> et
stocker toutes les pages de manuel dans <manrep>. Par exemple, les
systmes qui n'ont que les pages de manuel en anglais codes en ASCII
peuvent stocker ces pages (les rpertoires man<section>) directement
dans /usr/share/man. (Ce qui reprsente, en fait, la disposition et les
circonstances habituelles.)

Les pays pour lesquels existe un ensemble de codes de caractres
standard bien accept peuvent omettre le champ <code_caractre>, mais il
est fortement recommand de l'inclure, surtout pour les pays ayant
plusieurs normes en comptition.

Quelques exemples :


langue     territoire    code de caractre   rpertoire
------------------------------------------------------------------------
Anglais    --            ASCII               /usr/share/man/en
Anglais    Royaume Uni   ASCII               /usr/share/man/en_GB
Anglais    tats-Unis    ASCII               /usr/share/man/en_US
Franais   Canada        ISO 8859-1          /usr/share/man/fr_CA
Franais   France        ISO 8859-1          /usr/share/man/fr_FR
Allemand   Allemagne     ISO 646             /usr/share/man/de_DE.646
Allemand   Allemagne     ISO 6937            /usr/share/man/de_DE.6937
Allemand   Allemagne     ISO 8859-1          /usr/share/man/de_DE.88591
Allemand   Suisse        ISO 646             /usr/share/man/de_CH.646
Japonais   Japon         JIS                 /usr/share/man/ja_JP.jis
Japonais   Japon         SJIS                /usr/share/man/ja_JP.sjis
Japonais   Japon         UJIS (ou EUC-J)     /usr/share/man/ja_JP.ujis

De mme, il faut faire de la place pour les pages de manuel dpendant de
l'architecture, comme la documentation sur les pilotes de priphriques
ou les commandes d'administration systme de bas niveau. Elles devraient
tre places dans un rpertoire <arch> dans le rpertoire man<section>
appropri ; par exemple, une page de manuel pour la commande i386
ctrlaltdel(8) peut tre place dans
/usr/share/man/<locale>/man8/i386/ctrlaltdel.8.

Les pages de manuel pour les commandes et les donnes de /usr/local sont
stockes dans /usr/local/man. Les pages de manuel pour X11R6 sont
stockes dans /usr/X11R6/man. Il s'ensuit que toutes les hirarchies de
pages de manuel du systme devraient avoir la mme structure que
/usr/share/man. Les rpertoires vides peuvent tre exclus d'une
hirarchie de pages de manuel. Par exemple, si /usr/local/man n'a pas de


                                 - 28 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



page de manuel pour la section 4 (priphriques), alors on peut omettre
/usr/local/man/man4.

Les sections de pages cat (cat<section>) contenant des entres de pages
de manuel formates se trouvent aussi dans les sous-rpertoires de
<manrep>/<locale>, mais ne sont pas obligatoires ni ne devraient tre
distribues  la place des pages de manuel en source nroff.

Les sections numrotes "1"  "8" sont dfinies de manire
traditionnelle. En gnral, le nom de fichier des pages de manuel
situes dans une section particulire se termine par .<section>.

De plus, certains grands ensembles de pages de manuel spcifiques  une
application possdent un suffixe supplmentaire accol au nom de fichier
de la page de manuel. Par exemple, les pages de manuel du systme de
gestion de courrier MH devraient avoir mh accol  toutes les pages de
manuel de MH. Toutes les pages de manuel du systme X Window devraient
avoir un x accol au nom de fichier.

La pratique de placer les pages de manuel de diverses langues dans les
sous-rpertoires appropris de /usr/share/man s'applique aussi aux
autres hirarchies de pages de manuel, comme /usr/local/man et
/usr/X11R6/man. (Cette partie de la norme s'appliquera aussi plus loin
dans la section sur la structure optionnelle /var/cache/man.)

Voici une description de chaque section :


    man1 : programmes utilisateurs
     Les pages de manuel dcrivant les commandes accessibles  tous se
     trouvent dans ce chapitre. La majeure partie de la documentation
     sur les programmes dont aura jamais besoin un utilisateur se trouve
     ici.

    man2 : appels systme
     Cette section dcrit tous les appels systmes (requtes au noyau
     pour effectuer des oprations).

    man3 : fonctions et routines de la bibliothque
     La section 3 dcrit les routines de bibliothque des programmes qui
     ne sont pas des appels directs aux services du noyau. Ceci ainsi
     que le chapitre 2 n'intressent vraiment que les programmeurs.

    man4 : fichiers spciaux
     La section 4 dcrit les fichiers spciaux, les fonctions
     spcifiques aux pilotes et le support rseau disponible sur le
     systme. On y trouve typiquement les fichiers de priphriques de
     /dev et l'interface noyau pour le support des protocoles rseau.

    man5 : formats de fichiers
     Le format de nombreux fichiers de donnes non intuitifs est
     document dans la section 5. Ceci comprend divers fichiers d'en-
     ttes, les fichiers de rsultats de programmes et les fichiers
     systmes.


                                 - 29 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



    man6 : jeux
     Ce chapitre documente les jeux, les dmonstrations et des
     programmes en gnral triviaux. Des personnes diffrentes ont des
     notions varies sur l'opportunit de cette partie.

    man7 : divers
     Les pages de manuel difficiles  classer sont places dans la
     section 7.  Les paquets de macros pour troff et autres processeurs
     de texte se trouvent ici.

    man8 : administration systme
     La documentation pour les programmes utiliss par les
     administrateurs systme pour la bonne marche du systme et sa
     maintenance se trouve ici.  Certains de ces programmes sont aussi
     utiles de temps  autre pour les utilisateurs normaux.


4.8.3  /usr/share/misc : diverses donnes indpendantes de
l'architecture


Ce rpertoire contient divers fichiers indpendants de l'architecture
qui ne ncessitent pas un sous-rpertoire spar dans /usr/share. C'est
un rpertoire obligatoire de /usr/share.

Les fichiers suivants, s'ils sont prsents, devraient se trouver dans
/usr/share/misc :


{ ascii, magic, termcap, termcap.db }

D'autres fichiers (spcifiques  une application) peuvent apparatre
ici, mais un intgrateur peut les placer dans /usr/lib  sa discrtion.
De tels fichiers comprennent :


{ airport, birthtoken, eqnchar, getopt, gprof.callg, gprof.flat,
  inter.phone, ipfw.samp.filters, ipfw.samp.scripts, keycap.pcvt,
  mail.help, mail.tildehelp, man.template, map3270, mdoc.template,
  more.help, na.phone, nslookup.help, operator, scsi_modes, sendmail.hf,
  style, units.lib, vgrindefs, vgrindefs.db, zipcodes }


4.9  /usr/src : code source

Tout code source non local devrait tre plac dans ce sous-rpertoire.










                                 - 30 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



5.  La hirarchie /var

/var -- donnes variables
|
+-account   historique de la comptabilit des processus (si support)
+-cache     donnes de cache des applications
+-crash     donnes brutes des plantages systme (si support)
+-games     donnes variables des jeux
+-lock      fichiers de verrous
+-log       fichiers et rpertoires d'historique
+-mail      fichiers de botes aux lettres des utilisateurs
+-opt       donnes variables de /opt
+-run       fichiers relatifs aux processus en cours
+-spool     donnes en attente pour les applications
+-state     informations variables d'tat
+-tmp       fichiers temporaires prservs entre les redmarrages du systme
+-yp        fichiers de base de donnes de NIS (Network Information Service)

/var contient des fichiers de donnes variables. Ceci comprend les
rpertoires et fichiers en attente (spool), les donnes administratives
et d'historique, et les fichiers transitoires et temporaires.

Certaines parties de /var ne sont pas partageables entre des systmes
diffrents. Par exemple, /var/log, /var/lock et /var/run. D'autres
parties peuvent tre partages, comme notamment /var/mail,
/var/cache/man, /var/cache/fonts et /var/spool/news.

/var est ici spcifi afin de rendre possible le montage de /usr en
lecture seule. Tout ce qui allait auparavant dans /usr et sur lequel on
crivait pendant la marche du systme (au contraire de l'installation et
de la maintenance logicielle) doit aller dans /var.

Si on ne peut pas faire de /var une partition spare, il est souvent
prfrable de dplacer /var hors de la partition racine  l'intrieur de
la partition /usr. (On fait parfois ceci pour rduire la taille de la
partition racine ou quand l'espace se rduit dans la partition racine.)
Cependant, /var ne devrait pas tre un lien vers /usr parce que cela
rend la sparation de /usr et /var plus difficile et rend plus probable
la cration d'un conflit de noms.  la place, faites un lien de /var
vers /usr/var.

Les applications ne devraient en gnral pas ajouter de rpertoire au
niveau suprieur de /var. De tels rpertoires ne devraient tre ajouts
que s'ils concernent le systme en entier, et en consultant la liste de
diffusion FHS.

Les rpertoires cache, lock, log, run, spool, state et tmp doivent tre
inclus et utiliss dans toutes les distributions ; les rpertoires
account, crash, games, mail et yp doivent tre inclus et utiliss si les
applications ou possibilits correspondantes sont fournies dans la
distribution.

Les versions prcdentes de la FSSTND incluaient une hirarchie
/var/lib. Pour plus d'informations, voir la section sur /var/state.


                                 - 31 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Plusieurs rpertoires sont `rservs' dans le sens o une application
nouvelle ne devrait pas les utiliser de faon arbitraire, puisqu'ils
entreraient en conflit avec une pratique historique et/ou locale. Ce
sont :

    /var/backups
    /var/cron
    /var/lib
    /var/local
    /var/msgs
    /var/preserve


5.1  /var/account : historique de la comptabilit des processus (si
support)

Ce rpertoire contient l'historique en cours de la comptabilit des
processus et les donnes consolides d'utilisation des processus
(utiliss dans certains systmes de type UNIX par lastcomm et sa).


5.2  /var/cache : donnes de cache des applications

/var/cache -- rpertoires de cache
|
+-fonts     fontes gnres en local
+-man       pages de manuel formates en local
+-www       donnes de cache ou de proxy WWW
+-<paquet>  donnes de cache spcifiques  paquet


/var/cache est fait pour les donnes de cache des applications.  De
telles donnes sont gnres localement comme rsultat d'entres-sorties
ou de calculs qui prennent du temps. L'application doit tre capable de
regnrer ou de retrouver les donnes.  la diffrence de /var/spool,
les fichiers cachs peuvent tre effacs sans perte de donnes. Les
donnes doivent rester valides entre deux lancements de l'application et
aprs le redmarrage du systme.

Les fichiers situs dans /var/cache peuvent expirer d'une manire
spcifique  l'application, par l'administrateur systme ou des deux
manires. L'application devrait toujours tre capable de s'en remettre
suite  un effacement manuel des fichiers (gnralement  cause d'un
manque d'espace disque). Aucune autre obligation n'est faite concernant
le format des donnes dans les rpertoires de cache.


Raison d'tre :

L'existence d'un rpertoire spar pour les donnes de cache permet aux
administrateurs systme d'attribuer des politiques de disque et de
sauvegarde diffrentes des autres rpertoires de /var.




                                 - 32 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



5.2.1  /var/cache/fonts : fontes gnres en local


Le rpertoire /var/cache/fonts devrait re utilis pour stocker toute
fonte cre de manire dynamique. En particulier, /var/cache/fonts/pk
stockera toutes les fontes automatiquement gnres par MakeTeXPK.

Il devrait y avoir un lien de /usr/lib/texmf/fonts/tmp vers
/var/cache/fonts. Ce lien permet aux utilisateurs d'utiliser le chemin
unique /usr/lib/texmf/fonts/tfm quand ils font des modifications  leur
variable d'environnement TEXFONTS. (Ceci est le chemin par dfaut pour
les outils TeX de Karl Berry, distribus sur ftp.cs.umb.edu:/pub/tex2.
Si on utilise une autre distribution TeX, on devrait faire un lien du
rpertoire de fontes appropri vers /var/cache/fonts.)

Le MakeTeXPK distribu avec dvipsk placera les fichiers exemple,
fonts/pk/CanonCX/cmr10.300pk). Les fichiers .pk peuvent tre purgs
rgulirement de l'arborescence /var/cache/fonts ou peuvent tre
dplacs dans l'arborescence /usr/lib/texmf. Si on utilise des
gnrateurs automatiques de sous-rpertoires mf ou tfm de
/var/cache/fonts.

D'autres fontes cres dynamiquement peuvent aussi se trouver dans cette
arborescence, dans des sous-rpertoires de /var/cache/fonts nomms de
manire adquate.


5.2.2  /var/cache/man : pages de manuel formates en local (optionnel)


Ce rpertoire fournit un emplacement standard pour les sites qui
possdent une partition /usr en lecture seule, mais qui veulent
permettre le cache des pages de manuel formates en local. Les sites qui
montent /usr en criture (par exemple, les installations en utilisateur
unique) peuvent choisir de ne pas utiliser /var/cache/man et peuvent
crire les pages de manuel formates dans les rpertoires cat<section>
directement dans /usr/share/man. Nous recommandons que la plupart des
sites utilisent plutt l'une des options suivantes :


    prformater toutes les pages de manuel  ct des versions non
     formates ;

    ne permettre aucun cache des pages de manuel formates et obliger 
     refaire le formatage  chaque utilisation d'une page de manuel ;

    permettre le cache local des pages de manuel formates dans
     /var/cache/man.


____________________

2. La  raison pour laquelle les outils de Karl Berry sont mentionns est
   qu'ils sont le standard de-facto pour les installations UNIX de  TeX.
   Ces outils sont largement utiliss dans la communaut UNIX libre.

                                 - 33 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



La structure de /var/cache/man ncessite de reflter  la fois les
hirarchies multiples de pages de manuel et la possibilit d'un support
multilingue.

tant donne une page de manuel non formate qui apparat normalement
dans <chemin>/man/<locale>/man<section>, le rpertoire pour placer les
pages de manuel formates s'appelle
/var/cache/man/<chemin_cat>/<locale>/cat<section>, o <chemin_cat>
s'inspire de <chemin> en enlevant toute composante de nom de chemin usr
au dbut et/ou share  la fin. (Notez que la composante <locale> peut ne
pas tre prsente.)

Par exemple, /usr/share/man/man1/ls.1 sera formate en
/var/cache/man/cat1/ls.1 et /usr/X11R6/man/<locale>/man3/XtClass.3x en
/var/cache/man/X11R6/<locale>/cat3/XtClass.3x.

Les pages de manuel crites dans /var/cache/man peuvent  la fin tre
transfres vers les rpertoires prformats appropris dans la
hirarchie source man ou bien expirer ; de mme, les pages de manuel
formates dans la hirarchie des sources man peuvent tre expires si
personne n'y a accd pendant une certaine priode de temps.

Si les pages de manuel prformates sont distribues avec un systme sur
des supports en lecture seule (un CD-ROM, par exemple), elles seront
installes dans la hirarchie des sources man (par exemple
/usr/share/man/cat<section>). /var/cache/man est rserv comme cache
dans lequel on peut crire les pages de manuel formates.


Raison d'tre :

La version 1.2 de la norme spcifiait /var/catman pour cette hirarchie.
Le chemin a t modifi en /var/cache pour mieux reflter la nature
dynamique des pages de manuel formates. Le nom du rpertoire a t
modifi en man pour permettre l'agrandissement de la hirarchie et
inclure des formats traits autres que "cat", comme PostScript, HTML ou
DVI.


5.3  /var/crash : donnes brutes des plantages systme (si support)

Ce rpertoire contient des donnes brutes (dump) des plantages systme.
 la date de la sortie de cette norme, les donnes brutes de plantage
systme n'taient pas supportes par Linux.


5.4  /var/games : donnes variables des jeux

Toute donne variable concernant les jeux de /usr devrait tre place
ici. /var/games devrait contenir les donnes variables qu'on trouvait
auparavant dans /usr ; Les donnes statiques telles que les textes
d'aide, les descriptions de niveaux et ainsi de suite devraient rester
autre part, comme dans /usr/share/games.



                                 - 34 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Comme pour /var/state, les donnes variables des jeux peuvent tre
places dans /var/lib en tant que mesure de transition obsolte.
Cependant, cette permission sera leve dans une version future de la
norme.


Raison d'tre :

On a donn une hirarchie /var/games  part entire, plutt que de le
laisser mlang avec l'ancien /var/lib comme dans la version 1.2. La
sparation permet un contrle local des stratgies de sauvegarde,
permissions et utilisation des disques, ainsi que de permettre un
partage inter-machines et de rduire l'encombrement de /var/state. De
plus, /var/games est le chemin utilis traditionnellement par BSD.


5.5  /var/lock : fichiers de verrous

Les fichiers de verrous devraient tre stocks dans la structure de
rpertoires /var/lock.

Les fichiers de verrous de priphriques, tels les fichiers de verrous
du priphrique srie qu'on trouvait d'habitude, soit dans
/usr/spool/locks, soit dans /usr/spool/uucp doivent maintenant tre
stocks dans /var/lock. La convention de nommage  utiliser est "LCK.."
suivi du nom de base du priphrique. Par exemple, pour verrouiller
/dev/cua0 le fichier "LCK..cua0" serait cr.

Le format utilis pour les fichiers de verrous de priphrique doit tre
le format de fichier de verrou HDB UUCP. Le format HDB permet de stocker
l'identificateur du processus (PID) comme un nombre dcimal ASCII sur
dix octets, avec un signe nouvelle ligne  la fin. Par exemple, si le
processus 1230 tenait un fichier de verrou, ce dernier contiendrait les
onze caractres : espace, espace, espace, espace, espace, espace, un,
deux, trois, zro et nouvelle ligne.



5.6  /var/log : fichiers et rpertoires d'historique

Le rpertoire contient divers fichiers d'historique (log). La plupart
des historiques devraient tre crits dans ce rpertoire ou dans un
sous-rpertoire appropri.

lastlog    enregistrement du dernier login de chaque utilisateur
messages   messages systme de syslogd
wtmp       enregistrement de chaque login et logout


5.7  /var/mail : fichiers de botes aux lettres utilisateurs

Ce rpertoire contient les fichiers de botes aux lettres utilisateurs
stocks dans le format de botes aux lettres UNIX standard.



                                 - 35 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Raison d'tre :

Ce rpertoire a t relog de /var/spool/mail pour amener FHS en accord
avec la plupart des implmentations UNIX. Ce changement est important
pour l'interoprabilit puisqu'un /var/mail unique est souvent partag
entre plusieurs machines et plusieurs implmentations d'UNIX (malgr les
problmes de verrouillage NFS).


5.8  /var/opt : donnes variables de /opt

Les donnes variables devraient tre installes dans /var/opt/<paquet>,
o <paquet> est le nom de la sous-arborescence de /opt o sont stockes
les donnes statiques de tout paquet logiciel supplmentaire, sauf quand
elles sont supplantes par un autre fichier dans /etc. Aucune structure
n'est impose sur la disposition interne de /var/opt/<paquet>.


Raison d'tre :

Voir la raison d'tre pour /opt.


5.9  /var/run : fichiers variables d'excution

Ce rpertoire contient des fichiers d'information systme dcrivant le
systme depuis qu'il a dmarr. Les fichiers de ce rpertoire devraient
tre nettoys (enlevs ou tronqus selon le cas) au dbut du processus
de dmarrage.

Les fichiers d'identification de processus (PID), qui taient placs 
l'origine dans /etc, devraient tre placs dans /var/run. La convention
de nommage des fichiers PID est <nom_programme>.pid. Par exemple, le
fichier PID de crond est nomm /var/run/crond.pid.

Le format interne des fichiers PID reste inchang. Le fichier consiste
en un identificateur de processus en dcimal cod ASCII, suivi d'un
caractre nouvelle ligne. Par exemple, si crond tait le processus
numro 25, /var/run/crond.pid contiendrait trois caractres : deux, cinq
et nouvelle ligne.

Les programmes qui lisent les fichiers PID devraient tre assez souples
dans ce qu'ils acceptent ; par exemple, ils devraient ignorer les
espaces blancs supplmentaires, les zros au dbut, l'absence d'une
nouvelle ligne  la fin ou les lignes supplmentaires dans le fichier
PID. Les programmes qui crent des fichiers PID devraient utiliser la
spcification simple situe dans le paragraphe ci-dessus.

Le fichier utmp, qui stocke les informations sur qui est en train
d'utiliser le systme, est plac dans ce rpertoire.

Les programmes qui gardent des sockets du domaine UNIX temporaires
devraient les placer dans ce rpertoire.



                                 - 36 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



5.10  /var/spool : donnes en attente pour les applications

/var/spool -- rpertoires d'attente
|
+-lpd       rpertoire d'attente de l'imprimante
+-mqueue    file d'attente du courrier  l'expdition
+-news      rpertoire d'attente des news
+-rwho      fichiers rwhod
+-smail     rpertoire d'attente pour smail
+-uucp      rpertoire d'attente pour UUCP

/var/spool contient des donnes en attente d'un traitement ultrieur.
Les donnes de /var/spool reprsentent un travail  faire dans le futur
(par un programme, un utilisateur ou un administrateur) ; les donnes
sont souvent effaces aprs avoir t traites.

Les fichiers de verrou UUCP doivent tre placs dans /var/lock.  Voir la
section ci-dessus  propos de /var/lock.


5.10.1  /var/spool/lpd : file d'impression du dmon de l'imprimante
ligne
/var/spool/lpd -- rpertoire d'attente de l'imprimante
|
+-<imprimantfile d'attente d'une imprimante spcifique (optionnel)


Le fichier de verrou de lpd, lpd.lock, devrait tre plac dans
/var/spool/lpd. Nous suggrons que le fichier de verrou de chaque
imprimante soit plac dans le rpertoire d'attente spcifique  cette
imprimante et soit nomm lock.


5.10.2  /var/spool/rwho : fichiers rwhod

Ce rpertoire contient les informations rwhod d'autres systmes sur le
rseau local.


Raison d'tre :

Certaines versions de BSD utilisent /var/rwho pour ces donnes ; tant
donn leur emplacement historique dans /var/spool sur d'autres systmes
et sa convenance approximative  la dfinition de donnes `en attente',
cet emplacement a t estim plus appropri.


5.11  /var/state : informations variables d'tat








                                 - 37 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



/var/state -- informations variables d'tat
|
+-<diteur> fichiers de sauvegarde et tat d'diteurs
+-misc      diverses donnes d'tat
+-xdm       donnes variables du gestionnaire d'affichage X xdm
+-<pkgtool> fichiers d'aide au paquet
+-<paquet>  donnes d'tat pour les paquets et les sous-systmes


Cette hirarchie contient des informations d'tat se rapportant  une
application ou au systme. Les informations d'tat sont des donnes que
les programmes modifient au cours de leur excution, relatives  une
machine spcifique. Les utilisateurs ne devraient jamais avoir besoin de
modifier des fichiers dans /var/state pour configurer la bonne marche
d'un paquet.

Les informations d'tat sont utilises en gnral pour prserver
l'environnement d'une application (ou d'un groupe d'applications lies
entre elles) entre plusieurs lancements et entre plusieurs instances de
la mme application. Les informations d'tat devraient en gnral rester
valides aprs un redmarrage, ne devraient pas garder l'historique de
sortie d'un programme et ne devraient pas tre des donnes en attente.

Une application (ou un groupe d'applications lies) devrait utiliser un
sous-rpertoire de /var/state pour ses donnes. Il y a un sous-
rpertoire obligatoire, /var/state/misc, fait pour les fichiers d'tat
qui n'ont pas besoin de sous-rpertoire ; les autres sous-rpertoires ne
devraient tre prsents que si l'application en question est incluse
dans la distribution.

/var/state/<nom> est l'endroit  utiliser pour tout le support de paquet
de la distribution. Des distributions diffrentes peuvent videmment
utiliser des noms diffrents.

Les versions prcdentes de cette norme utilisaient le nom /var/lib pour
cette hirarchie. /var/lib est obsolte, mais peut tre utilis en
parallle avec la hirarchie obligatoire /var/state, comme mesure
transitoire pour les donnes spcifiques aux applications. Notez
cependant que cette permission sera retire dans une version future de
la norme. Par contre, vous pouvez faire un lien symbolique de /var/lib
vers /var/state.


Raison d'tre :

/usr/lib est de plus en plus utilis uniquement pour les fichiers objets
ou leurs archives ; ceci est vrai pour les variantes BSD UNIX actuelles
ainsi que les paquets GNU actuels. Dans le mme ordre d'ides, le nom
/var/lib semblait inappropri.

BSD utilise le nom /var/db pour un rpertoire similaire. Ce nom semblait
trop restrictif, puisqu'il impliquait une structure de rpertoires faite
tout d'abord pour les fichiers de base de donnes (.db).



                                 - 38 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



5.11.1  /var/state/<diteur> : fichiers de sauvegarde et tat d'un
diteur

Ces rpertoires contiennent des fichiers sauvegards par toute fin
inattendue d'un diteur (par exemple elvis, jove, nvi).

D'autres diteurs peuvent ne pas ncessiter de rpertoire pour les
fichiers de sauvegarde de plantage, mais peuvent ncessiter un endroit
bien dfini pour stocker d'autres informations pendant que l'diteur
fonctionne. Ces informations devraient tre stockes dans un sous-
rpertoire de /var/state (par exemple, GNU Emacs placerait ses fichiers
de verrou dans /var/state/emacs/lock).

Des diteurs futurs pourront avoir besoin d'informations d'tat
supplmentaires au-del des fichiers de sauvegarde de plantage et des
fichiers de verrou -- ces informations devraient aussi tre places dans
/var/state/<diteur>.


Raison d'tre :

Les versions prcdentes de Linux, ainsi que tous les distributeurs du
commerce, utilisaient /var/preserve pour vi et ses clones.  Cependant,
chaque diteur utilise son propre format pour ces fichiers de sauvegarde
de plantage, c'est pourquoi un rpertoire spar est ncessaire  chaque
diteur.

Les fichiers de verrous spcifiques  chaque diteur sont en gnral
assez diffrents des fichiers de verrous de priphrique ou de
ressources stocks dans /var/lock et de ce fait sont stocks dans
/var/state.


5.11.2  /var/state/misc : diverses donnes variables

Ce rpertoire contient des donnes variables qui ne sont pas places
dans un sous-rpertoire de /var/state. Il serait judicieux d'utiliser
dans la mesure du possible des noms uniques dans ce rpertoire pour
viter les conflits de noms.

Notez que cette hirarchie devrait contenir les fichiers de /var/db des
versions actuelles de BSD. Celles-ci comprennent locate.database et
mountdtab, et la (les) base(s) de donnes des symboles du noyau.


5.12  /var/tmp : fichiers temporaires prservs entre les redmarrages
du systme

Le rpertoire /var/tmp est mis  la disposition des programmes qui ont
besoin de fichiers ou de rpertoires temporaires prservs entre les
redmarrages du systme. Par consquent, les donnes stockes dans
/var/tmp restent plus longtemps que les donnes de /tmp.

Les fichiers et rpertoires situs dans /var/tmp ne doivent pas tre


                                 - 39 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



effacs quand le systme dmarre. Bien que les donnes stockes dans
/var/tmp soient typiquement effaces d'une manire spcifique au site,
il est recommand que l'effacement se fasse dans un intervalle plus long
que pour /tmp.



5.13  /var/yp : fichiers de base de donnes NIS (Network Information
Service)

Les donnes variables du Service d'Information Rseau (NIS ou Network
Information Service), qu'on appelait auparavant Pages Jaunes Sun (YP ou
Sun Yellow Pages), seront places dans ce rpertoire.


Raison d'tre :

/var/yp est le rpertoire normal des donnes NIS (YP) et est utilis
presque exclusivement dans la documentation et les systmes NIS.

Il ne faut pas confondre NIS et Sun NIS+, qui utilise un rpertoire
diffrent, /var/nis.


































                                 - 40 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



6.  Annexe spcifique aux systmes d'exploitation

Cette section contient des obligations et recommandations
supplmentaires qui ne s'appliquent qu' un systme d'exploitation
spcifique. Les principes de cette section ne devraient jamais entrer en
conflit avec la norme de base.


6.1  Linux

Voici l'annexe pour le systme d'exploitation Linux.


6.1.1  / : rpertoire racine

Sur les systmes Linux, si le noyau est situ dans /, nous recommandons
d'utiliser les noms vmlinux ou vmlinuz, qui sont utiliss dans les
paquets rcents de sources du noyau Linux.


6.1.2  /dev : fichiers de priphriques et fichiers spciaux

Tous les fichiers de priphriques et fichiers spciaux de /dev
devraient se conformer au document Linux Allocated Devices
(priphriques allous dans Linux), que l'on trouve dans les sources du
noyau Linux. Il est maintenu par H. Peter Anvin <hpa@zytor.com>.

Les liens symboliques de /dev ne devraient pas tre distribus avec des
systmes Linux sauf s'ils sont fournis dans le document Linux Allocated
Devices.


Raison d'tre :

L'obligation de ne pas faire de liens symboliques au hasard est donne
parce que la configuration locale diffre souvent de celle de la machine
de dveloppement du distributeur. De plus, si un script d'installation
de distribution configure les liens symboliques au moment de
l'installation, ces liens symboliques ne seront souvent pas mis  jour
si des changements locaux ont lieu sur le matriel. De manire
responsable et  un niveau local, cependant, on peut les utiliser  bon
escient.


6.1.3  /proc : systme de fichiers virtuel d'informations sur le noyau
et les processus

Le systme de fichiers proc devient la mthode standard de-facto sur
Linux pour manipuler les processus et les informations du systme,
plutt que par /dev/kmem et autres mthodes similaires. Nous
encourageons fortement ce principe pour le stockage et l'obtention
d'informations sur les processus ainsi que d'autres informations sur le
noyau et la mmoire.



                                 - 41 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



6.1.4  /sbin : binaires systmes importants

Les systmes Linux placent ces fichiers supplmentaires dans /sbin :


    commandes du systme de fichiers tendu deuxime version (ext2 --
     optionnel) :

     { badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs }


    installateur de carte du chargeur de dmarrage :

     { lilo }


Fichiers optionnels de /sbin :

    binaires statiques :

     { ldconfig, sln, ssync }

     Les binaires statiques ln (sln) et sync (ssync) sont utiles quand
     quelque chose va mal. L'utilisation principale de sln (pour rparer
     les liens symboliques incorrects dans /lib aprs une mise  jour
     mal faite) n'est plus d'une importance cruciale maintenant que le
     programme ldconfig (situ gnralement dans /usr/sbin) existe et
     peut agir comme guide pendant la mise  jour des bibliothques.
     sync en statique est utile dans certaines situations d'urgence.
     Notez qu'ils ne doivent pas forcment tre des versions lies en
     statique des commandes normales ln et sync, mais elle peuvent
     l'tre.

     Le binaire ldconfig est optionnel dans /sbin puisqu'un site peut
     choisir de lancer ldconfig au dmarrage plutt qu' la mise  jour
     des bibliothques partages. (Il n'est pas clair qu'il soit
     avantageux de lancer ldconfig  chaque dmarrage.) Mme ainsi,
     certaines personnes aiment avoir ldconfig  porte de clavier pour
     les situations suivantes (toutes trop frquentes) :


         (1) je viens d'enlever /lib/<fichier> ;

         (2) je ne peux pas trouver le nom de la bibliothque parce que
             ls est li en dynamique, j'utilise un shell qui n'a pas ls
             intgr et je ne sais pas utiliser "echo *"  la place ;

         (3) j'ai un sln en statique, mais je ne sais pas comment nommer
             le lien.

    divers :

     { ctrlaltdel, kbdrate }



                                 - 42 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



     Pour pallier au fait que certains claviers sont livrs avec une
     frquence de rptition si grande qu'ils en sont inutilisables,
     kbdrate peut tre install dans /sbin sur certains systmes.

     Puisque l'action par dfaut dans le noyau pour la combinaison de
     touches Ctrl-Alt-Del est un redmarrage brutal instantan, il est
     recommandable de dsactiver ce comportement avant de monter le
     systme de fichiers racine en mode lecture/criture. Certaines
     versions d'init sont capables de dsactiver Ctrl-Alt-Del, mais
     d'autres ncessitent le programme ctrlaltdel qui peut tre install
     dans /sbin sur ces systmes.



6.1.5  /usr/include : fichiers d'en-tte inclus par les programmes C

Les liens symboliques suivants sont ncessaires si un compilateur C ou
C++ est install.

    /usr/include/asm -> /usr/src/linux/include/asm-<arch>
    /usr/include/linux -> /usr/src/linux/include/linux


6.1.6  /usr/src : code source

Le seul code source qui doit tre plac dans un endroit spcifique est
le code source du noyau Linux. Il est situ dans /usr/src/linux.

Si un compilateur C ou C++ est install, mais que le code source complet
du noyau Linux n'est pas install, les fichiers d'en-tte du code source
du noyau devront tre situs dans ces rpertoires :

    /usr/src/linux/include/asm-<arch>
    /usr/src/linux/include/linux

<arch> est le nom de l'architecture du systme.

Note : /usr/src/linux peut tre un lien symbolique vers l'arborescence
relle du code source du noyau.



Raison d'tre :

Il est important que les fichiers d'en-ttes du noyau soient situs dans
/usr/src/linux et non dans /usr/include pour qu'il n'y ait pas de
problemes quand les administrateurs systme mettent  jour la version du
noyau pour la premire fois.


6.1.7  /var/spool/cron : travaux cron et at


Ce rpertoire contient les donnes variables pour les programmes cron et


                                 - 43 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



at.























































                                 - 44 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



La liste de diffusion FHS  La liste de diffusion FHS est situe  <fhs-
discuss@ucsd.edu>. Pour vous abonner  la liste envoyez un courrier 
<listserv@ucsd.edu> avec dans le corps du message "ADD fhs-discuss".

Merci au service rseau de l'universit de Californie  San Diego qui
nous a autoriss  utiliser leur super serveur de listes de
distribution.

Comme il est indiqu dans l'introduction, veuillez ne pas envoyer de
courrier  la liste de diffusion sans d'abord contacter l'diteur de la
FHS ou un contributeur list.


Remerciements


Les dveloppeurs de la FHS souhaitent remercier les dveloppeurs,
administrateurs systme et utilisateurs dont l'avis a t essentiel 
cette norme. Nous souhaitons remercier chacun des contributeurs qui ont
aid  crire, compiler et composer cette norme.

Le groupe FHS souhaite aussi remercier les dveloppeurs Linux qui ont
support la FSSTND, prdcesseur de cette norme. S'ils n'avaient pas
dmontr le bnfice apport par la FSSTND, la FHS n'aurait jamais pu
voluer.


Contributeurs

Brandon S. Allbery                                                       <bsa@kf8nh.wariat.org>
Keith Bostic                                                             <bostic@cs.berkeley.edu>
Drew Eckhardt                                                            <drew@colorado.edu>
Rik Faith                                                                <faith@cs.unc.edu>
Stephen Harris                                                           <sweh@spuddy.mew.co.uk>
Ian Jackson                                                              <ijackson@cus.cam.ac.uk>
John A. Martin                                                           <jmartin@acm.org>
Ian McCloghrie                                                           <ian@ucsd.edu>
Chris Metcalf                                                            <metcalf@lcs.mit.edu>
Ian Murdock                                                              <imurdock@debian.org>
David C. Niemi                                                           <niemidc@clark.net>
Daniel Quinlan                                                           <quinlan@pathname.com>
Eric S. Raymond                                                          <esr@thyrsus.com>
Mike Sangrey                                                             <mike@sojurn.lns.pa.us>
David H. Silber                                                          <dhs@glowworm.firefly.com>
Theodore Ts'o                                                            <tytso@athena.mit.edu>
Stephen Tweedie                                                          <sct@dcs.ed.ac.uk>
Fred N. van Kempen                                                       <waltje@infomagic.com>


Traduction :
La traduction franaise a t ralise par Olivier Tharan,
<olive@minet.net>. Tous les commentaires sont accepts. La relecture a
t effectue le 16/01/2000.



                                 - 45 -









                                CONTENTS



1. Introduction ...................................................... 1
   1.1  tat de la norme ............................................. 1
   1.2  Organisation de la norme ..................................... 1
   1.3  Conventions .................................................. 1
   1.4  Historique de la FHS ......................................... 3
   1.5  tendue ...................................................... 3
   1.6  Indications gnrales ........................................ 4
   1.7  Audience vise ............................................... 4
   1.8  Conformit avec ce document .................................. 5

2. Le systme de fichiers ............................................ 7

3. Le rpertoire racine ............................................. 10
   3.1  /bin : binaires de commandes utilisateurs importantes (pour
        tous les utilisateurs) ...................................... 11
   3.2  /boot : fichiers statiques du chargeur de dmarrage ......... 13
   3.3  /dev : fichiers de priphriques ............................ 13
   3.4  /etc : configuration systme spcifique  la machine ........ 14
   3.5  /home : rpertoires personnels des utilisateurs (optionnel) . 15
   3.6  /lib : bibliothques partages importantes et modules du
        noyau ....................................................... 16
   3.7  /mnt : point de montage pour les systmes de fichiers monts
        temporairement .............................................. 16
   3.8  /opt : paquets de logiciels applicatifs supplmentaires ..... 17
   3.9  /root : rpertoire personnel de l'utilisateur root
        (optionnel) ................................................. 18
   3.10 /sbin : binaires systmes (qui se trouvaient autrefois dans
        /etc) ....................................................... 18
   3.11 /tmp : fichiers temporaires ................................. 19

4. La hirarchie /usr ............................................... 21
   4.1  /usr/X11R6 : systme X Window, version 11 release 6 ......... 22
   4.2  /usr/X386 : systme X Window, version 11 release 5, sur les
        plates-formes x86 ........................................... 22
   4.3  /usr/bin : la plupart des commandes utilisateurs ............ 22
   4.4  /usr/include : rpertoire pour les fichiers d'en-ttes
        standards. .................................................. 23
   4.5  /usr/lib : bibliothques pour la programmation et les
        paquets ..................................................... 23
   4.6  /usr/local : hirarchie locale .............................. 24
   4.7  /usr/sbin : binaires systmes normaux non importants ........ 24
   4.8  /usr/share : donnes indpendantes de l'architecture ........ 25
   4.9  /usr/src : code source ...................................... 30

5. La hirarchie /var ............................................... 31
   5.1  /var/account : historique de la comptabilit des processus
        (si support) ............................................... 32
   5.2  /var/cache : donnes de cache des applications .............. 32
   5.3  /var/crash : donnes brutes des plantages systme (si
        support)


                                    i









                  ................................................... 34
   5.4  /var/games : donnes variables des jeux ..................... 34
   5.5  /var/lock : fichiers de verrous ............................. 35
   5.6  /var/log : fichiers et rpertoires d'historique ............. 35
   5.7  /var/mail : fichiers de botes aux lettres utilisateurs ..... 35
   5.8  /var/opt : donnes variables de /opt ........................ 36
   5.9  /var/run : fichiers variables d'excution ................... 36
   5.10 /var/spool : donnes en attente pour les applications ....... 37
   5.11 /var/state : informations variables d'tat .................. 37
   5.12 /var/tmp : fichiers temporaires prservs entre les
        redmarrages du systme ..................................... 39
   5.13 /var/yp : fichiers de base de donnes NIS (Network
        Information Service) ........................................ 40

6. Annexe spcifique aux systmes d'exploitation .................... 41
   6.1  Linux ....................................................... 41








































                                   ii


