









       Norme de hrarchie du sysme 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 sont faites pour faciliter l'interoprabilit des
     applications, des outils d'administration systme, des outils
     de dveloppement et des scripts, ainsi qu'une documentation
     plus uniforme entre ces systmes.



February 1, 1998








































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 changements devraient tre
faites sous la forme d'une proposition de changement du texte,
accompagne des commentaires d'explication appropris.

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



1.2  Organisation de la norme

Cette norme est divise entre ces sections :


  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
fichier>[.<extension>].


                                  - 1 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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 volontaires qui ont contribu activement  cette norme se trouvent
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 spcifiant 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 paquetages 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 incluant 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, 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 changement devraient tre adresss
l'diteur de la FHS (Daniel Quinlan <quinlan@pathname.com>), ou si vous
prfrez,  la liste de distribution 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 distribution afin d'viter un
nouveau dbat sur des sujets anciens. Les messages mal conus ne seront
pas bien vus sur la liste de distribution.

Des questions concernant l'interprtation des objets de ce documents
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 beaucoup de 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  Suggestions gnrales

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


    Rsoudre des problmes techniques en limitant les difficults lies
      la transition.

    Faire une spcification relativement 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 paquetage (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  sa description. L'implmentation doit
aussi tenter de trouver tout fichier ou rpertoire (extrieur  lui-
mme) au premier abord 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 variations soient tolres 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 explication brve de la raison de cette
diffrence. Cette liste sera fournie avec l'implmentation en question,
et aussi mise  disposition de la liste de distribution 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 au 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 particulire d'un systme UNIX.
Cependant, beaucoup d'aspects de cette norme sont bases 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

    Des normes applicables

Il est possible de dfinir deux catgories orthogonales de fichiers :
partageables contre non partageables, et variables contre statiques.

Les donnes partageables sont ce qui peut tre partag entre plusieurs
machines diffrentes ; non partageables est ce qui doit tre spcifique
 une machine particulire. Par exemple, les rpertoires personnels des
utilisateurs sont des donnes partageables, mais pas les fichiers de
blocage de priphriques (locks).

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 sont 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), il y a une bonne partie des donnes qui peuvent tre
     partages entre les diffrentes machines pour sauver 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" peut tre utilise pour 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 voudrions le monter en
     lecture seule (voir ci-dessus), il est ncessaire de fournir une
     mthode pour avoir /usr mont_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-ecriture, 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 root 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
     essentielles. /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
penchent pour 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 le systme de fichiers racine sur une
     grande partition, et pouvez le remplir _votre aise, il y aura des
     gens avec des partition 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 pouvez
     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 sont un problme plus important que les erreurs sur


                                 - 10 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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


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 essentielles
+-boot      Fichiers statiques du chargeur de dmarrage
+-dev       Fichiers de ripriques
+-etc       Configuration systme spcifique  la machine
+-home      pertoires personnels des utilisateurs
+-lib       Bibliothques partages essentielles et modules du noyau
+-mnt       Point de montage des partitions temporaires
+-opt       Paquetages d'applications logicielles supplmentaires
+-root      pertoire personnel de l'utilisateur root
+-sbin      Binaires systmes essentiels
+-tmp       Fichiers temporaires
+-usr       Hirarchie secondaire
+-var       Dones variables


Chaque pertoire listci-dessus est scifien tail dans des sous-
sections paes ci-dessous. /usr et /var ont chacun une section
compte dans ce document cause de la complexitde ces pertoires.

L'image du noyau du sysme d'exploitation doittre situsoit dans /
soit dans /boot. Les informations suppmentaires sur l'emplacement du
noyau se trouvent dans la section concernant /boot ci-dessous.


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

/bin contient des commandes qui peuvent tre utilises _la fois par
l'administrateur systme et les 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 essentielles
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 pas assez essentiels pour tre placs dans la
partition racine.



