fhs-2.0.fr-nroff/ 40750 764 764 0 6631326621 11373 5 ustar nat nat fhs-2.0.fr-nroff/draft.mm 100640 764 764 311227 6465123240 13167 0 ustar nat nat .\" Norme de hiérarchie du système de fichiers 2.0 -*- nroff -*-
.ig
Time-stamp: <97/10/26 01:18:57 quinlan>
Copyright (C) 1994, 1995, 1996, 1997 Daniel Quinlan
Voir ci-dessous (sous "Partie légale") pour les conditions complètes de
copie.
Ce document est mis en page avec GNU groff 1.10 et les macros mm, et
pré-traité avec pic et tbl. Le site web de la FHS est situé à
.
Notes pour écrire ce document avec troff :
* Utilisez toutes les chaînes définies avec la commande ".ds".
* Les noms de fichiers doivent être mis en page en police de taille
constante, mais n'incluez pas la ponctuation, par exemple
\f(CWfichier\fP.
* Les noms de fichiers contenant des tirets doivent être précédés de
\%, par exemple \f(CW\%/pub/liste-fichiers\fP.
* Utilisez la langue décrite dans la section "Conformité".
..
.\" -------------------------------------------------------------------
.\" Chaînes prédéfinies
.\" -------------------------------------------------------------------
.ds Date 1er février 1998
.ds Fs FHS
.ds Ux UNIX
.ie n .ds Tx TeX
.el .ds Tx T\h'-.2m'\v'+.3m'E\h'-.0m'\v'-.3m'X
.\" -------------------------------------------------------------------
.\" Mise en page du document
.\" -------------------------------------------------------------------
.nr Cl 2
.nr Hu 3
.nr Hy 0
.PGNH
.PH "'Norme de hiérarchie du système de fichiers''\*[Date]"
.SA 0
.ie t \{\
.PGFORM 6i 10.5i 1.25i
.ds HF B B B B B B B
.ds HP 14 12 12 10 10 10 10
\}
.el \{\
.PGFORM 7.2i 11i
\}
.\" -------------------------------------------------------------------
.\" Page de couverture
.\" -------------------------------------------------------------------
.COVER ms
.TL
Norme de hiérarchie du système de fichiers \(em Version 2.0
.AF "\fIéditée par Daniel Quinlan\fP"
.AU "\fRGroupe pour la norme de hiérarchie du système de fichiers\fP"
.AS 0 5
.nh
.P 1
Cette norme consiste en un ensemble d'exigences et de
suggestions concernant la disposition des fichiers et des répertoires
dans un système d'exploitation de type \*(Ux. Les suggestions sont
faites pour faciliter l'interopérabilité des applications, des outils
d'administration système, des outils de développement et des scripts,
ainsi qu'une documentation plus uniforme entre ces systèmes.
.AE
.COVEND
.SK
.\" -------------------------------------------------------------------
.\" Partie légale
.\" -------------------------------------------------------------------
.nh
.nr % 1
.af P i
.PF "''- \\\\nP -''"
Toutes les marques déposées et les copyrights appartiennent à leurs
propriétaires, sauf notification spécifique. L'utilisation d'un terme
dans ce document ne devrait pas être considérée comme affectant la
validité de toute marque déposée ou marque de fabrique.
.BS
Copyright \(co 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 préservées sur toutes les copies.
.ig
Nous accordons la permission de faire traiter ce fichier par un outil de
mise en page (tel que troff) et d'imprimer le résultat, à la condition
que le document imprimé contienne une note de permission identique à
celle-ci mis à part l'omission de ce parapgraphe (ce paragraphe n'étant
pas pertinent dans le document imprimé).
..
Nous accordons la permission de copier et distribuer des versions
modifiées de cette norme sous les conditions de copie exacte, à
condition que la page de titre indique qu'elle a été modifiée en
incluant une référence à la norme d'origine, à condition que soient
incluses les informations nécessaires à la recherche de la norme
d'origine, et à condition que le travail dérivé 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 modifiées, à part le fait que cette note de permission soit
donnée dans une traduction approuvée par le tenant du copyright.
.BE
.SK
.\" -------------------------------------------------------------------
.\" Corps du document
.\" -------------------------------------------------------------------
.BS
.BE
.nr % 1
.af P 1
.nr Hu 4
.H 1 "Introduction"
.\" J'aimerais en finir avec ces sous-sections dans l'introduction :
.\" (en déplaçant certaines choses générales à cet endroit)
.\"
.\" Déclaration d'intérêt général (ou est-ce le résumé ?)
.\"
.\" - Organisation
.\" - Documents de base, s'il y en a
.\" - Contexte (histoire)
.\" - Audience
.\" - But (objectifs)
.\" - principes de base (possibilité d'avoir /usr en lecture seule,
.\" etc.) comprenant : implémentable à grande échelle, changements
.\" minimes par rapport aux implémentations historiques, changements
.\" minimes par rapport aux implémentations existantes
.\" - Normes connexes
.H 2 "État de la norme"
.P
Voici la version 2.0 de la norme de hiérarchie du système de fichiers
(FHS 2.0).
Les commentaires sur cette norme sont les bienvenus de la part des
personnes intéressées. Les suggestions de changements devraient être
faites sous la forme d'une proposition de changement du texte,
accompagnée des commentaires d'explication appropriés.
Les suggestions de cette norme sont sujettes à modification. L'utilisation
des informations incluses dans ce document se fait à vos propres risques.
.ig
Cette norme proposée est distribuée pour l'instant à des fins de tests
et de commentaires.
Les commentaires sur cette norme sont les bienvenus de la part des
personnes intéressées. Les suggestions de changements devraient être de
la forme d'une proposition de changement du texte, accompagnée des
commentaires d'explication appropriés.
Les suggestions de cette norme sont sujets à modification. L'utilisation
des informations incluses dans ce document se fait à vos propres risques.
..
.H 2 "Organisation de la norme"
.P
Cette norme est divisée entre ces sections :
.AL 1
.LI
Introduction
.LI
Le système de fichiers : établissement de quelques principes clés.
.LI
Le répertoire racine.
.LI
La hiérarchie \f(CW/usr\fP.
.LI
La hiérarchie \f(CW/var\fP.
.LI
Annexe spécifique au système d'exploitation.
.LE
.H 2 "Conventions"
.P
.ie t \{\
Une police de taille fixe est utilisée pour l'affichage des noms de
fichiers et de répertoires.
\}
.el \{\
Nous recommandons que lisiez une version mise en pages de ce documents
plutôt que la version texte. Dans la version mise en pages, les noms de
fichiers et de répertoire sont affichés dans une police à taille fixe.
\}
Les parties variables des noms de fichiers sont représentées par une
description de leur contenu à l'intérieur des caractères chevrons
"\f(CW<\fP" et "\f(CW>\fP", \f(CW\fP. Les adresses de courrier
électronique sont aussi entourées de chevrons "<" et ">" mais sont
indiquées dans la police habituelle.
Les parties optionnelles des noms de fichiers sont entourées des
caractères crochet "\f(CW[\fP" et "\f(CW]\fP" et peuvent être combinées
avec la convention "\f(CW<\fP" et "\f(CW>\fP". Par exemple, si on
pouvait trouver un fichier existant avec ou sans extension, on pourrait
le représenter par \f(CW[.]\fP.
Les parties de chaînes variables des noms de répertoires et de fichiers
sont indiquées par une étoile : "\f(CW*\fP".
.SK
.H 2 "Historique de la \*(Fs"
.P
Le processus de développement d'une hiérarchie de système de fichiers
standard a débuté en août 1993 dans un effort de restructuration de la
structure de fichiers et de répertoires de Linux. La FSSTND, norme pour
une hiérarchie du système de fichiers spécifique au système
d'exploitation Linux, est sortie le 14 février 1994. Des versions
successives sont sorties le 9 octobre 1994 et le 28 mars 1995.
Au début de 1995, avec l'aide de membres de la communauté de
développement BSD, il a été décidé de développer une version de FSSTND
plus complète pour englober non seulement Linux mais aussi les autres
systèmes de type \*(Ux. En définitive, nous avons fait un effort
concerté pour nous concentrer sur des problèmes généraux aux systèmes de
type \*(Ux. En reconnaissance de cette ouverture, le nom de la norme a
été modifié pour devenir Norme de hiérarchie du système de fichiers ou
\*(Fs en abrégé. (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 représente un consensus entre les
points de vue de ceux-ci et d'autres contributeurs.
.H 2 "Étendue"
.P
Ce document spécifie une hiérarchie de système de fichiers standard pour
les systèmes de fichiers \*(Fs en spécifiant l'emplacement des fichiers
et répertoires, et le contenu de certains fichiers système.
Cette norme a été faite pour être utilisée par les intégrateurs de
systèmes, les développeurs de paquetages et les administrateurs système
dans la construction et la maintenance de systèmes de fichiers
se conformant à \*(Fs. Elle est tout d'abord destinée à servir de
référence et n'est pas un tutoriel sur la manière de gérer une
hiérarchie de système de fichiers conforme.
La \*(Fs est basée sur des travaux préliminaires sur FSSTND, une norme
d'organisation du système de fichiers pour le système d'exploitation
Linux. Elle est basée sur la FSSTND pour pallier à des problèmes
d'interopérabilité non seulement dans la communauté Linux mais dans un
horizon plus vaste incluant les systèmes d'exploitation basés sur
4.4BSD. Elle incorpore les leçons concernant le support de
plusieurs architectures et les demandes en matière de réseaux
hétérogènes, leçons apprises dans le monde BSD ou ailleurs.
Bien que cette norme soit plus complète que les tentatives précédentes
sur la normalisation de la hiérarchie de systèmes de fichiers, des mises
à jour périodiques peuvent s'avérer nécessaires à mesure que les
demandes changent par rapport à la technologie émergeante. Il est aussi
possible que de meilleures solutions aux problèmes évoqués ici soient
découvertes ou que nos solutions ne soient plus les meilleures
possibles. Des brouillons supplémentaires pourront être apportés en plus
des mises à jour périodiques de ce document. Cependant, un des buts
suivis est la compatibilité ascendante entre une version de ce document
et la suivante.
Les commentaires relatifs à cette norme sont les bienvenus. Tout
commentaire ou suggestion de changement devraient être adressés à
l'éditeur de la \*(Fs (Daniel Quinlan ), ou si
vous préférez, à la liste de distribution \*(Fs. Les commentaires de
nature typographique ou grammaticale doivent être adressés directement à
l'éditeur de la \*(Fs.
Nous vous demandons de contacter en premier l'éditeur de la \*(Fs avant
d'envoyer un courrier à la liste de distribution afin d'éviter un
nouveau débat sur des sujets anciens. Les messages mal conçus ne seront
pas bien vus sur la liste de distribution.
Des questions concernant l'interprétation des objets de ce documents
peuvent se poser de temps en temps. Si vous avez besoin de précisions,
veuillez contacter l'éditeur de la \*(Fs. Puisque cette norme représente
le consensus de beaucoup de participants, il est important de s'assurer
que toute interprétation représente aussi l'opinion collective. Pour
cette raison, il peut ne pas être possible de fournir une réponse
immédiate sauf si la demande a déjà fait l'objet d'une discussion.
.H 2 "Suggestions générales"
.P
Voici quelques unes des suggestions qui ont été utilisées dans le
développement de cette norme :
.BL
.LI
Résoudre des problèmes techniques en limitant les difficultés liées à la
transition.
.LI
Faire une spécification relativement stable.
.LI
Obtenir l'approbation des distributeurs, des développeurs, et autres
décideurs dans les groupes de développement adéquats et encourager leur
participation.
.LI
Fournir une norme attractive pour les implémenteurs des différents
systèmes de type \*(Ux.
.LE
.H 2 "Audience visée"
.P
L'audience visée par cette norme comprend, mais n'est pas limitée aux
groupes de personnes suivants :
.BL
.LI
Développeurs de systèmes
.LI
Intégrateurs et distributeurs de systèmes
.LI
Développeurs d'applications
.LI
Auteurs de documentations
.LI
Administrateurs système et autres personnes intéressées (à des fins
d'information)
.LE
.H 2 "Conformité avec ce document"
.P
Cette section définit la signification des termes "conforme" et
"compatible" en ce qui concerne cette norme, et de conformité et
compatibilité "partielle".
Une "implémentation" fait ici référence à une distribution, un système
installé, un programme, un paquetage (ou toute partie similaire d'un
logiciel ou de données), ou tout composant de ceux-ci.
Une implémentation est totalement conforme à cette norme si chaque
exigence de cette norme est satisfaite. Chaque fichier ou répertoire
faisant partie de l'implémentation doit être situé comme il est spécifié
dans ce document. Si le contenu d'un fichier est décrit ici, le contenu
véritable doit correspondre à sa description. L'implémentation doit
aussi tenter de trouver tout fichier ou répertoire (extérieur à
lui-même) au premier abord ou exclusivement à l'endroit spécifié dans
cette norme.
.\" maladroit
Une implémentation est totalement compatible avec cette norme si chaque
fichier ou répertoire qu'elle contient peut être trouvé en regardant à
l'endroit spécifié ici et sera trouvé avec un contenu identique à ce qui
est spécifié ici, même si ce n'est pas l'emplacement de base ou physique
du fichier ou du répertoire en question. L'implémentation doit, quand
elle essaie de trouver un fichier ou un répertoire n'en faisant pas
partie, le faire à l'endroit spécifié dans cette norme, bien qu'elle
puisse aussi tenter de le trouver à d'autres endroits (non standards).
Une implémentation 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
séparés. L'expression "une partie significative" est effectivement
subjective, et dans les cas limites, la personne concernée devrait
contacter l'éditeur de la \*(Fs. Nous avons anticipé le fait que des
variations soient tolérées dans les cas limites.
Afin de se définir comme partiellement conforme à la \*(Fs ou
partiellement compatible avec la \*(Fs, une implémentation doit fournir
une liste de tous les endroits auxquels elle et le document \*(Fs
diffèrent, en plus d'une explication brève de la raison de cette
différence. Cette liste sera fournie avec l'implémentation en question,
et aussi mise à disposition de la liste de distribution \*(Fs ou de
l'éditeur de la \*(Fs.
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 implémentation n'a pas besoin de contenir tous les fichiers
et répertoires spécifiés dans cette norme pour être conforme ou
compatible. Il est simplement nécessaire que les fichiers qu'elle
contient soient placés correctement. Par exemple, si le système de
fichiers minix n'est pas supporté par une distribution, les outils minix
n'ont pas besoin d'être inclus, même s'ils sont mentionnés explicitement
dans la section sur \f(CW/sbin\fP.
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 "suggère". Les objets indiqués comme
optionnels n'ont pas de portée sur la conformité ou la compatibilité
d'une implémentation ; ce sont des suggestions faites pour encourager la
pratique courante, mais ils peuvent être situés n'importe où au gré de
l'implémenteur.
.SK
.H 1 "Le système de fichiers"
.P
Le système de fichiers \*(Ux est caractérisé par :
.BL
.LI
Une structure hiérarchique
.LI
Le traitement uniforme des fichiers de données
.LI
La protection des fichiers de données
.LE
.P
Cette norme suppose que le système d'exploitation sous-jacent au système
de fichiers conforme à la \*(Fs supporte les mêmes possibilités de
sécurité de base que l'on trouve dans la plupart des systèmes de
fichiers \*(Ux. Notez que cette norme n'essaie pas d'être en accord au
mieux possible avec une implémentation particulière d'un système
\*(Ux. Cependant, beaucoup d'aspects de cette norme sont basées sur des
idées que l'on trouve dans \*(Ux et autres systèmes de type \*(Ux.
Ceci après une considération attentive d'autres facteurs, comprenant :
.BL
.LI
Des pratiques courantes et saines dans les systèmes de type \*(Ux.
.LI
L'implémentation d'autres structures de systèmes de fichiers
.LI
Des normes applicables
.LE
.P
Il est possible de définir deux catégories orthogonales de
fichiers : partageables contre non partageables, et variables contre
statiques.
.\" catégories/catégorisations and fichiers/fichiers de données
Les données partageables sont ce qui peut être partagé entre plusieurs
machines différentes ; non partageables est ce qui doit être spécifique à une
machine particulière. Par exemple, les répertoires personnels des
utilisateurs sont des données partageables, mais pas les fichiers de
blocage de périphériques (locks).
Les données statiques comprennent les binaires, les bibliothèques, la
documentation, et tout ce qui ne change pas sans l'intervention de
l'administrateur système ; les données variables sont tout le reste qui
change sans l'intervention de l'administrateur système.
.\" Le texte donné précédemment se rapportait aux "principes" sans les
.\" spécifier. À la place, il décrivait quatre catégories de telle sorte
.\" que ça *impliquait* un principe. Voici le principe.
Pour faciliter la sauvegarde, l'administration et le partage de fichiers
sur des réseaux de systèmes hétérogènes, il est préférable d'établir une
correspondance simple et aisément compréhensible entre les répertoires
(surtout les répertoires considérés comment des points de montage
potentiels) et le type de données qu'ils contiennent.
À travers ce document, et dans tout système de fichiers bien organisé,
la compréhension de ce principe de base aidera à diriger la structure
et lui apporter une cohérence supplémentaire.
La distinction entre données partageables et non partageables est
nécessaire pour plusieurs raisons :
.BL
.LI
Dans un environnement en réseau (par exemple, plus d'un hôte par site),
il y a une bonne partie des données qui peuvent être partagées entre les
différentes machines pour sauver de la place et faciliter la tâche de
maintenance.
.LI
Dans un environnement en réseau, certains fichiers contiennent des
informations spécifiques à une seule machine. Par conséquent ces
systèmes de fichiers ne peuvent être partagés (sans prendre des mesures
spéciales).
.LI
Historiquement, certaines implémentations des systèmes de fichiers de
type \*(Ux ont mélangé des données partageables et non partageables dans
la même hiérarchie, rendant difficile le partage de grandes parties du
système de fichiers.
.LE
La distinction "partageable" peut être utilisée pour supporter, par
exemple :
.BL
.LI
Une partition \f(CW/usr\fP (ou des composants de \f(CW/usr\fP) montés
(en lecture seule) à travers le réseau (en utilisant NFS).
.LI
Une partition \f(CW/usr\fP (ou des composants de \f(CW/usr\fP) montés
à partir d'un support en lecture seule. Un CD-ROM peut être considéré
comme un système de fichiers en lecture seule partagé avec d'autres
systèmes conformes à la \*(Fs, en utilisant le système de courrier comme
un "réseau".
.LE
.P
La distinction "statique" contre "variable" affecte le système de
fichiers de deux manières principales :
.BL
.LI
Puisque \f(CW/\fP contient à la fois des données statiques et variables,
il doit être monté en lecture-écriture.
.LI
Puisque le traditionnel \f(CW/usr\fP contient à la fois des données
variables et statiques, et puisque nous voudrions le monter en lecture
seule (voir ci-dessus), il est nécessaire de fournir une méthode pour
avoir \f(CW/usr\fP monté en lecture seule. Ceci est obtenu par la
création d'une hiérarchie \f(CW/var\fP qui est montée en
lecture-écriture (ou qui fait partie d'une autre partition en
lecture-ecriture, telle que \f(CW/)\fP, qui remplace bien des fonctions
traditionnelles de la partition \f(CW/usr\fP.
.LE
Voici un tableau pour résumer le tout. Puisque ce graphique contient des
exemples généralisés, il peut ne pas s'appliquer à chaque implémentation
possible d'un système conforme à la \*(Fs.
.TS
box,center;
l | l | l.
partageable non partageable
_
statique /usr /etc
/opt /boot
_
variable /var/mail /var/run
/var/spool/news /var/lock
.TE
.SK
.H 1 "Le répertoire racine"
.P
Cette section décrit la structure du répertoire racine (root). Le
contenu du système de fichiers root doit être adéquat pour démarrer,
reconstituer, rétablir et/ou réparer le système :
.BL
.LI
Pour démarrer un système, il doit y avoir suffisamment de choses sur la
partition racine pour monter d'autres systèmes de fichiers. Ceci
comprend les utilitaires, la configuration, les informations du chargeur
de démarrage, et d'autres données de démarrage
essentielles. \f(CW/usr\fP, \f(CW/opt\fP et \f(CW/var\fP sont faits pour
pouvoir être situés sur d'autres systèmes de fichiers.
.LI
Pour permettre le rétablissement et/ou la réparation d'un système, les
utilitaires nécessaires au mainteneur expérimenté pour diagnostiquer et
reconstruire un système endommagé doivent être présents sur le système
de fichiers racine.
.LI
Pour reconstituer un système, les utilitaires nécessaires à la
reconstitution à partir des sauvegardes système (sur disque, bande,
etc.) doivent être présents sur le système de fichiers racine.
.LE
.P
Le principal argument utilisé pour contrer ces considérations, qui
penchent pour mettre beaucoup de choses sur le système 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 système de fichiers racine :
.BL
.LI
Il est monté de temps en temps à partir d'un moyen de stockage très
petit.
.LI
Le système de fichiers racine contient beaucoup de fichiers de
configuration spécifiques au système. Les exemples possibles comprennent
un noyau spécifique au système, un nom d'hôte différent, etc. Ceci veut
dire que le système de fichiers racine n'est pas toujours partageable
entre des systèmes en réseau. Limiter sa taille sur des systèmes en réseau
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.
.LI
Bien que vous puissiez avoir le système 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 installés,
vous pourrez trouver des incompatibilités avec d'autres systèmes qui
utilisent des systèmes de fichiers racine sur des partitions plus
petites. Si vous êtes développeur vous pouvez changer votre hypothèse en
un problème pour un grand nombre d'utilisateurs.
.LI
Les erreurs de disque qui corrompent les données sur le système de
fichiers racine sont un problème plus important que les erreurs sur tout
autre partition. Un système de fichiers racine petit est moins sujet à
la corruption à la suite d'un plantage système.
.LE
.P
Les logiciels ne doivent jamais créer ou demander des fichiers spéciaux
ou des sous-répertoires dans le répertoire racine. D'autres emplacements
dans la hiérarchie \*(Fs fournissent plus de flexibilité qu'il n'en faut
pour tout paquetage.
.HU "Raison d'être"
.br
.P
Il y a plusieurs raisons pour lesquelles l'introduction d'un nouveau
répertoire dans le système de fichiers racine est interdit :
.BL
.LI
Ceci demande de la place sur une partition racine que l'administrateur
système veut garder petite et simple pour des raisons de performance ou
de sécurité.
.LI
Ceci contredit toute logique que l'administrateur système a pu mettre en
place pour distribuer des hiérarchies de fichiers standards sur des
volumes montables.
.LE
.PS
copy "draft.pic"
dir(/,le répertoire racine)
sub("bin","Binaires des commandes essentielles")
sub("boot","Fichiers statiques du chargeur de démarrage")
sub("dev","Fichiers de périphériques")
sub("etc","Configuration système spécifique à la machine")
sub("home","Répertoires personnels des utilisateurs")
sub("lib","Bibliothèques partagées essentielles et modules du noyau")
sub("mnt","Point de montage des partitions temporaires")
sub("opt","Paquetages d'applications logicielles supplémentaires")
sub("root","Répertoire personnel de l'utilisateur root")
sub("sbin","Binaires systèmes essentiels")
sub("tmp","Fichiers temporaires")
sub("usr","Hiérarchie secondaire")
sub("var","Données variables")
.PE
Chaque répertoire listé ci-dessus est spécifié en détail dans des
sous-sections séparées ci-dessous. \f(CW/usr\fP et \f(CW/var\fP ont
chacun une section complète dans ce document à cause de la complexité de
ces répertoires.
L'image du noyau du système d'exploitation doit être situé soit dans
\f(CW/\fP soit dans \f(CW/boot\fP. Les informations supplémentaires sur
l'emplacement du noyau se trouvent dans la section concernant
\f(CW/boot\fP ci-dessous.
.H 2 "/bin : binaires de commandes utilisateurs essentielles (pour tous les utilisateurs)"
.P
\f(CW/bin\fP contient des commandes qui peuvent être utilisées à la fois par
l'administrateur système et les utilisateurs, mais qui sont obligatoires
en mode utilisateur simple. Il peut aussi contenir des commandes
utilisées indirectement par des scripts.
Il ne devrait pas y avoir de sous-répertoires à l'intérieur de
\f(CW/bin\fP.
Les binaires des commandes qui ne sont pas suffisamment essentielles
pour rester dans \f(CW/bin\fP doivent être mises dans \f(CW/usr/bin\fP,
à la place. Les objets qui ne sont utilisés que par des utilisateurs non
root (\f(CWmail\fP, \f(CWchsh\fP, etc.) ne sont pas assez essentiels
pour être placés dans la partition racine.
.HU "Fichiers obligatoires pour /bin :"
.BL
.LI
Commandes générales :
.sp
Les commandes suivantes ont été incluses parce qu'elles sont
essentielles. Certaines sont présentes à cause de leur emplacement
traditionnel dans \f(CW/bin\fP.
.VL 2
.LI "\f(CW{"
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 }\fP
.LE
.P
Si \f(CW/bin/sh\fP est le Bash, alors \f(CW/bin/sh\fP devrait être un
lien symbolique ou dur vers \f(CW/bin/bash\fP puisque Bash se comporte
de manière différente quand il est appelé en tant que \f(CWsh\fP ou
\f(CWbash\fP. \f(CWpdksh\fP, qui peut être \f(CW/bin/sh\fP sur certains
disques d'installation, devrait être arrangé de la sorte avec
\f(CW/bin/sh\fP pointant vers \f(CW/bin/ksh\fP. L'utilisation d'un lien
symbolique dans ces cas permet aux utilisateurs de voir aisément que
\f(CW/bin/sh\fP n'est pas un vrai shell de Bourne.
Puisque l'emplacement standard de-facto du shell C est \f(CW/bin/csh\fP,
si et seulement si un shell C ou équivalent (comme \f(CWtcsh\fP) est
disponible sur le système, il devrait être disponible par le nom
\f(CW/bin/csh\fP. \f(CW/bin/csh\fP peut être un lien symbolique vers
\f(CW/bin/tcsh\fP ou \f(CW/usr/bin/tcsh\fP.
.ft I
Note : les commandes \f(CW[\fP et \f(CWtest\fP sont intégrées dans les
remplacements du shell de Bourne (\f(CW/bin/sh\fP) les plus couramment
utilisés. Ces deux commandes ne doivent pas être placées dans
\f(CW/bin\fP ; elles peuvent être placées dans \f(CW/usr/bin\fP. Elles
doivent être incluses comme binaires séparés avec tout système \*(Ux ou
de type \*(Ux essayant de se conformer à la norme POSIX.2.
.ft R
.LI
Commandes de remise en état :
.sp
Ces commandes ont été ajoutées pour permettre la remise en état d'un
système (en supposant que \f(CW/\fP soit intact).
.VL 2
.LI "\f(CW{"
tar, gzip, gunzip \fR(lien vers gzip)\fP, zcat \fR(lien vers gzip)\fP }\fP
.LE
.P
Si les sauvegardes système sont faites en utilisant des programmes
autres que \f(CWgzip\fP et \f(CWtar\fP, alors la partition racine
devrait contenir les composants de remise en état minimaux. Par exemple,
beaucoup de systèmes devraient inclure \f(CWcpio\fP puisque c'est
l'utilitaire de sauvegarde le plus couramment utilisé après
\f(CWtar\fP. Inversement, si l'on est sûr 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 \f(CW/usr\fP en NFS). Si
la remise en état d'un système est prévue à travers le réseau, alors
\f(CWftp\fP ou \f(CWtftp\fP (avec tout ce qui est nécessaire à
l'établissement d'une connexion ftp) doit être disponible sur la
partition racine.
Les commandes de remise en état peuvent apparaître soit dans
\f(CW/bin\fP soit dans \f(CW/usr/bin\fP sur des systèmes différents.
.LI
Commandes réseau :
.sp
Voici les seuls binaires nécessaires pour le réseau, autres que ceux de
\f(CW/usr/bin\fP ou \f(CW/usr/local/bin\fP, et que à la fois root et les
utilisateurs voudront ou auront besoin d'exécuter.
.VL 2
.LI "\f(CW{"
domainname, hostname, netstat, ping }\fP
.LE
.LE
.H 2 "/boot : fichiers statiques du chargeur de démarrage"
.P
Ce répertoire contient tout ce qu'il faut pour le processus de démarrage
à part les fichiers de configuration et l'installeur de carte. Ainsi,
\f(CW/boot\fP stocke les données utilisées avant que le noyau ne
commence à exécuter des programmes en mode utilisateur. Ceci peut
comprendre les secteurs de démarrage principaux sauvegardés, les
fichiers de cartes des secteurs, et tout autre donnée qui n'est
pas directement éditée à la main. Les programmes nécessaires à ce que le
chargeur de démarrage soit capable de démarrer sur un fichier doivent
être placés dans \f(CW/sbin\fP. Les fichiers de configuration pour les
chargeurs de démarrage doivent être placés dans \f(CW/etc\fP.
Le noyau du système d'exploitation doit être situé soit dans \f(CW/\fP
soit dans \f(CW/boot\fP
.ft I
Note : sur certaines machines i386, il peut être nécessaire que
\f(CW/boot\fP soit situé sur une partition séparée située complètement
en-dessous du cylindre 1024 du périphérique de démarrage à cause de
contraintes matérielles.
.ft P
.H 2 "/dev : fichiers de périphériques"
.P
Le répertoire \f(CW/dev\fP est l'emplacement des fichiers spéciaux ou de
périphériques.
S'il est possible que des périphériques dans \f(CW/dev\fP aient besoin
d'être créés à la main, \f(CW/dev\fP contiendra une commande nommée
\f(CWMAKEDEV\fP, qui pourra créer les périphériques au besoin. Il peut
aussi disposer d'une commande \f(CWMAKEDEV.local\fP pour tout
périphérique local.
Au besoin, \f(CWMAKEDEV\fP doit avoir de quoi créer n'importe quel
périphérique qu'on pourrait trouver dans le système, et non pas
simplement ceux qu'une implémentation particulière installe.
.H 2 "/etc : configuration système spécifique à la machine"
.P
\f(CW/etc\fP contient les fichiers et les répertoires de configuration
spécifiques au système en cours.
Aucun binaire ne devrait être situé dans \f(CW/etc\fP.
.PS
copy "draft.pic"
dir(/etc,configuration système spécifique à la machine)
sub("X11","Configuration pour le système X Window")
sub("opt","Configuration pour /opt")
.PE
La section suivante sert surtout à illustrer la description du contenu
de \f(CW/etc\fP avec un certain nombre d'exemples ; ce n'est surtout pas
une liste exhaustive.
.HU "Fichiers obligatoires pour /etc :"
.BL
.LI
Fichiers généraux :
.VL 2
.LI "\f(CW{"
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 }\fP
.LE
.LI
Fichiers de réseau :
.VL 2
.LI "\f(CW{"
exports, ftpusers, gateways, host.conf, hosts, hosts.allow, hosts.deny,
hosts.equiv, hosts.lpd, inetd.conf, networks, printcap, protocols,
resolv.conf, rpc, services }\fP
.LE
.LE
.P
.ft I
Notes :
La mise en place des scripts de commandes invoqués au démarrage peut
ressembler aux modèles System V ou BSD. Des spécifications
supplémentaires dans ce domaine pourront être ajoutées à une version
future de la norme.
Les systèmes qui utilisent la suite shadow password auront des fichiers
de configuration supplémentaires dans \f(CW/etc\fP (\f(CW/etc/shadow\fP
et autres) et des programmes dans \f(CW/usr/sbin\fP (\f(CWuseradd\fP,
\f(CWusermod\fP, et autres).
.ft P
.H 3 "/etc/X11 : Configuration pour le système X Window"
.sp 0
.P
\f(CW/etc/X11\fP est l'emplacement recommandé pour toute configuration
X11 spécifique à la machine. Ce répertoire est nécessaire pour permettre
un contrôle local si \f(CW/usr\fP est monté en lecture seule. Les
fichiers qui devraient être dans ce répertoire comprennent
\f(CWXconfig\fP (et/ou \f(CWXF86Config\fP) et \f(CWXmodmap\fP.
Les sous-répertoires de \f(CW/etc/X11\fP peuvent inclure ceux pour
\f(CWxdm\fP et pour tout autre programme (certains gestionnaires de
fenêtres, par exemple) qui en a besoin. Nous recommandons que les
gestionnaires de fenêtres qui n'ont qu'un fichier de configuration
par défaut \f(CW.*wmrc\fP le nomment \f(CWsystem.*wmrc\fP
(sauf s'il existe un nom de rechange largement reconnu) et n'utilisent
pas de sous-répertoire. Tout sous-répertoire de gestionnaire de fenêtres
devrait être nommé du même nom que le binaire réel du gestionnaire de
fenêtres.
\f(CW/etc/X11/xdm\fP contient les fichiers de configuration pour
\f(CWxdm\fP. Ce sont la plupart des fichiers que l'on trouve
habituellement dans \f(CW/usr/lib/X11/xdm\fP. Certaines données
variables et locales pour \f(CWxdm\fP sont stockées dans
\f(CW/var/state/xdm\fP.
.H 3 "/etc/opt : fichiers de configuration pour /opt"
.sp 0
.P
Les fichiers de configuration spécifiques à la machine pour les
paquetages des logiciels d'application supplémentaires seront installés
dans le répertoire \f(CW/etc/opt/\fP, où \f(CW\fP
est le nom du sous-répertoire de \f(CW/opt\fP où les données statiques
de ce paquetage sont stockées. Aucune structure n'est imposée sur la
disposition interne de \f(CW/etc/opt/\fP.
Si un fichier de configuration doit résider dans un endroit différent
pour que le paquetage ou le système fonctionne correctement, on peut le
placer dans un endroit différent de \f(CW/etc/opt/\fP.
.HU "Raison d'être :"
.br
.P
Voir la raison d'être pour \f(CW/opt\fP.
.H 2 "/home : répertoires personnels des utilisateurs (optionnel)"
.P
\f(CW/home\fP est un concept très standard, mais c'est clairement un
système de fichiers spécifique au site. Sa mise en place sera différente
d'une machine à l'autre. Cette section ne décrit qu'un ordonnancement
suggéré des répertoires personnels des utilisateurs ; néanmoins nous
recommandons que toutes les distributions conformes à la \*(Fs l'utilisent
comme emplacement par défaut des répertoires utilisateurs.
Sur les petits systèmes, chaque répertoire utilisateur est en général
l'un des nombreux sous-répertoires de \f(CW/home\fP comme
\f(CW/home/dupont\fP, \f(CW/home/torvalds\fP, \f(CW/home/admin\fP, etc.
Sur des grands systèmes (surtout quand les répertoires \f(CW/home\fP
sont partagés entre beaucoup d'hôtes par NFS) il est utile de subdiviser
les répertoires personnels des utilisateurs. Le partage peut se faire en
utilisant des sous-répertoires comme \f(CW/home/equipe\fP,
\f(CW/home/invites\fP, \f(CW/home/eleves\fP, etc.
D'autres personnes préfèrent placer les comptes utilisateurs à divers
autres endroits. Par conséquent, aucun programme ne devrait se fier à
cet endroit. Si vous voulez trouver le répertoire personnel d'un
utilisateur, vous devriez utiliser la fonction de bibliothèque
\f(CWgetpwent(3)\fP plutôt que de compter sur \f(CW/etc/passwd\fP parce
que les informations sur les utilisateurs peuvent être stockées à
distance en utilisant des systèmes tels que NIS.
.H 2 "/lib : bibliothèques partagées importantes et modules du noyau"
.P
Le répertoire \f(CW/lib\fP contient les images des bibliothèques
partagées nécessaires au démarrage du système et pour lancer les
commandes du système de fichiers racine.
.PS
copy "draft.pic"
dir(/lib,bibliothèques partagées importantes et modules du noyau)
sub("modules","modules chargeables du noyau")
.PE
Ceci comprend \f(CW/lib/libc.so.*\fP, \f(CW/lib/libm.so.*\fP, l'éditeur
de liens dynamiques partagés \f(CW/lib/ld.so\fP, et d'autres
bibliothèques partagées nécessaires pour les binaires de \f(CW/bin\fP et
\f(CW/sbin\fP.
Les bibliothèques partagées nécessaires uniquement aux binaires de
\f(CW/usr\fP (comme n'importe quel binaire pour X Window)
n'appartiennent pas à \f(CW/lib\fP. Seules les bibliothèques partagées
nécessaires au fonctionnement des binaires de \f(CW/bin\fP et
\f(CW/sbin\fP devraient se trouver ici. La bibliothèque
\f(CWlibm.so.*\fP peut aussi se trouver dans \f(CW/usr/lib\fP si elle
n'est pas nécessaire dans \f(CW/bin\fP ou \f(CW/sbin\fP.
Pour des raisons de compatibilité, \f(CW/lib/cpp\fP doit exister et se
référer au pré-processeur C installé sur le système. L'emplacement
traditionnel de ce binaire est
\f(CW\%/usr/lib/gcc-lib///cpp\fP. \f(CW/lib/cpp\fP peut
soit pointer vers ce binaire, soit vers toute référence à ce binaire qui
existe dans le système de fichiers. (Par exemple, \f(CW/usr/bin/cpp\fP
est de même souvent utilisé.)
La spécification pour \f(CW/lib/modules\fP est en cours d'élaboration.
.H 2 "/mnt : point de montage pour les systèmes de fichiers montés temporairement"
.P
Ce répertoire est installé pour que l'administrateur système puisse
monter de manière temporaire et au besoin des systèmes de fichiers. Le
contenu de ce répertoire est une affaire locale et ne devrait pas
affecter la manière dont n'importe quel programme est lancé.
Nous sommes opposés à l'utilisation de ce répertoire par les programmes
d'installation, et nous suggérons qu'un répertoire temporaire convenable
non utilisé par le système soit utilisé à la place.
.H 2 "/opt : paquetages de logiciels d'applications supplémentaires"
.SP
.PS
copy "draft.pic"
dir(/opt,paquetages de logiciels d'applications supplémentaires)
sub("","objets de paquetage statiques")
.PE
\f(CW/opt\fP est réservé à l'installation de paquetages de logiciels
d'application supplémentaires.
Un paquetage qui doit être installé dans \f(CW/opt\fP devra mettre ses
fichiers statiques dans une arborescence \f(CW/opt/\fP
séparée, où \f(CW\fP est un nom décrivant le paquetage
logiciel.
Les programmes devant être lancés par les utilisateurs seront situés
dans le répertoire \f(CW/opt//bin\fP. Si le paquetage
comprend des pages de manuel \*(Ux, elle seront situées dans
\f(CW/opt//man\fP et la même structure que
\f(CW/usr/share/man\fP sera utilisée.
Les répertoires \f(CW/opt/bin\fP, \f(CW/opt/doc\fP,
\f(CW/opt/include\fP, \f(CW/opt/info\fP, \f(CW/opt/lib\fP, et
\f(CW/opt/man\fP sont réservés à l'usage de l'administrateur système
local. Les paquetages peuvent fournir des fichiers de "lancement"
(front-end) faits pour qu'un administrateur système local les place (en
faisant un lien ou en les copiant) dans ces répertoires réservés, mais
ils devront fonctionner normalement en l'absence de ces répertoires
réservés.
Les fichiers de paquetage variables (qui changent avec un usage normal)
devraient être installés dans \f(CW/var/opt\fP. Voyez la section sur
\f(CW/var/opt\fP pour plus d'informations.
Les fichiers de configuration spécifiques à la machine devraient être
installés dans \f(CW/etc/opt\fP. Voyez la section sur \f(CW/etc/opt\fP
pour plus d'informations.
Aucun autre fichier de paquetage ne devrait exister en dehors des
hiérarchies \f(CW/opt\fP, \f(CW/var/opt\fP et \f(CW/etc/opt\fP sauf pour
les fichiers de paquetage qui doivent résider dans des endroits
spécifiques à l'intérieur de l'arborescence du système de fichiers afin
de fonctionner correctement. Par exemple, les fichiers de bloquage des
périphériques doivent être placés dans \f(CW/var/lock\fP et les
périphériques dans \f(CW/dev\fP.
.HU "Raison d'être"
.br
.P
L'utilisation de \f(CW/opt\fP pour les logiciels supplémentaires est une
pratique bien établie dans la communauté \*(Ux. L'interface Binaire
d'Applications (ABI) System V [AT&T 1990], basée sur la Définition
d'Interface System V (troisième édition) fournit une structure
\f(CW/opt\fP très similaire à celle décrite ici.
La Norme de Compatibilité Binaire Intel version 2 (iBCS2) fournit aussi
une structure similaire pour \f(CW/opt\fP.
En général, toutes les données nécessaires au support d'un paquetage sur
un système doivent être présentes dans \f(CW/opt/\fP, y
compris les fichiers destinés à être copiés dans
\f(CW/etc/opt/\fP et \f(CW/var/opt/\fP ainsi que
dans les répertoires réservés de \f(CW/opt\fP.
.H 2 "/root : répertoire personnel pour l'utilisateur root (optionnel)"
.P
\f(CW/\fP est traditionnellement le répertoire personnel du compte root
sur les systèmes \*(Ux. \f(CW/root\fP est utilisé sur de nombreux
systèmes Linux et sur certains systèmes \*(Ux (afin de réduire
l'encombrement du répertoire \f(CW/\fP). Le répertoire
personnel du compte root peut être déterminé par une préférence globale
au niveau du développeur ou locale. Les possibilités évidentes
comprennent \f(CW/\fP, \f(CW/root\fP et \f(CW/home/root\fP.
Si le répertoire personnel du compte root n'est pas stocké sur la
partition racine il sera nécessaire de s'assurer qu'il prendra la
valeur \f(CW/\fP par défaut si on ne peut le trouver.
.ft I
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 système. Pour
cette raison, nous recommandons que les sous-répertoires tels que
\f(CWMail\fP et \f(CWNews\fP n'apparaissent pas dans le répertoire
personnel du compte root, et que le courrier à destination des rôles
administratifs comme root, postmaster ou webmaster soient redirigés vers
un utilisateur approprié.
.ft P
.H 2 "/sbin : binaires systèmes (qui se trouvaient autrefois dans /etc)"
.P
Les utilitaires utilisés pour l'administration système (et autres
commandes faites uniquement pour root) sont stockés dans \f(CW/sbin\fP,
\f(CW/usr/sbin\fP et \f(CW/usr/local/sbin\fP. \f(CW/sbin\fP contient
typiquement des binaires essentiels au démarrage du système en plus des
binaires de \f(CW/bin\fP. Tout ce qui est exécuté après qu'il soit sûr
que \f(CW/usr\fP soit monté (quand il n'y a pas de problèmes) devrait
aller dans \f(CW/usr/sbin\fP. Les binaires d'administration système
spécifiques au système devraient être installés dans
\f(CW/usr/local/sbin\fP.
Décider de ce qui va dans les répertoires \f(CW"sbin"\fP est simple : si
un utilisateur normal (pas un administrateur système) doit le lancer
directement, il devrait alors aller dans l'un des répertoires
\f(CW"bin"\fP. Les utilisateurs ordinaires ne devraient mettre aucun des
répertoires \f(CWsbin\fP dans leur chemin d'accès (path).
.ft I
Note : par exemple, les fichiers tels que \f(CWchfn\fP que les
utilisateurs n'utilisent que de temps en temps devraient quand même être
placés dans \f(CW/usr/bin\fP. \f(CWping\fP, bien qu'il ne soit
absolument nécessaire que pour root (remise en état et diagnostic
réseau) est souvent utilisé par les utilisateurs et pour cette raison
devrait exister dans \f(CW/bin\fP.
.ft R
Nous recommandons que les utilisateurs aient les permissions de lecture
et d'exécution pour tout ce qui se trouve dans \f(CW/sbin\fP mis à part,
peut-être, certains programmes setuid et setgid. La division entre
\f(CW/bin\fP et \f(CW/sbin\fP n'a pas été créée pour des raisons de
sécurité ou pour empêcher les utilisateurs de voir le système
d'exploitation, mais pour fournir une bonne séparation entre les
binaires que tout le monde utilise et ceux qui sont tout d'abord
utilisés pour des tâches d'administration. Il n'y a pas d'avantage
spécifique pour la sécurité à rendre \f(CW/sbin\fP inaccessible aux
utilisateurs.
.HU "Fichiers obligatoires pour /sbin :"
.BL
.LI
Commandes générales :
.VL 2
.LI "\f(CW{"
clock, getty, init, update, mkswap, swapon, swapoff, telinit }\fP
.LE
.LI
Commandes d'extinction :
.VL 2
.LI "\f(CW{"
fastboot, fasthalt, halt, reboot, shutdown }\fP
.LE
.sp 0.5
(ou toute combinaison des fichiers ci-dessus, pourvu que
\f(CWshutdown\fP soit inclus.)
.LI
Commandes de gestion du système de fichiers :
.VL 2
.LI "\f(CW{"
fdisk, fsck, fsck.*, mkfs, mkfs.* }\fP
.LE
.sp 0.5
\f(CW*\fP = un ou plus parmi \f(CWext, ext2, minix, msdos, xia\fP et
peut-être d'autres
.LI
Commandes réseau :
.VL 2
.LI "\f(CW{"
ifconfig, route }\fP
.LE
.LE
.H 2 "/tmp : fichiers temporaires"
.P
Le répertoire \f(CW/tmp\fP devra êre mis à la disposition des programmes
qui ont besoin de créer des fichiers temporaires.
Bien que les données stockées dans \f(CW/tmp\fP puissent être effacées
d'une manière spécifique à chaque site, il est recommandé que les
fichiers et répertoires situés dans \f(CW/tmp\fP soient effacés à chaque
démarrage du système.
Les programmes ne devront pas supposer que tout fichier ou répertoire
de \f(CW/tmp\fP est préservé entre deux lancements de ces programmes.
.HU "Raison d'être :"
.br
.P
La norme IEEE P1003.2 (POSIX, partie 2) donne des obligations similaires
à la section ci-dessus.
\*(Fs a ajouté la recommandation du nettoyage de \f(CW/tmp\fP au
démarrage sur la base de précédents historiques et de pratique commune,
mais n'en a pas fait une obligation parce que l'administration système
n'entre pas dans l'objectif de cette norme.
.SK
.H 1 "La hiérarchie /usr"
.P
\f(CW/usr\fP est la deuxième grande partie du système de
fichiers. \f(CW/usr\fP contient des données partageables, en lecture
seule. Ceci veut dire qu'on devrait pouvoir partager \f(CW/usr\fP entre
plusieurs machines diverses se conformant à \*(Fs et on ne devrait pas y
écrire. Toute information spécifique à la machine ou qui varie avec le
temps est stockée autre part.
Aucun grand paquetage logiciel ne devrait utiliser un sous-répertoire
direct sous la hiérarchie \f(CW/usr\fP. Exception est faite du système X
Window à cause d'un énorme précédent et d'une pratique largement
suivie. Cette section de la norme spécifie l'emplacement de la plupart
de ces paquetages.
.PS
copy "draft.pic"
dir(/usr,hiérarchie secondaire)
sub("X11R6","Système X Window, version 11 release 6")
sub("X386","Système X Window, version 11 release 5 sur des plate-formes x86")
sub("bin","La plupart des commandes utilisateurs")
.\" old placement
.\" sub("g++-include","GNU C++ include files")
sub("games","Binaires de jeux et d'apprentissage")
sub("include","Fichiers d'en-têtes inclus par les programmes C")
sub("lib","Bibliothèques")
sub("local","Hiérarchie locale (vide après l'installation principale)")
sub("sbin","Binaires systèmes non essentiels")
sub("share","Données indépendantes de l'architecture")
sub("src","Code source")
.PE
Les liens symboliques vers les répertoires suivants peuvent être
présents. Cette possibilité est basée sur le besoin de préserver la
compatibilité avec les vieux systèmes jusqu'à ce qu'on soit sûr que
toutes les implémentations utilisent la hiérarchie \f(CW/var\fP.
.nf
.ft CW
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/usr/spool/locks -> /var/lock
.ft P
.fi
Une fois qu'un système n'a plus besoin de l'un des liens symboliques
ci-dessus, le lien peut être enlevé si désiré.
.SK
.H 2 "/usr/X11R6 : Système X Window, Version 11 Release 6"
.P
Cette hiérarchie est réservée au système X Window, version 11 release 6,
et aux fichiers apparentés.
Pour simplifier les choses et rendre XFree86 plus compatible avec le
système X Window sur les autres systèmes, les liens symboliques suivants
devraient être présents :
.nf
.ft CW
/usr/bin/X11 -> /usr/X11R6/bin
/usr/lib/X11 -> /usr/X11R6/lib/X11
/usr/include/X11 -> /usr/X11R6/include/X11
.ft P
.fi
.P
En général, les logiciels ne devraient pas être installés ou gérés par
l'intermédiaire de ces liens symboliques. Ils ne sont destinés qu'à une
utilisation par les utilisateurs. La difficulté est liée à la version de
sortie du système X Window \(em dans les périodes de transition, il est
impossible de savoir quelle version de X11 est en cours d'utilisation.
Les données spécifiques à la machine dans \f(CW/usr/X11R6/lib/X11\fP
devraient être prises comme des fichiers de démonstration. Les
applications ayant besoin d'informations sur la machine courante (grâce
à des fichiers comme \f(CWXconfig\fP, \f(CWXF86Config\fP ou
\f(CWsystem.twmrc\fP) doivent se référer à un fichier de configuration
dans \f(CW/etc/X11\fP, qui peut être un lien vers un fichier de
\f(CW/usr/X11R6/lib\fP.
.H 2 "/usr/X386 : système X Window, Version 11 Release 5, sur les plate-formes x86"
.P
Cette hiérarchie est en général identique à \f(CW/usr/X11R6\fP ; les
liens symboliques de \f(CW/usr\fP pour X11 devraient pointer vers la
version du système X Window désirée.
.H 2 "/usr/bin : la plupart des commandes utilisateurs"
.P
Voici le répertoire principal des commandes exécutables sur le système.
.PS
copy "draft.pic"
dir(/usr/bin,Binaires non nécessaires en mode utilisateur unique)
sub("mh","Commandes pour le système de gestion de courrier MH")
sub("X11","Lien symbolique vers \f(CW/usr/X11R6/bin\fP")
.PE
Les interpréteurs de scripts shell (qu'on lance avec \f(CW#!\fP
sur la première ligne d'un script shell) ne pouvant pas compter sur un
chemin, il est avantageux de normaliser leur emplacement. Les
interpréteurs du shell de Bourne et du shell C sont déjà fixés dans
\f(CW/bin\fP, mais on trouve souvent Perl, Python et Tcl dans maints
endroits différents. \f(CW/usr/bin/perl\fP, \f(CW/usr/bin/python\fP et
\f(CW/usr/bin/tcl\fP devraient faire référence respectivement aux
interpréteurs de shell \f(CWperl\fP, \f(CWpython\fP et \f(CWtcl\fP. Il
peut y avoir des liens symboliques vers l'emplacement véritable des
interpréteurs shell.
.SK
.H 2 "/usr/include : répertoire pour les fichiers d'en-têtes standards."
.P
Voici l'endroit où tous les fichiers d'en-têtes à usage général pour les
langages de programmation C et C++ devraient être placés.
.PS
copy "draft.pic"
dir(/usr/include,fichiers d'en-têtes)
sub("X11","lien symbolique vers \f(CW/usr/X11R6/include/X11\fP")
sub("bsd","fichiers d'en-têtes de compatibilité BSD (si nécessaire)")
sub("g++","fichiers d'en-têtes pour le GNU C++")
.PE
.H 2 "/usr/lib : bibliothèques pour la programmation et les paquetages"
.P
\f(CW/usr/lib\fP contient des fichiers objets, des bibliothèques et des
binaires internes qui ne sont pas destinés à être exécutés par les
utilisateurs ou les scripts shell.
Les applications peuvent utiliser un sous-répertoire unique sous
\f(CW/usr/lib\fP. Si une application utilise un sous-répertoire, toutes
les données dépendantes de l'architecture utilisées exclusivement par
cette application devraient être placées dans ce sous-répertoire. Par
exemple, le sous-répertoire \f(CWperl5\fP pour les modules et les
bibliothèques de Perl 5.
Les fichiers et répertoires divers, statiques, indépendants de
l'architecure et spécifiques à une application devraient aller dans
\f(CW/usr/share\fP.
Certaines commandes exécutables telles que \f(CWmakewhatis\fP et
\f(CWsendmail\fP ont aussi été placées de manière traditionnelle dans
\f(CW/usr/lib\fP. \f(CWmakewhatis\fP est un binaire interne et devrait
être placé dans un répertoire de binaires ; les utilisateurs accèdent
uniquement à \f(CWcatman\fP. Les nouveaux binaires \f(CWsendmail\fP sont
maintenant placés par défaut dans \f(CW/usr/sbin\fP ; un lien symbolique
devrait rester de \f(CW/usr/lib\fP. En plus, les systèmes qui utilisent
Smail devraient placer Smail dans \f(CW/usr/sbin/smail\fP et
\f(CW/usr/sbin/sendmail\fP devrait être un lien symbolique vers
celui-ci.
Un lien symbolique \f(CW/usr/lib/X11\fP pointant vers le répertoire
\f(CWlib/X11\fP de la distribution X par défaut est nécessaire si X est
installé.
.\" XXX - Chris a effacé ceci. Peut-être le réduire à une phrase ?
.\"
.ft I
Note : aucune donnée spécifique à la machine pour le système X Window ne
devrait être stocké dans \f(CW/usr/lib/X11\fP. Les fichiers de
configuration spécifiques à la machine tels que \f(CWXconfig\fP ou
\f(CWXF86Config\fP devraient exister dans \f(CW/etc/X11\fP. Ceci devrait
comprendre les données de configuration tels que \f(CWsystem.twmrc\fP
même si l'on n'en fait qu'un lien symbolique vers un fichier de
configuration plus global (probablement dans \f(CW/usr/X11R6/lib/X11\fP).
.ft P
.H 2 "/usr/local : hiérarchie locale"
.P
La hiérarchie \f(CW/usr/local\fP est destinée à l'utilisation de
l'administrateur système quand il installe des logiciels en local. Il
doit être mis à l'abri de tout effacement lors de la mise à jour du
logiciel système. On peut l'utiliser pour des programmes et des données
qu'on peut partager parmi un groupe de machines, mais qu'on ne trouve
pas dans \f(CW/usr\fP.
.PS
copy "draft.pic"
dir(/usr/local,Hiérarchie locale)
sub("bin","Binaires locaux")
sub("games","Binaires de jeux locaux")
sub("include","Fichiers d'en-têtes C locaux")
sub("lib","Bibliothèques locales")
sub("sbin","Binaires système locaux")
sub("share","Hiérarchie indépendante de la machine locale")
sub("src","Code source local")
.PE
Ce répertoire devrait toujours être vide après la première installation
d'un système se conformant à la \*(Fs. Aucune exception à cette règle ne
devrait être faite à part les morceaux de répertoires listés.
Les logiciels installés localement devraient être placés dans
\f(CW/usr/local\fP plutôt que dans \f(CW/usr\fP sauf si on l'installe
pour remplacer ou mettre à jour un logiciel de \f(CW/usr\fP.
Notez que les logiciels placés dans \f(CW/\fP ou \f(CW/usr\fP peuvent
être écrasés par les mises à jour systèmes (bien que nous recommandons
que les distributions n'écrasent pas les données de \f(CW/etc\fP dans
ces circonstances). Pour cette raison, les logiciels locaux ne devraient
pas aller en dehors de \f(CW/usr/local\fP sans bonne raison.
.H 2 "/usr/sbin : binaires systèmes normaux non essentiels"
.P
Ce répertoire contient tous les binaires non essentiels utilisés
exclusivement par l'administrateur système. Les programmes
d'administration système nécessaires à la réparation du système, sa
remise en route, le montage de \f(CW/usr\fP ou d'autres fonctions
essentielles devraient plutôt être placés dans \f(CW/sbin\fP.
.\" XXX - Chris a barré les deux paragraphes suivants. Effacer ?
Typiquement, \f(CW/usr/sbin\fP contient les daemons réseau, tous les
outils d'administration non essentiels et les binaires pour les
programmes serveurs non critiques.
.\" Je ne suis pas sûr de devoir recommander ce paragraphe -
.\" il semble hors de notre portée - iwj
Ces programmes serveurs sont utilisés à l'entrée dans l'état System V
connu sous le nom de "run level 2" (état multi-utilisateurs) et "run
level 3" (état en réseau) ou dans l'état BSD connu sous le nom de "mode
multi-utilisateurs". À ce point le système met certains services à la
disposition des utilisateurs (par exemple, les impressions) et d'autres
machines (par exemple, les exports NFS).
Les programmes d'administration système installés en local devraient
être placés dans \f(CW/usr/local/sbin\fP.
.H 2 "/usr/share : données indépendantes de l'architecture"
.P
.PS
copy "draft.pic"
dir(/usr/share,Données indépendantes de l'architecture)
sub("dict","Listes de mots")
sub("doc","Documentations diverses")
sub("games","Fichiers de données statiques pour \f(CW/usr/games\fP")
sub("info","Répertoire principal du système Info de GNU")
sub("locale","Informations pour Locale")
sub("man","Pages de manuel en ligne")
sub("nls","Support pour la langue natale")
sub("misc","Données diverses indépendantes de la machine")
sub("terminfo","Répertoires pour la base de données terminfo")
sub("tmac","Macros troff non distribuées avec groff")
sub("zoneinfo","Information et configuration pour le fuseau horaire")
.PE
La hiérarchie \f(CW/usr/share\fP contient tous les fichiers de données
indépendantes de l'architecture en lecture seule. La plupart de ces
données se trouvaient à l'origine dans \f(CW/usr\fP (\f(CWman\fP,
\f(CWdoc\fP) ou \f(CW/usr/lib\fP (\f(CWdict\fP, \f(CWterminfo\fP,
\f(CWzoneinfo\fP). Cette hiérarchie est destinée à être partagée entre
toutes les plate-formes et architectures pour un système d'exploitation
donné ; ainsi, par exemple, un site avec des plate-formes i386, Alpha et
PPC peut maintenir un seul répertoire \f(CW/usr/share\fP qui est monté
de manière centrale. Notez, cependant, que \f(CW/usr/share\fP n'est en
général pas fait pour être partagé par des systèmes d'exploitation
différents ou par différentes versions du même système d'exploitation.
Tout programme ou paquetage qui contient ou nécessite des données qui
n'ont pas besoin d'être modifiées devrait stocker ces données dans
\f(CW/usr/share\fP (ou \f(CW/usr/local/share\fP en cas d'installation
locale). Il est recommandé d'utiliser un sous-répertoire de
\f(CW/usr/share\fP à cet effet.
Notez que Linux utilise pour le moment des fichiers de bases de données
au format DBM. Bien que ceux-ci ne soient pas indépendants de
l'architecture, ils sont autorisés dans \f(CW/usr/share\fP en
anticipation d'un passage au format DB 2.0 indépendant de
l'architecture.
Les données de jeux stockées dans \f(CW/usr/share/games\fP devraient
être des données purement statiques. Tout fichier modifiable, comme les
fichiers de scores, les enregistrements de parties et ainsi de suite,
devraient être placés dans \f(CW/var/games\fP.
Il est recommandé que les répertoire spécifiques à une application,
indépendants de l'architecture soient placés ici. De tels répertoires
comprennent \f(CWgroff\fP, \f(CWperl\fP, \f(CWghostscript\fP,
\f(CWtexmf\fP et \f(CWkbd\fP (Linux) ou \f(CWsyscons\fP (BSD). Ils
peuvent, cependant, être placés dans \f(CW/usr/lib\fP pour des raisons
de compatibilité ascendante, à la discrétion du distributeur. De même,
une hiérarchie \f(CW/usr/lib/games\fP peut être utilisée en plus de la
hiérarchie \f(CW/usr/share/games\fP si le distributeur désire placer
quelques données de jeux à cet endroit.
.\"
.\" Note les fichiers de support de groff devraient être installés dans
.\" /usr/share/groff pour simplifier la mise à jour de groff sur les
.\" systèmes Linux, plutôt que la distribution des fichiers groff que
.\" l'on trouve sur les systèmes BSD actuels.
.H 3 "/usr/share/dict : listes de mots"
.sp
.HU "Fichiers recommandés pour /usr/share/dict :"
.VL 2
.LI "\f(CW{"
words }\fP
.LE
.P
Traditionnellement, ce répertoire ne contient que le fichier anglais
\f(CWwords\fP, utilisé par \f(CWlook(1)\fP et divers programmes de
correction orthographique. \f(CWwords\fP peut utiliser l'orthographe
américaine ou britannique. Les sites qui veulent les deux peuvent faire
un lien \f(CWwords\fP vers \f(CW\%/usr/share/dict/american-english\fP ou
\f(CW\%/usr/share/dict/british-english\fP.
On peut ajouter des listes de mots pour d'autres langues en utilisant le
nom anglais de cette langue, par exemple \f(CW/usr/share/dict/french\fP,
\f(CW/usr/share/dict/danish\fP, etc. Ils devraient, si possible,
utiliser un jeu de caractères ISO 8859 approprié à la langue en question
; si possible en utilisant le jeu de caractères Latin1 (ISO 8859-1) --
ce n'est souvent pas possible.
D'autres listes de mots, comme le "dictionnaire" \f(CWweb2\fP devraient
y être inclus, s'ils existent.
.HU "Raison d'être :"
.br
.P
La raison pour laquelle seules les listes de mots sont situées ici est
que ce sont les seuls fichiers communs à tous les correcteurs
d'orthographe.
.H 3 "/usr/share/man : pages de manuel"
.sp
Cette section parcourt en détails l'organisation des pages de manuel
pour le système entier, en incluant
\f(CW/usr/share/man\fP. Reportez-vous aussi à la section sur
\f(CW/var/cache/man\fP.
Les pages de manuel sont stockées dans
\f(CW//man/\fP. \f(CW\fP,
\f(CW\fP, \f(CW\fP et \f(CW\fP sont expliqués
ci-dessous.
.PS
copy "draft.pic"
dir(/,Hiérarchie de pages de manuel)
sub("man1","Programmes utilisateurs")
sub("man2","Appels système")
sub("man3","Appels de bibliothèque")
sub("man4","Fichiers spéciaux")
sub("man5","Formats de fichiers")
sub("man6","Jeux")
sub("man7","Divers")
sub("man8","Administration système")
.PE
Le \f(CW\fP principal du système est
\f(CW/usr/share/man\fP. \f(CW/usr/share/man\fP contient des informations
du manuel pour les commandes et les données des systèmes de fichiers
\f(CW/\fP et \f(CW/usr\fP. Évidemment, il n'y a pas de pages de manuel
dans \f(CW/\fP parce qu'elles ne sont pas utiles au démarrage ni dans
les situations d'urgence.
La \f(CW\fP décrit la section du manuel.
Il faut s'assurer de faire de la place dans la structure de
\f(CW/usr/share/man\fP pour supporter les pages de manuel écrites en des
langues différentes (ou multiples). Cette place doit prendre en compte
le stockage et la référence à ces pages de manuel. Les facteurs
pertinents comprennent la langue (avec les différences géographiques),
et le codage des caractères.
Le nommage des sous-répertoires spécifiques à la langue dans
\f(CW/usr/share/man\fP est basé sur l'annexe E de la norme POSIX 1003.1
qui décrit la chaîne d'identification locale \(em la méthode la mieux
acceptée pour décrire un environnement culturel. La chaîne
\f(CW\fP est :
.P 1
\f(CW[_][.][,]\fP
Le champ \f(CW\fP sera tiré d'ISO 639 (un code de représentation
des noms de langues). Il sera constitué de deux caractères et spécifié
en lettres minuscules uniquement.
Le champ \f(CW\fP sera le code à deux lettres d'ISO 3166
(spécification des représentations de pays) si possible. (La plupart des
personnes sont familières avec les codes à deux lettres utilisées pour
les codes de pays des adresses électroniques.\*F) Il sera constitué de
deux caractères spécifiés en lettres majuscules uniquement.
.FS
Une exception majeure à cette règle est le Royaume Uni, qui est `GB'
dans ISO 3166, mais `UK' pour la plupart des adresses électroniques.
.FE
Le champ \f(CW\fP devrait représenter la norme décrivant
le code de caractères. Si le champ \f(CW\%\fP est une
simple indication numérique, le nombre représente le numéro de la norme
internationale décrivant le code de caractères. Il est recommandé que ce
soit une représentation numérique si possible (surtout pour les normes
ISO), qu'il n'inclue pas de symboles de ponctuation supplémentaires et
que toute lettre soit en minuscule.
Un paramètre spécifiant la \f(CW\fP du profil peut être placé
après le champ \f(CW\%\fP, séparé par une virgule. Ceci
peut servir à différencier plusieurs besoins culturels ; par exemple,
l'ordre du dictionnaire comparé à un ordre d'assemblage plus orienté
systèmes. Cette norme recommande de ne pas utiliser le champ
\f(CW\fP, sauf si c'est nécessaire.
Les systèmes utilisant une langue et un code de caractères uniques pour
toutes les pages de manuel peuvent omettre la sous-chaîne
\f(CW\fP et stocker toutes les pages de manuel dans
\f(CW\fP. Par exemple, les systèmes qui n'ont que les pages de
manuel en anglais codées en ASCII peuvent stocker ces pages (les
répertoires \f(CWman\fP) directement dans
\f(CW/usr/share/man\fP. (Ce qui représente, en fait, la disposition et
les circonstances habituelles.)
Les pays pour lesquels un ensemble de codes de caractères standard bien
accepté existe peuvent omettre le champ \f(CW\%\fP, mais
il est fortement recommandé de l'inclure, surtout pour les pays ayant
plusieurs normes en compétition.
Quelques exemples :
.TS
l l l l
l l l lfCW.
Langue Territoire Code de caractère Répertoire
_
Anglais \(em ASCII /usr/share/man/en
Anglais Royaume Uni ASCII /usr/share/man/en_GB
Anglais États-Unis ASCII /usr/share/man/en_US
Français Canada ISO 8859-1 /usr/share/man/fr_CA
Français 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
.TE
De même, il faut faire de la place pour les pages de manuel dépendant de
l'architecture, comme la documentation sur les pilotes de périphériques
ou les commandes d'administration système de bas niveau. Elles devraient
être placées dans un répertoire \f(CW\fP dans le répertoire
\f(CWman\fP approprié ; par exemple, une page de manuel pour la
commande i386 ctrlaltdel(8) peut être placée dans
\f(CW/usr/share/man//man8/i386/ctrlaltdel.8\fP.
Les pages de manuel pour les commandes et les données de
\f(CW/usr/local\fP sont stockées dans \f(CW/usr/local/man\fP. Les pages
de manuel pour X11R6 sont stockées dans \f(CW/usr/X11R6/man\fP. Il
s'ensuit que toutes les hiérarchies de pages de manuel du système
devraient avoir la même structure que \f(CW/usr/share/man\fP. Les
répertoires vides peuvent être oubliés d'une hiérarchie de pages de
manuel. Par exemple, si \f(CW/usr/local/man\fP n'a pas de pages de
manuel pour la section 4 (périphériques), alors
\f(CW/usr/local/man/man4\fP peut être omis.
Les sections de pages cat (\f(CWcat\fP) contenant des entrées
de pages de manuel formatées se trouvent aussi dans les sous-répertoires
de \f(CW/\fP, mais ne sont pas obligatoires ni ne
devraient être distribuées à la place des pages de manuel en source nroff.
.\" d'autres sous-répertoires, ps, dvi, html
.\" pourront y être ajoutés
.\" à revoir
Les sections numérotées "1" à "8" sont définies de manière
traditionnelle. En général, le nom de fichier des pages de manuel
situées dans une section particulière se termine par \f(CW.\fP.
De plus, certains grands ensembles de pages de manuel spécifiques à une
application possèdent un suffixe supplémentaire accolé au nom de fichier
de la page de manuel. Par exemple, les pages de manuel du système de
gestion de courrier MH devraient avoir \f(CWmh\fP accolé à toutes les
pages de manuel de MH. Toutes les pages de manuel du système X Window
devraient avoir un \f(CWx\fP accolé au nom de fichier.
La pratique de placer les pages de manuel de diverses langues dans les
sous-répertoires appropriés de \f(CW/usr/share/man\fP s'applique aussi
aux autres hiérarchies de pages de manuel, comme \f(CW/usr/local/man\fP
et \f(CW/usr/X11R6/man\fP. (Cette partie de la norme s'appliquera aussi
plus loin dans la section sur la structure optionnelle
\f(CW/var/cache/man\fP.)
Voici une description de chaque section :
.BL
.LI
\f(CWman1\fP : programmes utilisateurs
.br
Les pages de manuel décrivant les commandes accessibles à tous se
trouvent dans ce chapitre. La majeure partie de la documentation sur les
programmes dont aura jamais besoin un utilisateur se trouve ici.
.LI
\f(CWman2\fP : appels système
.br
Cette section décrit tous les appels systèmes (requêtes au noyau pour
effectuer des opérations).
.\" enlever la remarque entre parenthèses ? supposer les connaissances
.\" techniques ?
.LI
\f(CWman3\fP : fonctions et routines de la bibliothèque
.br
La section 3 décrit les routines du programme de la bibliothèque qui ne
sont pas des appels directs aux services du noyau. Ceci ainsi que le
chapitre 2 ne sont vraiment intéressants que pour les programmeurs.
.LI
\f(CWman4\fP : fichiers spéciaux
.br
La section 4 décrit les fichiers spéciaux, les fonctions spécifiques aux
pilotes et le support réseau disponible sur le système. On y trouve
typiquement les fichiers de périphériques de \f(CW/dev\fP et l'interface
noyau pour le support des protocoles réseau.
.LI
\f(CWman5\fP : formats de fichiers
.br
Le format de nombreux fichiers de données non intuitifs est documenté
dans la section 5. Ceci comprend divers fichiers d'en-têtes, les
fichiers de résultats de programmes et les fichiers systèmes.
.LI
\f(CWman6\fP : jeux
.br
Ce chapitre documente les jeux, les démonstrations et des programmes en
général triviaux. Des personnes différentes ont des notions variées sur
l'opportunité de cette partie.
.LI
\f(CWman7\fP : divers
.br
Les pages de manuel difficiles à classer sont placées dans la section
7. Les paquetages de macros pour troff et autres processeurs de texte se
trouvent ici.
.LI
\f(CWman8\fP : administration système
.br
La documentation pour les programmes utilisés par les administrateurs
système pour la bonne marche du système et sa maintenance se trouve
ici. Certains de ces programmes sont aussi utiles de temps à autre pour
les utilisateurs normaux.
.LE
.H 3 "/usr/share/misc : diverses données indépendantes de l'architecture"
.P
Ce répertoire contient divers fichiers indépendants de l'architecture
qui ne nécessitent pas un sous-répertoire séparé dans
\f(CW/usr/share\fP. C'est un répertoire obligatoire de
\f(CW/usr/share\fP.
Les fichiers suivants, s'ils sont présents, devraient se trouver dans
\f(CW/usr/share/misc\fP :
.VL 2
.LI "\f(CW{"
ascii, magic, termcap, termcap.db }\fP
.LE
D'autres fichiers (spécifiques à une application) peuvent apparaître
ici, mais un intégrateur peut les placer dans \f(CW/usr/lib\fP à sa
discrétion. De tels fichiers comprennent :
.VL 2
.LI "\f(CW{"
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 }\fP
.LE
.H 2 "/usr/src : code source"
.P
Tout code source non local devrait être placé dans ce sous-répertoire.
.SK
.H 1 "La hiérarchie /var"
.PS
copy "draft.pic"
dir(/var,Données variables)
sub("account","Historique de la comptabilité des processus (si supporté)")
sub("cache","Données de cache des applications")
sub("crash","Données brutes des plantages système (si supporté)")
sub("games","Données variables des jeux")
sub("lock","Fichiers de verrous")
sub("log","Fichiers et répertoires d'historique")
sub("mail","Fichiers de boîtes aux lettres utilisateurs")
sub("opt","Données variables de /opt")
sub("run","Fichiers relatifs aux processus en cours")
sub("spool","Données en attente pour les applications")
sub("state","Informations variables d'état")
sub("tmp","Fichiers temporaires préservés entre les redémarrages du système")
sub("yp","fichiers de base de données de NIS (Network Information Service)")
.PE
.P
\f(CW/var\fP contient des fichiers de données variables. Ceci inclut les
répertoires et fichiers en attente (spool), les données administratives
et d'historique, et les fichiers transitoires et temporaires.
Certaines parties de \f(CW/var\fP ne sont pas partageables entre des
systèmes différents. Par exemple, \f(CW/var/log\fP, \f(CW/var/lock\fP et
\f(CW/var/run\fP. D'autres parties peuvent être partagées, comme
notamment \f(CW/var/mail\fP, \f(CW/var/cache/man\fP,
\f(CW/var/cache/fonts\fP et \f(CW/var/spool/news\fP.
\f(CW/var\fP est ici spécifié afin de rendre possible le montage de
\f(CW/usr\fP en lecture seule. Tout ce qui allait auparavant dans
\f(CW/usr\fP sur lequel on écrivait pendant la marche du système (au
contraire de l'installation et de la maintenance logicielle) doit aller
dans \f(CW/var\fP.
Si on ne peut pas faire de \f(CW/var\fP une partition séparée, il est
souvent préférable de déplacer \f(CW/var\fP hors de la partition racine
à l'intérieur de la partition \f(CW/usr\fP. (Ceci est parfois effectué
pour réduire la taille de la partition racine ou quand l'espace se
réduit dans la partition racine.) Cependant, \f(CW/var\fP ne devrait pas
être un lien vers \f(CW/usr\fP parce que cela rend la séparation de
\f(CW/usr\fP et \f(CW/var\fP plus difficile et rend plus probable la
création d'un conflit de noms. À la place, faites un lien de
\f(CW/var\fP vers \f(CW/usr/var\fP.
Les applications ne devraient en général pas ajouter de répertoire au
niveau supérieur de \f(CW/var\fP. De tels répertoires ne devraient être
ajoutés que s'ils concernent le système en entier, et en consultant la
liste de distribution \*(Fs.
Les répertoires \f(CWcache\fP, \f(CWlock\fP, \f(CWlog\fP, \f(CWrun\fP,
\f(CWspool\fP, \f(CWstate\fP et \f(CWtmp\fP doivent être inclus et
utilisés dans toutes les distributions ; les répertoires
\f(CWaccount\fP, \f(CWcrash\fP, \f(CWgames\fP, \f(CWmail\fP et
\f(CWyp\fP doivent être inclus et utilisés si les applications ou
possibilités correspondantes sont fournies dans la distribution.
Les versions précédentes de la FSSTND incluaient une hiérarchie
\f(CW/var/lib\fP. Pour plus d'informations, voir la section sur
\f(CW/var/state\fP.
Plusieurs répertoires sont `réservés' dans le sens où ils ne devraient
pas être utilisés de façon arbitraire par une application nouvelle,
puisqu'ils entreraient en conflit avec une pratique historique et/ou
locale. Ce sont :
.nf
.ft CW
/var/backups
/var/cron
/var/lib
/var/local
/var/msgs
/var/preserve
.ft P
.fi
.H 2 "/var/account : historique de la comptabilité des processus (si supporté)"
.P
Ce répertoire contient l'historique en cours de la comptabilité des
processus et les données composées d'utilisation des processus (utilisés
dans certains système \*(Ux par \f(CWlastcomm\fP et \f(CWsa\fP).
.H 2 "/var/cache : données de cache des applications"
.P
.PS
copy "draft.pic"
dir(/var/cache,répertoires de cache)
sub("fonts","fontes générées en local")
sub("man","pages de manuel formatées en local")
sub("www","données de cache ou de proxy WWW")
sub("","données de cache spécifiques à paquetage")
.PE
\f(CW/var/cache\fP est fait pour les données de cache des
applications. De telles données sont générées localement comme résultat
d'entrées-sorties ou de calculs qui prennent du temps. L'application
doit être capable de regénérer ou de retrouver les données. À la
différence de \f(CW/var/spool\fP, les fichiers cachés peuvent être
effacés sans perte de données. Les données doivent rester valides entre
deux lancements de l'application et après le redémarrage du système.
Les fichiers situés dans /var/cache peuvent expirer d'une manière
spécifique à l'application, par l'administrateur système ou des deux
manières. L'application devrait toujours être capable de s'en remettre
suite à un effacement manuel des fichiers (généralement à cause d'un
manque d'espace disque). Aucune autre obligation n'est faite concernant
le format des données dans les répertoires de cache.
.HU "Raison d'être :"
.br
.P
L'existence d'un répertoire séparé pour les données de cache permet aux
administrateurs système d'attribuer une politique de disque et de
sauvegarde différente des autres répertoires de \f(CW/var\fP.
.H 3 "/var/cache/fonts : fontes générées en local"
.P
Le répertoire \f(CW/var/cache/fonts\fP devrait êre utilisé pour stocker
toute fonte créée de manière dynamique. En particulier,
\f(CW/var/cache/fonts/pk\fP stockera toutes les fontes automatiquement
générées par \f(CWMakeTeXPK\fP.
Il devrait y avoir un lien de \f(CW/usr/lib/texmf/fonts/tmp\fP vers
\f(CW/var/cache/fonts\fP. Ce lien permet aux utilisateurs d'utiliser le
chemin unique \f(CW/usr/lib/texmf/fonts/tfm\fP quand ils effectuent des
changements à leur variable d'environnement TEXFONTS. (Ceci est le
chemin par défaut pour les outils \*(Tx de Karl Berry, distribués sur
\f(CWftp.cs.umb.edu:/pub/tex\fP.\*F
.FS
La raison pour laquelle les outils de Karl Berry sont mentionnés est
qu'ils sont le standard de-facto pour les installations \*(Ux de
\*(Tx. Ces outils sont largement utilisés dans la communauté \*(Ux
libre.
.FE
Si une autre distribution \*(Tx est utilisée, un lien du répertoire de
fontes approprié vers \f(CW/var/cache/fonts\fP devrait être fait.)
Le \f(CWMakeTeXPK\fP distribué avec \f(CWdvipsk\fP placera les
fichiers \f(CW.pk\fP dans \f(CWfonts/pk//\fP (par
exemple, \f(CWfonts/pk/CanonCX/cmr10.300pk\fP). Les fichiers \f(CW.pk\fP
peuvent être périodiquement purgés de l'arborescence
\f(CW/var/cache/fonts\fP ou peuvent être déplacés dans l'arborescence
\f(CW/usr/lib/texmf\fP. Si des générateurs automatiques de \f(CW.mf\fP
ou \f(CW.tfm\fP sont utilisés, ils devraient placer leurs données dans
les sous-répertoires \f(CWmf\fP ou \f(CWtfm\fP de
\f(CW/var/cache/fonts\fP.
D'autres fontes créées dynamiquement peuvent aussi être placées dans
cette arborescence, dans des sous-répertoires de
\f(CW/var/cache/fonts\fP nommés de manière adéquate.
.H 3 "/var/cache/man : pages de manuel formatées en local (optionnel)"
.P
Ce répertoire fournit un emplacement standard pour les sites qui
fournissent une partition \f(CW/usr\fP en lecture seule, mais qui
veulent permettre le cache des pages de manuel formatées en local. Les
sites qui montent \f(CW/usr\fP en écriture (par exemple, les
installations en utilisateur unique) peuvent choisir de ne pas utiliser
\f(CW/var/cache/man\fP et peuvent écrire les pages de manuel formatées
dans les répertoires \f(CWcat\fP directement dans
\f(CW/usr/share/man\fP. Nous recommandons que la plupart des sites
utilisent plutôt l'une des options suivantes :
.BL
.LI
Préformater toutes les pages de manuel à côté des versions non formatées.
.LI
Ne permettre aucun cache des pages de manuel formatées et obliger à
refaire le formatage à chaque utilisation d'une page de manuel.
.LI
Permettre le cache local des pages de manuel formatées dans
\f(CW/var/cache/man\fP.
.LE
.P
La structure de \f(CW/var/cache/man\fP nécessite de refléter à la fois
les hiérarchies multiples de pages de manuel et la possibilité d'un
support multilingue.
Étant donnée une page de manuel non formatée qui apparaît normalement
dans \f(CW/man//man\fP, le répertoire pour
placer les pages de manuel formatées s'appelle
\f(CW/var/cache/man///cat\fP, où
\f(CW\fP s'inspire de \f(CW\fP en enlevant toute
composante de nom de chemin \f(CWusr\fP au début et/ou \f(CWshare\fP à la
fin. (Notez que la composante \f(CW\fP peut ne pas être présente.)
.\" Notez que /usr/local/man et /local/man entreront en conflit si un
.\" administrateur système est assez timbré pour utiliser les deux pour
.\" des choses différentes.
Par exemple, \f(CW/usr/share/man/man1/ls.1\fP sera formatée en
\f(CW/var/cache/man/cat1/ls.1\fP et
\f(CW/usr/X11R6/man//man3/XtClass.3x\fP en
\f(CW/var/cache/man/X11R6//cat3/XtClass.3x\fP.
Les pages de manuel écrites dans \f(CW/var/cache/man\fP peuvent à la fin
être transférées vers les répertoires préformatés appropriés dans la
hiérarchie source \f(CWman\fP ou bien expirées ; De même, les pages
de manuel formatées dans la hiérarchie source \f(CWman\fP peuvent être
expirées si personne n'y a accédé pendant une certaine période de temps.
Si les pages de manuel préformatées sont distribuées avec un système sur
des supports en lecture seule (un CD-ROM, par exemple), elles seront
installées dans la hiérarchie source \f(CWman\fP (par exemple
\f(CW/usr/share/man/cat\fP). \f(CW/var/cache/man\fP est réservé
comme cache dans lequel on peut écrire les pages de manuel
formatées.
.HU "Raison d'être :"
.br
.P
La version 1.2 de la norme spécifiait \f(CW/var/catman\fP pour cette
hiérarchie. Le chemin a été changé en \f(CW/var/cache\fP pour mieux
refléter la nature dynamique des pages de manuel formatées. Le nom du
répertoire a été changé en \f(CWman\fP pour permettre l'agrandissement
de la hiérarchie et inclure des formats traités autres que "cat", comme
PostScript, HTML ou DVI.
.H 2 "/var/crash : données brutes des plantages système (si supporté)"
.P
Ce répertoire contient des données brutes (dump) des plantages
système. À la date de la sortie de cette norme, les données brutes de
plantage système n'étaient pas supportés par Linux.
.H 2 "/var/games : données variables des jeux"
.P
Toute donnée variable concernant les jeux de \f(CW/usr\fP devrait être
placée ici. \f(CW/var/games\fP devrait contenir les données variables
qu'on trouvait auparavant dans \f(CW/usr\fP ; Les données statiques
telles que les textes d'aide, les descriptions de niveaux et ainsi de
suite devraient rester autre part, comme dans \f(CW/usr/share/games\fP.
Comme pour \f(CW/var/state\fP, les données variables des jeux peuvent
être placées dans \f(CW/var/lib\fP en tant que mesure de transition
obsolète. Cependant, cette permission sera levée dans une version future
de la norme.
.HU "Raison d'être :"
.br
.P
On a donné une hiérarchie \f(CW/var/games\fP à part entière, plutôt que
de le laisser mélangé avec l'ancien \f(CW/var/lib\fP comme dans la
version 1.2. La séparation permet un contrôle local des stratégies de
sauvegarde, permissions et utilisation des disques, ainsi que de
permettre un partage inter-machines et de réduire l'encombrement de
\f(CW/var/state\fP. De plus, \f(CW/var/games\fP est le chemin utilisé
traditionnellement par BSD.
.H 2 "/var/lock : fichiers de verrous"
.P
Les fichiers de verrous devraient être stockés dans la structure de
répertoires \f(CW/var/lock\fP.
Les fichiers de verrous de périphériques, tels les fichiers de verrous
du périphérique série qu'on trouvait d'habitude soit dans
\f(CW/usr/spool/locks\fP soit dans \f(CW/usr/spool/uucp\fP doivent
maintenant être stockés dans \f(CW/var/lock\fP. La convention de nommage
à utiliser est
.ie t \{\
\f(CWLCK..\fP suivi du nom de base du périphérique. Par exemple, pour
verrouiller \f(CW/dev/cua0\fP le fichier \f(CWLCK..cua0\fP serait créé.
\}
.el \{\
"LCK.." suivi du nom de base du périphérique. Par exemple, pour
verrouiller /dev/cua0 le fichier "LCK..cua0" serait créé.
\}
Le format utilisé pour les fichiers de verrous de périphérique doit être
le format de fichier de verrou HDB UUCP. Le format HDB permet de stocker
l'identificateur du processus (PID) comme un nombre décimal 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
caractères : espace, espace, espace, espace, espace, espace, un, deux,
trois, zéro et nouvelle ligne.
.\" Certaines versions d'UUCP ajoutent une deuxième ligne indiquant quel
programme a créé le verrou (uucp, cu ou getty).
Alors, tout ce qui voudrait utiliser \f(CW/dev/cua0\fP peut lire le
fichier de verrou et agir en conséquence (tous les verrous de
\f(CW/var/lock\fP devraient être lisibles par tout le monde).
.H 2 "/var/log : fichiers et répertoires d'historique"
.P
Le répertoire contient divers fichiers d'historique (log). La plupart
des historiques devraient être écrits dans ce répertoire ou dans un
sous-répertoire approprié.
.TS
tab(@);
lfCW l.
lastlog@enregistrement du dernier login de chaque utilisateur
messages@messages système de \f(CWsyslogd\fP
wtmp@enregistrement de chaque login et logout
.TE
.H 2 "/var/mail : fichiers de boîtes aux lettres utilisateurs"
.P
Ce répertoire contient les fichiers de boîtes aux lettres utilisateurs
stockés dans le format de boîtes aux lettres \*(Ux standard.
.HU "Raison d'être :"
.br
.P
Ce répertoire a été relogé de \f(CW/var/spool/mail\fP pour amener \*(Fs
en accord avec la plupart des implémentations \*(Ux. Ce changement est
important pour l'interopérabilité puisqu'un \f(CW/var/mail\fP unique est
souvent partagé entre plusieurs machines et plusieurs implémentations
d'\*(Ux (malgré les problèmes de verrouillage NFS).
.H 2 "/var/opt : données variables de /opt"
.P
Les données variables devraient être installées dans
\f(CW/var/opt/\fP, où \f(CW\fP est le nom de la
sous-arborescence de \f(CW/opt\fP où les données statiques de tout
paquetage logiciel supplémentaire sont stockées, sauf quand elles sont
supplantées par un autre fichier dans \f(CW/etc\fP. Aucune structure
n'est imposée sur la disposition interne de
\f(CW/var/opt/\fP.
.HU "Raison d'être :"
.br
.P
Voir la raison d'être pour \f(CW/opt\fP.
.H 2 "/var/run : fichiers variables d'exécution"
.P
Ce répertoire contient des fichiers d'information système décrivant le
système depuis qu'il a démarré. Les fichiers de ce répertoire devraient
être nettoyés (enlevés ou tronqués selon le cas) au début du processus
de démarrage.
Les fichiers d'identification de processus (PID), qui étaient placés à
l'origine dans \f(CW/etc\fP, devraient être placés dans
\f(CW/var/run\fP. La convention de nommage des fichiers PID est
\f(CW.pid\fP. Par exemple, le fichier PID de
\f(CWcrond\fP est nommé \f(CW/var/run/crond.pid\fP.
Le format interne des fichiers PID reste inchangé. Le fichier consiste
en un identificateur de processus en décimal codé ASCII, suivi d'un
caractère nouvelle ligne. Par exemple, si \f(CWcrond\fP était le
processus numéro 25, \f(CW/var/run/crond.pid\fP contiendrait trois
caractères : 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 supplémentaires, les zéros au début, l'absence d'une
nouvelle ligne à la fin ou les lignes supplémentaires dans le fichier
PID. Les programmes qui créent des fichiers PID devraient utiliser la
spécification simple située dans le paragraphe ci-dessus.
Le fichier \f(CWutmp\fP, qui stocke les informations sur qui est en
train d'utiliser le système, est placé dans ce répertoire.
Les programmes qui gardent des sockets du domaine \*(Ux temporaires
devraient les placer dans ce répertoire.
.H 2 "/var/spool : données en attente pour les applications"
.PS
copy "draft.pic"
dir(/var/spool,Répertoires d'attente)
sub("lpd","Répertoire d'attente de l'imprimante")
sub("mqueue","File d'attente du courrier à l'expédition")
sub("news","Répertoire d'attente des news")
sub("rwho","Fichiers rwhod")
sub("smail","Répertoire d'attente pour smail")
sub("uucp","Répertoire d'attente pour UUCP")
.PE
\f(CW/var/spool\fP contient des données en attente d'un traitement
ultérieur. Les données de \f(CW/var/spool\fP représentent un travail à
faire dans le futur (par un programme, un utilisateur ou un
administrateur) ; les données sont souvent effacées après avoir été
traitées.
.ig
\f(CW/var/spool\fP est fait pour les données `en attente' des
applications. De telles données restent valides même si l'application
qui les a créées s'arrête et redémarre. Quelque temps après avoir été
créées, les données sont enlevées automatiquement, d'une manière
spécifique à l'application ; cela arrive typiquement quand un événement
quelconque se produit (par exemple, lpd imprime le fichier, ou sendmail
l'envoie) ou quand une limite de temps parvient à sa fin (par exemple,
un article de news). Les données de \f(CW/var/spool\fP sont en général
intéressantes pour l'utilisateur en soi et pour soi, à la différence des
données de \f(CW/var/state\fP, qui n'ont généralement d'intérêt
qu'indirectement.
..
Les fichiers de verrou UUCP doivent être placés dans
\f(CW/var/lock\fP. Voir la section ci-dessus à propos de
\f(CW/var/lock\fP.
.H 3 "/var/spool/lpd : file d'impression du daemon de l'imprimante ligne"
.PS
copy "draft.pic"
dir(/var/spool/lpd,Répertoire d'attente de l'imprimante)
sub("","File d'attente d'une imprimante spécifique (optionnel)")
.PE
Le fichier de verrou de \f(CWlpd\fP, \f(CWlpd.lock\fP, devrait être
placé dans \f(CW/var/spool/lpd\fP. Nous suggérons que le fichier de
verrou de chaque imprimante soit placé dans le répertoire d'attente
spécifique à cette imprimante et soit nommé \f(CWlock\fP.
.H 3 "/var/spool/rwho : fichier rwhod"
.sp
Ce répertoire contient les informations rwhod d'autres systèmes sur le
réseau local.
.HU "Raison d'être :"
.br
.P
Certaines versions de BSD utilisent \f(CW/var/rwho\fP pour ces données ;
étant donné leur emplacement historique dans \f(CW/var/spool\fP sur
d'autres systèmes et sa convenance approximative à la définition de
données `en attente', cet emplacement a été estimé plus approprié.
.H 2 "/var/state : informations variables d'état"
.PS
copy "draft.pic"
dir(/var/state,Informations variables d'état)
sub("<éditeur>","Fichiers de sauvegarde et état d'éditeurs")
.\" sub("elvis","Saved files after crash or hang-up from elvis")
.\" sub("emacs","State directory for Emacs")
sub("misc","Diverses données d'état")
.\" sub("news","Fichiers variables pour Cnews/INN")
.\" sub("nvi","Fichiers sauvegardés apreès le plantage ou le bloquage de nvi")
sub("xdm","Données variables du gestionnaire d'affichage X xdm")
sub("","Fichiers d'aide au paquetage")
sub("","Données d'état pour les paquetages et les sous-systèmes")
.PE
Cette hiérarchie contient des informations d'état se rapportant à une
application ou au système. Les informations d'état sont des données que
les programmes modifient au cours de leur exécution, relatives à une
machine spécifique. Les utilisateurs ne devraient jamais avoir besoin de
modifier des fichiers dans \f(CW/var/state\fP pour configurer la bonne
marche d'un paquetage.
Les informations d'état sont utilisées en général pour préserver
l'environnement d'une application (ou d'un groupe d'applications liées
entre elles) entre plusieurs lancements et entre plusieurs instances de
la même application. Les informations d'état devraient en général rester
valides après un redémarrage, ne devraient pas garder l'historique
de sortie d'un programme et ne devraient pas être des données en attente.
.\" (mais notez que emacs/lock en est une exception),
Une application (ou un groupe d'applications liées) devrait utiliser un
sous-répertoire de \f(CW/var/state\fP pour ses données. Il y a un
sous-répertoire obligatoire, \f(CW/var/state/misc\fP, fait pour les
fichiers d'état qui n'ont pas besoin de sous-répertoire ; les autres
sous-répertoires ne devraient être présents que si l'application en
question est incluse dans la distribution.
\f(CW/var/state/\fP est l'endroit à utiliser pour tout le support
de paquetage de la distribution. Des distributions différentes peuvent
évidemment utiliser des noms différents.
Les versions précédentes de cette norme utilisaient le nom
\f(CW/var/lib\fP pour cette hiérarchie. \f(CW/var/lib\fP est obsolète,
mais peut être utilisé en parallèle avec la hiérarchie obligatoire
\f(CW/var/state\fP, comme mesure transitoire pour les données
spécifiques aux applications. Notez cependant que cette permission sera
retirée dans une version future de la norme. Par contre, vous pouvez
faire un lien symbolique de \f(CW/var/lib\fP vers \f(CW/var/state\fP.
.HU "Raison d'être :"
.br
.P
\f(CW/usr/lib\fP est de plus en plus utilisé uniquement pour les
fichiers objets ou leurs archives ; ceci est vrai pour les variantes BSD
\*(Ux actuelles ainsi que les paquetages GNU actuels. Dans le même
ordre d'idées, le nom \f(CW/var/lib\fP semblait inapproprié.
BSD utilise le nom \f(CW/var/db\fP pour un répertoire similaire. Ce nom
semblait trop restrictif, puisqu'il impliquait une structure de
répertoires faite tout d'abord pour les fichiers de base de données
(\f(CW.db\fP).
.H 3 "/var/state/<éditeur> : fichiers de sauvegarde et état d'un éditeur"
.sp
Ces répertoires contiennent des fichiers sauvegardés par toute fin
inattendue d'un éditeur (par exemple elvis, jove, nvi).
D'autres éditeurs peuvent ne pas demander de répertoire pour les
fichiers de sauvegarde de plantage, mais peuvent nécessiter un endroit
bien défini pour stocker d'autres informations pendant que l'éditeur
fonctionne. Ces informations devraient être stockées dans un
sous-répertoire de \f(CW/var/state\fP (par exemple, GNU Emacs placerait
ses fichiers de verrou dans \f(CW/var/state/emacs/lock\fP).
Des éditeurs futurs pourront avoir besoin d'informations d'état
supplémentaires au-delà des fichiers de sauvegarde de plantage et des
fichiers de verrou -- ces informations devraient aussi être placées dans
\f(CW/var/state/<éditeur>\fP.
.HU "Raison d'être :"
.br
.P
Les versions précédentes de Linux, ainsi que tous les distributeurs du
commerce, utilisaient \f(CW/var/preserve\fP pour vi et ses
clones. Cependant, chaque éditeur utilise son propre format pour ces
fichiers de sauvegarde de plantage, c'est pourquoi un répertoire séparé
est nécessaire à chaque éditeur.
Les fichiers de verrous spécifiques à chaque éditeur sont en général
assez différents des fichiers de verrous de périphérique ou de
ressources stockés dans \f(CW/var/lock\fP et de ce fait sont stockés
dans \f(CW/var/state\fP.
.H 3 "/var/state/misc : diverses données variables"
.SP
Ce répertoire contient des données variables qui ne sont pas placées
dans un sous-répertoire de \f(CW/var/state\fP. Il serait judicieux
d'utiliser dans la mesure du possible des noms uniques dans ce
répertoire pour éviter les conflits de noms.
Notez que cette hiérarchie devrait contenir les fichiers de
\f(CW/var/db\fP des versions actuelles de BSD. Celles-ci comprennent
\f(CWlocate.database\fP et \f(CWmountdtab\fP, et la (les) base(s) de
données des symboles du noyau.
.H 2 "/var/tmp : fichiers temporaires préservés entre les redémarrages du système"
.P
Le répertoire \f(CW/var/tmp\fP est mis à la disposition des programmes
qui ont besoin de fichiers ou de répertoires temporaires préservés entre
les redémarrages du système. Par conséquent, les données stockées dans
\f(CW/var/tmp\fP restent plus longtemps que les données de \f(CW/tmp\fP.
Les fichiers et répertoires situés dans \f(CW/var/tmp\fP ne doivent pas
être effacées quand le système démarre. Bien que les données stockées
dans \f(CW/var/tmp\fP soient typiquement effacées d'une manière
spécifique au site, il est recommandé que l'effacement se fasse dans un
intervalle plus long que pour \f(CW/tmp\fP.
.ig
Un lien symbolique \f(CW/var/tmp/vi.recover\fP vers
\f(CW/var/state/nvi\fP est permis pour supporter les versions de nvi
compilées sans le nom de chemin suggéré dans la norme.
Les programmes ne doivent pas supposer que tout fichier ou répertoire
est préservé entre deux appels du programme.
..
.\" XXX - Pourquoi le deuxième paragraphe a été mis en commentaire ?
.H 2 "/var/yp : fichiers de base de données NIS (Network Information Service)"
.P
Les données variables du Service d'Information Réseau (NIS ou Network
Information Service), qu'on appelait auparavant Pages Jaunes Sun (YP ou
Sun Yellow Pages), seront placées dans ce répertoire.
.HU "Raison d'être :"
.br
.P
\f(CW/var/yp\fP est le répertoire normal des données NIS (YP) et est
utilisé presque exclusivement dans la documentation et les systèmes NIS.
Il ne faut pas confondre NIS et Sun NIS+, qui utilise un répertoire
différent, \f(CW/var/nis\fP.
.SK
.H 1 "Annexe spécifique aux systèmes d'exploitation"
.P
Cette section contient des obligations et recommandations
supplémentaires qui ne s'appliquent qu'à un système d'exploitation
spécifique. Les principes de cette section ne devraient jamais entrer en
conflit avec la norme de base.
.H 2 "Linux"
.P
Voici l'annexe pour le système d'exploitation Linux.
.H 3 "/ : répertoire racine"
.sp
Sur les systèmes Linux, si le noyau est situé dans \f(CW/\fP, nous
recommandons d'utiliser les noms \f(CWvmlinux\fP ou \f(CWvmlinuz\fP, qui
sont utilisés dans les paquetages récents de sources du noyau Linux.
.H 3 "/dev : fichiers de périphériques et fichiers spéciaux"
.sp
Tous les fichiers de périphériques et fichiers spéciaux de \f(CW/dev\fP
devraient se conformer au document \fILinux Allocated Devices\fP
(périphériques alloués dans Linux), que l'on trouve dans les sources du
noyau Linux. Il est maintenu par H. Peter Anvin .
Les liens symboliques de \f(CW/dev\fP ne devraient pas être distribués
avec des systèmes Linux sauf s'ils sont fournis dans le document
\fILinux Allocated Devices\fP.
.HU "Raison d'être :"
.br
.P
L'obligation de ne pas faire de liens symboliques au hasard est donnée
parce que la configuration locale diffère souvent de celle de la machine
de développement 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 matériel. Utilisés de manière
responsable à un niveau local, cependant, on peut les utiliser à bon
escient.
.H 3 "/proc : système de fichiers virtuel d'information sur le noyau et les processus"
.sp
Le système de fichiers proc devient la méthode standard de-facto sur
Linux pour manipuler les processus et les informations du système,
plutôt que par \f(CW/dev/kmem\fP et autres méthodes 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 mémoire.
.H 3 "/sbin : binaires systèmes essentiels"
.sp
Les systèmes Linux placent ces fichiers supplémentaires dans
\f(CW/sbin\fP.
.BL
.LI
Commandes du système de fichiers étendu deuxième version (ext2 --
optionnel) :
.VL 2
.LI "\f(CW{"
badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs }\fP
.LE
.LI
Installateur de carte du chargeur de démarrage :
.VL 2
.LI "\f(CW{"
lilo }\fP
.LE
.HU "Fichiers optionnels de /sbin :"
.BL
.LI
Binaires statiques :
.SP
.VL 2
.LI "\f(CW{"
ldconfig, sln, ssync }\fP
.LE
.P
Les binaires statiques \f(CWln\fP (\f(CWsln\fP) et \f(CWsync\fP
(\f(CWssync\fP) sont utiles quand quelque chose va mal. L'utilisation
principale de \f(CWsln\fP (pour réparer les liens symboliques incorrects
dans \f(CW/lib\fP après une mise à jour mal faite) n'est plus d'une
importance cruciale maintenant que le programme \f(CWldconfig\fP (situé
généralement dans \f(CW/usr/sbin\fP) existe et peut agir comme guide
dans certaines situations d'urgence. Notez qu'ils ne doivent pas
forcément être des versions liées en statique des commandes normales
\f(CWln\fP et \f(CWsync\fP, mais elle peuvent l'être.
Le binaire \f(CWldconfig\fP est optionnel dans \f(CW/sbin\fP puisqu'un
site peut choisir de lancer \f(CWldconfig\fP au démarrage plutôt qu'à la
mise à jour des bibliothèques partagées. (Il n'est pas clair qu'il soit
avantageux de lancer \f(CWldconfig\fP à chaque démarrage.) Même ainsi,
certaines personnes aiment avoir \f(CWldconfig\fP à portée de clavier
pour les situations suivantes (toutes trop fréquentes) :
.LB 8 4 " " 3
.LI
Je viens d'enlever \f(CW/lib/\fP.
.LI
Je ne peux pas trouver le nom de la bibliothèque parce que \f(CWls\fP
est lié en dynamique, j'utilise un shell qui n'a pas \f(CWls\fP intégré
et je ne sais pas utiliser "\f(CWecho *\fP" à la place.
.LI
J'ai un \f(CWsln\fP en statique, mais je ne sais pas comment appeler le
lien.
.LE
.LI
Divers :
.SP
.VL 2
.LI "\f(CW{"
ctrlaltdel, kbdrate }\fP
.LE
.P
Pour pallier au fait que certains claviers sont livrés avec une
fréquence de répétition si grande qu'ils en sont inutilisables,
\f(CWkbdrate\fP peut être installé dans \f(CW/sbin\fP sur certains
systèmes.
.\" devons-nous conseiller d'installer ceci ?
Puisque l'action par défaut dans le noyau pour la combinaison de touches
Ctrl-Alt-Del est un redémarrage brutal instantané, il est recommandable
de désactiver ce comportement avant de monter le système de fichiers
racine en mode lecture/écriture. Certaines versions d'\f(CWinit\fP sont
capables de désactiver Ctrl-Alt-Del, mais d'autres nécessitent le
programme \f(CWctrlaltdel\fP qui peut être installé dans \f(CW/sbin\fP
sur ces systèmes.
.LE
.H 3 "/usr/include : fichiers d'en-tête inclus par les programmes C"
.sp
Les liens symboliques suivants sont nécessaires si un compilateur C ou
C++ est installé.
.nf
.ft CW
/usr/include/asm -> /usr/src/linux/include/asm-
/usr/include/linux -> /usr/src/linux/include/linux
.ft P
.fi
.H 3 "/usr/src : code source"
.sp
Le seul code source qui doit être placé dans un endroit spécifique est
le code source du noyau Linux. Il est situé dans \f(CW/usr/src/linux\fP.
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-tête du code source
du noyau devront être situés dans ces répertoires :
.nf
.ft CW
/usr/src/linux/include/asm-
/usr/src/linux/include/linux
.ft P
.fi
\f(CW\fP est le nom de l'architecture du système.
.ft I
Note : \f(CW/usr/src/linux\fP peut être un lien symbolique vers
l'arborescence réelle du code source du noyau.
.ft P
.HU "Raison d'être :"
.br
.P
Il est important que les fichiers d'en-têtes du noyau soient situés dans
\f(CW/usr/src/linux\fP et non dans \f(CW/usr/include\fP pour qu'il n'y
ait pas de problemes quand les administrateurs système mettent à jour la
version du noyau pour la première fois.
.H 3 "/var/spool/cron : travaux cron et at"
.P
Ce répertoire contient les données variables pour les programmes cron et
at.
.SK
.\" -------------------------------------------------------------------
.\" Partie finale
.\" -------------------------------------------------------------------
.nr Hu 3
.HU "La liste de distribution \*(Fs"
.P
La liste de distribution \*(Fs est située à
. Pour vous abonner à la liste envoyez un courrier
à avec dans le corps du message "\f(CWADD
fhs-discuss\fP".
Merci à Network Operations à l'université de Californie à San Diego qui
nous a autorisés à 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 \*(Fs ou un contributeur listé.
.HU "Remerciements"
.P
Les développeurs de la \*(Fs souhaitent remercier les développeurs,
administrateurs système 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 \*(Fs souhaite aussi remercier les développeurs Linux qui ont
supporté la FSSTND, prédécesseur de cette norme. S'ils n'avaient pas
démontré le bénéfice apporté par la FSSTND, la \*(Fs n'aurait jamais pu
évoluer.
.HU "Contributeurs"
.P
.TS
l l.
Brandon S. Allbery
Keith Bostic
Drew Eckhardt
Rik Faith
Stephen Harris
Ian Jackson
John A. Martin
Ian McCloghrie
Chris Metcalf
Ian Murdock
David C. Niemi
Daniel Quinlan
Eric S. Raymond
Mike Sangrey
David H. Silber
Theodore Ts'o
Stephen Tweedie
Fred N. van Kempen
.HU "Traducteurs :"
.P
La traduction française a été réalisée par Olivier Tharan,
. Tous les commentaires sont acceptés.
.TE
.TC
.\" Local Variables:
.\" fill-column:72
.\" font-lock-maximum-size:0
.\" hilit-auto-highlight-maxout:100000
.\" End:
fhs-2.0.fr-nroff/Makefile 100640 764 764 1461 6465126461 13140 0 ustar nat nat TFLAGS=-p -t -mm -Wall
GROFF=groff
export PATH=/usr/bin:/bin
all: fhs.dvi fhs.txt fhs.ps
fhs.lj4: draft.mm
$(GROFF) $(TFLAGS) -Tlj4 draft.mm > fhs.lj4
fhs.dvi: draft.mm
$(GROFF) $(TFLAGS) -Tdvi draft.mm > fhs.dvi
fhs.txt: draft.mm
$(GROFF) $(TFLAGS) -Tlatin1 draft.mm | col -bx > fhs.txt
fhs.doc: draft.mm
$(GROFF) $(TFLAGS) -Tlatin1 draft.mm > fhs.doc
fhs.ps: draft.mm
$(GROFF) $(TFLAGS) -Tps draft.mm > fhs.ps
X75: draft.mm
$(GROFF) $(TFLAGS) -TX75 draft.mm
X100: draft.mm
$(GROFF) $(TFLAGS) -TX100 draft.mm
clean:
rm -f fhs.dvi fhs.ps fhs.txt fhs.doc fhs.lj4
fhs-us.ps: draft-vo.mm
$(GROFF) $(TFLAGS) -Tps draft-vo.mm > fhs-us.ps
dist: draft.mm Makefile draft.pic README.trad fhs.dvi fhs.ps fhs.txt
tar zcvf fhs-2.0.fr.tar.gz draft.mm Makefile draft.pic \
README.trad fhs.dvi fhs.txt fhs.ps
fhs-2.0.fr-nroff/draft.pic 100640 764 764 550 6436250143 13244 0 ustar nat nat define dir %
line invis
move to left of last line
"\f(CW\fB$1\fR \(em $2" ljust
move to left of last line
move down 0.20
%
define sub %
boxht = 0.165
line down boxht
line right 0.15
box invis
move to left of last box
move right 0.1
"\f(CW" $1 ljust "\fP"
move from right of last box right 0.3
$2 ljust
move to end of last line
move left 0.15
%
fhs-2.0.fr-nroff/README.trad 100640 764 764 1125 6465127354 13310 0 ustar nat nat
( English note: this is the French translation for FHS )
Certains mots sont introduits automatiquement par groff et ne sont donc
pas traduits (à moins de patcher groff), ce sont Abstract, Contents, et la
date sur la page de couverture.
Pour compiler cette doc, taper make produit un .ps, un .dvi et un .txt (le
txt n'utilise pas les caractères 8 bits, faire make fhs.doc pour les avoir).
De toute façon, regardez le Makefile qui est très explicite.
La version d'origine se trouve sur
ftp://ftp.lip6.fr/pub/linux/sunsite/docs/fhs/fhs-2.0.tar.gz
--Olivier Tharan , le 01/02/98