









              Norme de hirarchie du systme de fichiers -- Version 2.0

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


                                       ABSTRACT

                 Cette norme consiste en un ensemble d'exigences et de
            suggestions concernant la disposition des fichiers et des
            rpertoires dans un systme d'exploitation de type UNIX. Les
            suggestions 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.



       April 17, 2003








































       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.


                                        - ii -





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

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


                                         - 3 -





       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
       suivis est la compatibilit ascendante entre une version de ce document


                                         - 4 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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

           Dveloppeurs d'applications

           Auteurs de documentations



                                         - 5 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



           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.

       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


                                         - 6 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.










































                                         - 7 -





       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 :


                                         - 8 -





       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.








                                         - 9 -





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















































                                        - 10 -





       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


                                        - 11 -





       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 priphriques
       +-etc       Configuration systme spcifique  la machine
       +-home      Rpertoires 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      Rpertoire personnel de l'utilisateur root
       +-sbin      Binaires systmes essentiels
       +-tmp       Fichiers temporaires
       +-usr       Hirarchie secondaire
       +-var       Donnes variables


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

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

       3.1  /bin : binaires de commandes utilisateurs 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.

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


                                        - 12 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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) }

            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


                                        - 13 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



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


                                        - 14 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       qu'on pourrait trouver dans le systme, et non pas simplement ceux
       qu'une implmentation particulire installe.

       3.4  /etc : configuration systme spcifique  la machine

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

       Aucun binaire ne devrait tre situ dans /etc.

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


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

       Fichiers obligatoires pour /etc :

           Fichiers gnraux :

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


           Fichiers de rseau :

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

       Notes :

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

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


       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.


                                        - 15 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.

       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


                                        - 16 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.*, l'diteur de liens
       dynamiques partags /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 rfrer
       au pr-processeur C install sur le systme. L'emplacement traditionnel
       de ce binaire est /usr/lib/gcc-lib/<cible>/<version>/cpp. /lib/cpp peut
       soit pointer vers ce binaire, soit vers toute rfrence  ce binaire qui
       existe dans le systme de fichiers. (Par exemple, /usr/bin/cpp est de
       mme souvent utilis.)

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

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

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



                                        - 17 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       /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 dcrivant le paquetage logiciel.

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

       Les rpertoires /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
       et /opt/man sont rservs  l'usage 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 rsider dans des endroits spcifiques 
       l'intrieur de l'arborescence du systme de fichiers afin de fonctionner
       correctement. Par exemple, les fichiers de bloquage des priphriques
       doivent tre placs dans /var/lock et les priphriques dans /dev.

       Raison d'tre

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


                                        - 18 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



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



                                        - 19 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



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

       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     Systme 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-ttes inclus par les programmes C
       +-lib       Bibliothques
       +-local     Hirarchie locale (vide aprs l'installation principale)
       +-sbin      Binaires systmes non essentiels
       +-share     Donnes indpendantes 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 systme de gestion de courrier MH
       +-X11       Lien symbolique vers /usr/X11R6/bin


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




                                        - 22 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



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

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

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


       4.5  /usr/lib : bibliothques pour la programmation et les 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).


       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


                                        - 23 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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-ttes C locaux
       +-lib       Bibliothques locales
       +-sbin      Binaires systme locaux
       +-share     Hirarchie indpendante de la machine locale
       +-src       Code source local


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

       Les logiciels installs localement devraient tre placs 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).

       Les programmes d'administration systme installs en local devraient
       tre placs dans /usr/local/sbin.

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



                                        - 24 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       /usr/share -- Donnes indpendantes de l'architecture
       |
       +-dict      Listes de mots
       +-doc       Documentations diverses
       +-games     Fichiers de donnes statiques pour /usr/games
       +-info      Rpertoire principal du systme Info de GNU
       +-locale    Informations pour Locale
       +-man       Pages de manuel en ligne
       +-nls       Support pour la langue natale
       +-misc      Donnes diverses indpendantes de la machine
       +-terminfo  Rpertoires pour la base de donnes terminfo
       +-tmac      Macros troff non distribues avec groff
       +-zoneinfo  Information et configuration pour le fuseau horaire


       La hirarchie /usr/share contient tous les fichiers de donnes
       indpendantes de l'architecture en lecture seule. La plupart de ces
       donnes se trouvaient  l'origine dans /usr (man, doc) ou /usr/lib
       (dict, terminfo, zoneinfo). Cette hirarchie est destine  tre
       partage entre toutes les 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
       mont de manire centrale. Notez, cependant, que /usr/share n'est en
       gnral pas fait pour tre partag par des systmes d'exploitation
       diffrents ou par diffrentes versions du mme systme d'exploitation.

       Tout programme ou 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 donnes
       au format DBM. Bien que ceux-ci ne soient pas indpendants de
       l'architecture, ils sont autoriss dans /usr/share en anticipation d'un
       passage au format DB 2.0 indpendant de l'architecture.

       Les donnes de jeux stockes dans /usr/share/games devraient tre des
       donnes purement statiques. Tout fichier modifiable, comme les fichiers
       de scores, les enregistrements de parties et ainsi de suite, devraient
       tre placs 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 compatibilit ascendante,  la discrtion du distributeur. De
       mme, une hirarchie /usr/lib/games peut tre utilise en plus de la
       hirarchie /usr/share/games si le distributeur dsire placer quelques
       donnes de jeux  cet endroit.


       4.8.1  /usr/share/dict : listes de mots




                                        - 25 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.

       <manrep>/<locale> -- Hirarchie de pages de manuel
       |
       +-man1      Programmes utilisateurs
       +-man2      Appels systme
       +-man3      Appels de bibliothque
       +-man4      Fichiers spciaux
       +-man5      Formats de fichiers
       +-man6      Jeux
       +-man7      Divers
       +-man8      Administration systme

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



                                        - 26 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       La <section> dcrit la section du manuel.

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

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


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

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

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

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

       Un paramtre spcifiant la <version> du profil peut tre plac aprs le
       champ <code_caractre>, spar par une virgule. Ceci peut servir 
       diffrencier plusieurs besoins culturels ; par exemple, l'ordre du
       dictionnaire compar  un ordre d'assemblage plus orient systmes.
       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.)


       ____________________

       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



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

       Quelques exemples :


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

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

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

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


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

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


                                        - 28 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       manuel de MH. Toutes les pages de manuel du systme X Window devraient
       avoir un x accol au nom de fichier.

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

       Voici une description de chaque section :


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

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

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

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

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

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

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

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


                                        - 29 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



            utiles de temps  autre pour les utilisateurs normaux.

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

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


       { ascii, magic, termcap, termcap.db }

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


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

       4.9  /usr/src : code source

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





























                                        - 30 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       5.  La hirarchie /var

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

       /var contient des fichiers de donnes variables. Ceci 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 systmes
       diffrents. Par exemple, /var/log, /var/lock et /var/run. D'autres
       parties peuvent tre partages, comme notamment /var/mail,
       /var/cache/man, /var/cache/fonts et /var/spool/news.

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

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

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

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

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


                                        - 31 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       Plusieurs rpertoires sont `rservs' dans le sens o 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 gnres en local
       +-man       pages de manuel formates en local
       +-www       donnes de cache ou de proxy WWW
       +-<paquetagedonnes de cache spcifiques  paquetage


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

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

       Raison d'tre :

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

       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.


                                        - 32 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.

       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

       ____________________

       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



       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.

       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


                                        - 34 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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

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




                                        - 35 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.

       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











                                        - 36 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



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

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

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

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


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

       5.10.2  /var/spool/rwho : 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.

       5.11  /var/state : informations variables d'tat


       /var/state -- Informations variables d'tat
       |
       +-<diteur> Fichiers de sauvegarde et tat d'diteurs
       +-misc      Diverses donnes d'tat
       +-xdm       Donnes variables du gestionnaire d'affichage X xdm
       +-<pkgtool> Fichiers d'aide au paquetage
       +-<paquetageDonnes d'tat pour les paquetages et les sous-systmes


       Cette hirarchie contient des informations d'tat se rapportant  une


                                        - 37 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       application ou au systme. Les informations d'tat sont des donnes que
       les programmes modifient au cours de leur excution, relatives  une
       machine spcifique. Les utilisateurs ne devraient jamais avoir besoin de
       modifier des fichiers dans /var/state pour configurer la bonne marche
       d'un 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 donnes. Il y a un sous-
       rpertoire obligatoire, /var/state/misc, fait pour les fichiers d'tat
       qui n'ont pas besoin de sous-rpertoire ; les autres sous-rpertoires ne
       devraient tre prsents que si l'application en question est incluse
       dans la distribution.

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

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

       Raison d'tre :

       /usr/lib est de plus en plus utilis uniquement pour les fichiers objets
       ou leurs archives ; ceci est vrai pour les variantes BSD UNIX actuelles
       ainsi que les 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
       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


                                        - 38 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       de verrou dans /var/state/emacs/lock).

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

       Raison d'tre :

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

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

       5.11.2  /var/state/misc : diverses donnes variables

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

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

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

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

       Les fichiers et rpertoires situs dans /var/tmp ne doivent pas tre
       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.




                                        - 39 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



       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.

       6.1.4  /sbin : binaires systmes essentiels

       Les systmes Linux placent ces fichiers supplmentaires dans /sbin.




                                        - 41 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



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


                                        - 42 -





       Norme de hirarchie du systme de fichiers              1er fvrier 1998



            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 ....................................... 2
           1.5   tendue .................................................... 2
           1.6   Suggestions gnrales ...................................... 3
           1.7   Audience vise ............................................. 3
           1.8   Conformit avec ce document ................................ 4

       2.  Le systme de fichiers ........................................... 6

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

       4.  La hirarchie /usr .............................................. 19
           4.1   /usr/X11R6 : Systme X Window, Version 11 Release 6 ....... 20
           4.2   /usr/X386 : systme X Window, Version 11 Release 5, sur
                 les plate-formes x86 ...................................... 20
           4.3   /usr/bin : la plupart des commandes utilisateurs .......... 20
           4.4   /usr/include : rpertoire pour les fichiers d'en-ttes
                 standards. ................................................ 21
           4.5   /usr/lib : bibliothques pour la programmation et les
                 paquetages ................................................ 21
           4.6   /usr/local : hirarchie locale ............................ 21
           4.7   /usr/sbin : binaires systmes normaux non essentiels ...... 22
           4.8   /usr/share : donnes indpendantes de l'architecture ...... 22
           4.9   /usr/src : code source .................................... 28

       5.  La hirarchie /var .............................................. 29
           5.1   /var/account : historique de la comptabilit des processus
                 (si support) ............................................. 30



                                           i









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

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






































                                          ii