Fichiers obligatoires pour /bin :

    Commandes gnrales :

     Les commandes suivantes ont t incluses parce qu'elles sont
     essentielles. 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 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 avec /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 avec 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
     les composants de remise en tat minimaux. 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 faire aucune remise en tat de la partition
     racine, ces binaires peuvent alors tre omis (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.

S'il est possible que des priphriques dans /dev aient besoin d'tre


                                 - 13 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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 sysme 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 pour le 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 pour 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
paquetages des logiciels d'application supplmentaires seront installs
dans le rpertoire /etc/opt/<paquetage>, o_<paquetage> est le nom du
sous-rpertoire de /opt o_les donnes statiques de ce paquetage sont
stockes. Aucune structure n'est impose sur la disposition interne de
/etc/opt/<paquetage>.

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


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 endroit. 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 pour lancer les 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.*, lditeur de liens
dynamiques partas /lib/ld.so, et d'autres bibliothques partages
ncessaires pour les binaires de /bin et /sbin.

Les bibliothques partages ncessaires uniquement aux binaires de /usr
(comme n'importe quel binaire pour X Window) n'appartiennent pas /lib.
Seules les bibliothques partages ncessaires au fonctionnement des
binaires de /bin et /sbin devraient 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 rer
au p-processeur C installsur le sysme. L'emplacement traditionnel
de ce binaire est /usr/lib/gcc-lib/<cible>/<version>/cpp. /lib/cpp peut
soit pointer vers ce binaire, soit vers toute rence ce binaire qui
existe dans le sysme de fichiers. (Par exemple, /usr/bin/cpp est de
mme souvent utilis.)

La spcification pour /lib/modules est en cours dlaboration.


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

Ce rpertoire est install 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


                                 - 16 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



affecter la 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 : paquetages de logiciels d'applications supplmentaires

/opt -- paquetages de logiciels d'applications supplmentaires
|
+-<paquetageobjets de paquetage statiques

/opt est rserv  l'installation de paquetages de logiciels
d'application supplmentaires.

Un paquetage qui doit tre install dans /opt devra mettre ses fichiers
statiques dans une arborescence /opt/<paquetage> spare, o <paquetage>
est un nom crivant le paquetage logiciel.

Les programmes devanttre lans par les utilisateurs seront sits
dans le pertoire /opt/<paquetage>/bin. Si le paquetage comprend des
pages de manuel UNIX, elle seront situes dans /opt/<paquetage>/man et
la me 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 de l'administrateur systme local.
Les paquetages 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 de paquetage variables (qui changent avec un usage normal)
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 paquetage ne devrait exister en dehors des
hirarchies /opt, /var/opt et /etc/opt sauf pour les fichiers de
paquetage qui doivent sider dans des endroits scifiques
l'inrieur de l'arborescence du sysme de fichiers afin de fonctionner
correctement. Par exemple, les fichiers de bloquage des ripriques
doiventtre plas 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 paquetage sur
un systme doivent tre prsentes dans /opt/<paquetage>, y compris les
fichiers destins  tre copis dans /etc/opt/<paquetage> et
/var/opt/<paquetage> ainsi que dans les rpertoires rservs de /opt.


3.9  /root : rpertoire personnel pour 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 globale 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 nouvelles, 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 root) sont stocks dans /sbin,
/usr/sbin et /usr/local/sbin. /sbin contient typiquement des binaires
essentiels 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
(remise en tat et diagnostic rseau) est souvent utilis_par les


                                 - 18 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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 diverses se conformant _
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 paquetage 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
paquetages.

/usr -- hirarchie secondaire
|
+-X11R6     Sysme X Window, version 11 release 6
+-X386      Systme X Window, version 11 release 5 sur des plate-formes x86
+-bin       La plupart des commandes utilisateurs
+-games     Binaires de jeux et d'apprentissage
+-include   Fichiers d'en-tes inclus par les programmes C
+-lib       Bibliothques
+-local     Hrarchie locale (vide aps l'installation principale)
+-sbin      Binaires systmes non essentiels
+-share     Dones inpendantes de l'architecture
+-src       Code source


Les liens symboliques vers les rpertoires suivants peuvent tre
prsents. 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
devraient 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 prises 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 plate-
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 sysme de gestion de courrier MH
+-X11       Lien symbolique vers /usr/X11R6/bin


Les interpteurs 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 difrents.
/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 ritable des
interpteurs 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-tes de compatibilitBSD (si cessaire)
+-g++       fichiers d'en-ttes pour le GNU C++



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

/usr/lib contient des fichiers objets, des bibliothques et des binaires
internes qui ne sont pas destins _tre excuts 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 accdent uniquement  catman. Les nouveaux
binaires sendmail sont maintenant placs par dfaut dans /usr/sbin ; un
lien symbolique devrait rester de /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
exister 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'utilisation de
l'administrateur systme quand il installe des logiciels en local. Il
doit tre mis _l'abri de tout effacement 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-tes C locaux
+-lib       Bibliothques locales
+-sbin      Binaires sysme locaux
+-share     Hirarchie indpendante de la machine locale
+-src       Code source local


Ce pertoire devrait toujourstre vide aps la premre installation
d'un sysme se conformant la FHS. Aucune exception cette gle ne
devraittre faite part les morceaux de pertoires liss.

Les logiciels instals localement devraienttre plas 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
aller en dehors de /usr/local sans bonne raison.


4.7  /usr/sbin : binaires systmes normaux non essentiels

Ce rpertoire contient tous les binaires non essentiels 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 essentielles
devraient plutt tre placs dans /sbin.

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

Ces programmes serveurs sont utiliss _l'entre dans l'tat System V
connu sous le nom de "run level 2" (tat multi-utilisateurs) et "run
level 3" (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, les exports NFS).



                                 - 24 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



Les programmes d'administration systme installs en local devraient
tre placs 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 dones statiques pour /usr/games
+-info      pertoire principal du sysme Info de GNU
+-locale    Informations pour Locale
+-man       Pages de manuel en ligne
+-nls       Support pour la langue natale
+-misc      Dones diverses inpendantes de la machine
+-terminfo  Rpertoires pour la base de donnes terminfo
+-tmac      Macros troff non distribes avec groff
+-zoneinfo  Information et configuration pour le fuseau horaire


La hirarchie /usr/share contient tous les fichiers de dones
inpendantes de l'architecture en lecture seule. La plupart de ces
dones se trouvaient l'origine dans /usr (man, doc) ou /usr/lib
(dict, terminfo, zoneinfo). Cette hirarchie est destine  tre
partage entre toutes les plate-formes et architectures pour un systme
d'exploitation donn ; ainsi, par exemple, un site avec des plate-formes
i386, Alpha et PPC peut maintenir un seul rpertoire /usr/share qui est
montde manre 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 paquetage qui contient ou ncessite des donnes qui
n'ont pas besoin d'tre modifies 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 dones
au format DBM. Bien que ceux-ci ne soient pas inpendants de
l'architecture, ils sont autoris dans /usr/share en anticipation d'un
passage au format DB 2.0 indpendant de l'architecture.

Les donnes de jeux stockes dans /usr/share/games devraienttre des
dones purement statiques. Tout fichier modifiable, comme les fichiers
de scores, les enregistrements de parties et ainsi de suite, devraient
tre plas 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). Ils peuvent, cependant, tre placs dans /usr/lib pour des
raisons de compatibilitascendante, la disction du distributeur. De
me, une hrarchie /usr/lib/games peut tre utilise en plus de la


                                 - 25 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



hirarchie /usr/share/games si le distributeur sire placer quelques
dones 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 dtails 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 bibliotque
+-man4      Fichiers spciaux
+-man5      Formats de fichiers
+-man6      Jeux
+-man7      Divers
+-man8      Administration systme

Le <manrep> principal du sysme est /usr/share/man. /usr/share/man
contient des informations du manuel pour les commandes et les dones
des sysmes 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> crit 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 bassur l'annexe E de la norme POSIX 1003.1 qui
crit la chne d'identification locale -- la thode la mieux accepe
pour crire un environnement culturel. La chne <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
(scification des repsentations de pays) si possible. (La plupart des
personnes sont familres avec les codes deux lettres utilies pour
les codes de pays des adresseslectroniques.1) Il sera constitude
deux caracres scifs en lettres majuscules uniquement.

Le champ <code_caracre> devrait reprsenter la norme dcrivant le code
de caractres. Si le champ <code_caractre> est une simple indication
nurique, le nombre repsente le nuro de la norme internationale
crivant le code de caracres. Il est recommandque ce soit une
repsentation nurique si possible (surtout pour les normes ISO),
qu'il n'inclue pas de symboles de ponctuation suppmentaires 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 paratre scifiant la <version> du profil peut tre plac aprs le
champ <code_caractre>, parpar une virgule. Ceci peut servir
difrencier plusieurs besoins culturels ; par exemple, l'ordre du
dictionnaire comparun ordre d'assemblage plus orientsysmes.
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 un ensemble de codes de caractres standard bien
accept existe peuvent omettre le champ <code_caractre>, mais il est
fortement recommandde l'inclure, surtout pour les pays ayant plusieurs
normes en comtition.

Quelques exemples :


Langue     Territoire    Code de caracre   pertoire
------------------------------------------------------------------------
Anglais    --            ASCII               /usr/share/man/en
Anglais    Royaume Uni   ASCII               /usr/share/man/en_GB
Anglais   tats-Unis    ASCII               /usr/share/man/en_US
Fraais   Canada        ISO 8859-1          /usr/share/man/fr_CA
Fraais   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 me, il faut faire de la place pour les pages de manuel pendant de
l'architecture, comme la documentation sur les pilotes de ripriques
ou les commandes d'administration sysme de bas niveau. Elles devraient
tre plaes dans un pertoire <arch> dans le pertoire man<section>
appropri; par exemple, une page de manuel pour la commande i386
ctrlaltdel(8) peuttre plae dans
/usr/share/man/<locale>/man8/i386/ctrlaltdel.8.

Les pages de manuel pour les commandes et les dones de /usr/local sont
stoces dans /usr/local/man. Les pages de manuel pour X11R6 sont
stoces dans /usr/X11R6/man. Il s'ensuit que toutes les hrarchies de
pages de manuel du sysme devraient avoir la me structure que
/usr/share/man. Les pertoires vides peuventtre oubls d'une
hrarchie 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



pages de manuel pour la section 4 (ripriques), alors
/usr/local/man/man4 peuttre omis.

Les sections de pages cat (cat<section>) contenant des entes de pages
de manuel formaes se trouvent aussi dans les sous-pertoires de
<manrep>/<locale>, mais ne sont pas obligatoires ni ne devraienttre
distribes la place des pages de manuel en source nroff.


Les sections nuroes "1" "8" sont finies de manre
traditionnelle. En ral, le nom de fichier des pages de manuel
sites dans une section particulre se termine par .<section>.

De plus, certains grands ensembles de pages de manuel scifiques une
application posdent un suffixe suppmentaire accolau nom de fichier
de la page de manuel. Par exemple, les pages de manuel du sysme de
gestion de courrier MH devraient avoir mh accoltoutes les pages de
manuel de MH. Toutes les pages de manuel du sysme X Window devraient
avoir un x accolau nom de fichier.

La pratique de placer les pages de manuel de diverses langues dans les
sous-pertoires approprs de /usr/share/man s'applique aussi aux
autres hrarchies 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 crivant 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 sysme
     Cette section crit tous les appels sysmes (reqtes au noyau
     pour effectuer des orations).

   man3 : fonctions et routines de la bibliotque
     La section 3 crit les routines du programme de la bibliotque
     qui ne sont pas des appels directs aux services du noyau. Ceci
     ainsi que le chapitre 2 ne sont vraiment inressants que pour les
     programmeurs.

   man4 : fichiers sciaux
     La section 4 crit les fichiers sciaux, les fonctions
     scifiques aux pilotes et le support seau disponible sur le
     sysme. On y trouve typiquement les fichiers de ripriques de
     /dev et l'interface noyau pour le support des protocoles seau.

   man5 : formats de fichiers
     Le format de nombreux fichiers de dones non intuitifs est
     documentdans la section 5. Ceci comprend divers fichiers d'en-


                                 - 29 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



     tes, les fichiers de sultats de programmes et les fichiers
     sysmes.

   man6 : jeux
     Ce chapitre documente les jeux, les monstrations et des
     programmes en ral triviaux. Des personnes difrentes ont des
     notions vares sur l'opportunitde cette partie.

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

   man8 : administration sysme
     La documentation pour les programmes utilis par les
     administrateurs sysme pour la bonne marche du sysme 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 comptabilitdes processus (si suppor)
+-cache     Donnes de cache des applications
+-crash     Dones brutes des plantages sysme (si suppor)
+-games     Donnes variables des jeux
+-lock      Fichiers de verrous
+-log       Fichiers et rpertoires d'historique
+-mail      Fichiers de btes aux lettres utilisateurs
+-opt       Donnes variables de /opt
+-run       Fichiers relatifs aux processus en cours
+-spool     Donnes en attente pour les applications
+-state     Informations variables dtat
+-tmp       Fichiers temporaires prservs entre les redmarrages du systme
+-yp        fichiers de base de dones de NIS (Network Information Service)

/var contient des fichiers de donnes variables. Ceci inclut 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 sysmes
difrents. 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 scifiafin de rendre possible le montage de /usr en
lecture seule. Tout ce qui allait auparavant dans /usr sur lequel on
crivait pendant la marche du sysme (au contraire de l'installation et
de la maintenance logicielle) doit aller dans /var.

Si on ne peut pas faire de /var une partition pae, il est souvent
prable de placer /var hors de la partition racine  l'intrieur de
la partition /usr. (Ceci est parfois effectupour duire la taille de
la partition racine ou quand l'espace se duit dans la partition
racine.) Cependant, /var ne devrait pas tre un lien vers /usr parce que
cela rend la paration de /usr et /var plus difficile et rend plus
probable la cation d'un conflit de noms. la place, faites un lien de
/var vers /usr/var.

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

Les rpertoires cache, lock, log, run, spool, state et tmp doiventtre
inclus et utilis dans toutes les distributions ; les pertoires
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 ils ne devraient
pas tre utiliss de faon arbitraire par une application nouvelle,
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 composes d'utilisation des processus (utiliss
dans certains systme UNIX par lastcomm et sa).


5.2  /var/cache : donnes de cache des applications

/var/cache -- rpertoires de cache
|
+-fonts     fontes es en local
+-man       pages de manuel formates en local
+-www       dones de cache ou de proxy WWW
+-<paquetagedonnes de cache spcifiques  paquetage


/var/cache est fait pour les dones de cache des applications. De
telles dones sont es localement comme sultat d'entes-sorties
ou de calculs qui prennent du temps. L'application doittre capable de
rerer ou de retrouver les dones. la difrence 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 une politique de disque et de
sauvegarde diffrente 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 effectuent des changements
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/tex.2

Si une autre distribution TeX est utilise, un lien du rpertoire de
fontes appropri_vers /var/cache/fonts devrait tre fait.)

Le MakeTeXPK distribu_avec dvipsk placera les fichiers .pk dans
fonts/pk/<priphrique>/<nom_fonte> (par exemple,
fonts/pk/CanonCX/cmr10.300pk). Les fichiers .pk peuvent tre
priodiquement purgs de l'arborescence /var/cache/fonts ou peuvent tre
dplacs dans l'arborescence /usr/lib/texmf. Si des gnrateurs
automatiques de .mf ou .tfm sont utiliss, ils devraient placer leurs
donnes dans les sous-rpertoires mf ou tfm de /var/cache/fonts.

D'autres fontes cres dynamiquement peuvent aussi tre places 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
fournissent 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 expires ; De mme, les pages de manuel
formates dans la hirarchie source 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 source 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_chang_en /var/cache pour mieux reflter la nature
dynamique des pages de manuel formates. Le nom du rpertoire a t
chang 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 supports 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, il contiendrait les onze
caractres : espace, espace, espace, espace, espace, espace, un, deux,
trois, zro et nouvelle ligne.

programme a cr le verrou (uucp, cu ou getty).  Alors, tout ce qui
voudrait utiliser /dev/cua0 peut lire le fichier de verrou et agir en
consquence (tous les verrous de /var/lock devraient tre lisibles par
tout le monde).


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





                                 - 35 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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.


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/<paquetage>, o_<paquetage> est le nom de la sous-arborescence
de /opt o_les donnes statiques de tout paquetage logiciel
supplmentaire sont stockes, sauf quand elles sont supplantes par un
autre fichier dans /etc. Aucune structure n'est impose sur la
disposition interne de /var/opt/<paquetage>.


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.


                                 - 36 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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.


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

/var/spool -- Rpertoires d'attente
|
+-lpd       pertoire d'attente de l'imprimante
+-mqueue    File d'attente du courrier  l'expdition
+-news      pertoire d'attente des news
+-rwho      Fichiers rwhod
+-smail     pertoire d'attente pour smail
+-uucp      Rpertoire d'attente pour UUCP

/var/spool contient des dones en attente d'un traitement ulrieur.
Les dones 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 daemon de l'imprimante
ligne
/var/spool/lpd -- Rpertoire d'attente de l'imprimante
|
+-<imprimantFile d'attente d'une imprimante scifique (optionnel)


Le fichier de verrou de lpd, lpd.lock, devraittre placdans
/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 : fichier 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.




                                 - 37 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



5.11  /var/state : informations variables d'tat


/var/state -- Informations variables d'tat
|
+-<diteur> Fichiers de sauvegarde ettat dditeurs
+-misc      Diverses donnes d'tat
+-xdm       Dones variables du gestionnaire d'affichage X xdm
+-<pkgtool> Fichiers d'aide au paquetage
+-<paquetageDones dtat pour les paquetages et les sous-sysmes


Cette hrarchie contient des informations dtat se rapportant une
application ou au sysme. Les informations dtat sont des dones que
les programmes modifient au cours de leur ecution, relatives une
machine scifique. Les utilisateurs ne devraient jamais avoir besoin de
modifier des fichiers dans /var/state pour configurer la bonne marche
d'un paquetage.

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 dones. Il y a un sous-
pertoire 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
paquetage de la distribution. Des distributions difrentes peuvent
videmment utiliser des noms difrents.

Les versions pdentes de cette norme utilisaient le nom /var/lib pour
cette hirarchie. /var/lib est obsote, mais peuttre utilisen
paralle avec la hrarchie 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 paquetages 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


                                 - 38 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



trop restrictif, puisqu'il impliquait une structure de rpertoires faite
tout d'abord pour les fichiers de base de donnes (.db).


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


                                 - 39 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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
effaces 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
paquetages 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. Utiliss de manire
responsable  un niveau local, cependant, on peut les utiliser  bon
escient.


6.1.3  /proc : systme de fichiers virtuel d'information 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 un 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 essentiels

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

         (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
             appeler le lien.

   _Divers :

     { ctrlaltdel, kbdrate }

     Pour pallier au fait que certains claviers sont livrs avec une
     frquence de rptition si grande qu'ils en sont inutilisables,


                                 - 42 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



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






                                 - 43 -





Norme de hirarchie du systme de fichiers              1er fvrier 1998



La liste de distribution FHS  La liste de distribution 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 _Network Operations _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 distribution 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>


Traducteurs :
La traduction franaise a t ralise par Olivier Tharan,
<tharan@int-evry.fr>. Tous les commentaires sont accepts.







                                 - 44 -









                                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  Suggestions 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 essentielles (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 : paquetages de logiciels d'applications
        supplmentaires ............................................. 17
   3.9  /root : rpertoire personnel pour 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
        plate-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
        paquetages .................................................. 23
   4.6  /usr/local : hirarchie locale .............................. 24
   4.7  /usr/sbin : binaires systmes normaux non essentiels ........ 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


                                    i









        /var/crash : donnes brutes des plantages systme (si
        support) ................................................... 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 ..... 36
   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 .................. 38
   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


