Tables des matières. - 4 La hiérarchie /usr << >> Up Title Contents

4 La hiérarchie /usr


/usr est la deuxième section majeure du système de fichiers. /usr est partageable, en lecture seule. Ceci veut dire que /usr doit être partageable entre des machines variées tournant sous Linux et ne doit pas être accessible en écriture. Toutes les informations locales à une machine ou qui varient dans le temps sont stockées autre part.

Aucun gros package (comme TeX ou GNU Emacs) ne devrait utiliser un sous-répertoire direct de /usr. À la place, il devrait y avoir un sous-répertoire à l'intérieur de /usr/lib (ou /usr/local/lib si il était installé complètement localement) pour cet usage. Une exception est faite pour le système X Window à cause d'un précédent considérable et d'une pratique largement acceptée.

/usr -- Second major mount point (permanent)

|

+-X11R6 X Window System, version 11 release 6

+-X386 X Window System, version 11 release 5 on x86 Platforms

+-bin Most user commands

+-dict Word lists

+-doc Miscellaneous documentation

+-etc Site-wide system configuration

+-games Games and educational binaries

+-include Header files included by C programs

+-info GNU Info system's primary directory

+-lib Libraries

+-local Local hierarchy (empty after main installation)

+-man Online manuals

+-sbin Non-vital system administration binaries

+-share Architecture-independent data

+-src Source code

Les liens symboliques suivants vers les répertoires doivent être présents. Cette possibilité est basée sur le besoin de préserver la compatibilité avec des systèmes plus anciens jusqu'à ce que toutes les implémentations utilisent la hiérarchie /var.

/usr/adm -> /var/adm

/usr/preserve -> /var/preserve

/usr/spool -> /var/spool

/usr/tmp -> /var/tmp

/var/spool/locks -> /var/lock

Une fois qu'un système ne demande plus aucun des liens symboliques suivants, les liens peuvent être enlevés, si désiré. De façon notable, il ne faut que peu d'effort pour enlever complètement /usr/preserve puisque seulement ex et vi l'utilisent.

4.1 /usr/X11R6 : système X Window, Version 11 Release 6

Cette hiérarchie est réservée au système X Window, version 11 release 6, et aux fichiers liés.

/usr/X11R6 -- X Window System (version 11 release 6)

|

+-bin

+-doc

+-include

+-lib

+-man

Pour simplifier les choses et rendre XFree86 plus compatible avec le système X Window sur d'autres systèmes, les liens symboliques suivants doivent être présents :

/usr/bin/X11 -> /usr/X11R6/bin

/usr/lib/X11 -> /usr/X11R6/lib/X11

/usr/include/X11 -> /usr/X11R6/include/X11

En général, les logiciels ne doivent pas être installés ou gérés à travers les liens symboliques ci-dessus. Ils ne sont faits que pour l'utilisation par les utilisateurs. La difficulté est liée à la version de sortie du système X Window -- dans les périodes de transition, il est impossible de savoir quelle version de X11 est utilisée. Pour la même raison, il ne doit pas y avoir de lien symbolique de /usr/X11 pointant vers la hiérarchie courante du système X Window.

4.2 /usr/X386 : système X Window, Version 11 Release 5, sur les plate-formes x86

Cette hiérarchie est en général identique à /usr/X11R6, sauf que les liens symboliques /usr doivent être absents si /usr/X11R6 est installé.

4.3 /usr/bin : Commandes utilisateurs principales

Voici le principal répertoire des commandes exécutables sur le système.

/usr/bin -- Binaries that are not needed in single-user mode

|

+-mh Commands for the MH mail handling system

+-X11 Symlink to /usr/X11R6/bin

Parce que les interpréteurs de scripts shell (invoqués avec #!<path> sur la première ligne d'un script shell) ne peuvent se fier à un chemin, il est avantageux d'en standardiser l'emplacement. Les interpréteurs des shell de Bourne et C-shell sont déjà fixés dans /bin, mais Perl, Python, et Tcl se trouvent souvent dans bien des endroits différents. /usr/bin/perl, /usr/bin/python, and /usr/bin/tcl doivent référencer les interpréteurs de shell perl, python, et tcl respectivement. Ils peuvent être des liens symboliques vers la position physique des interpréteurs de shell.

4.4 /usr/dict : listes de mots

Fichiers recommandés pour /usr/dict:

{ words }

Traditionnellement ce répertoire ne contient que le fichier de mots anglais words qui est utilisé par look(1) et d'autres programmes de vérification d'orthographe variés. words peut utiliser la prononciation américaine ou britannique. Les sites qui ont besoin des deux peuvent lier words à /usr/dict/american-english ou /usr/dict/british-english.

Les listes de mots pour les autres langues peuvent être ajoutées en utilisant le nom anglais de cette langue, par exemple /usr/dict/french, /usr/dict/danish, etc. Ceux-ci doivent, si possible, utiliser un jeu de caractères ISO 8859 qui est approprié à la langue en question ; si possible le jeu de caractères Latin1 (ISO 8859-1) doit être utilisé (ceci est souvent impossible).

D'autres listes de mots, comme le "dictionnaire" web2 doivent être incluses ici, si elles sont présentes.

La raison de n'avoir que des listes de mots ici est que ce sont les seuls fichiers communs à tous les vérificateurs d'orthographe.

4.5 /usr/etc : configuration système à l'échelle d'un site

Stocker les informations dans /usr/etc pour les logiciels que l'on trouve dans /usr/bin et /usr/sbin pose un problème. Cela rend le montage en lecture seule de /usr à partir d'un CD-ROM ou par NFS très difficile au mieux.

Une des solutions possibles que nous avons considérées était d'éliminer complètement /usr/etc et spécifier que toute la configuration soit placée dans /etc. Le problème avec cette approche est qu'elle n'anticipe pas proprement la possibilité qu'ont certains sites d'avoir certains fichiers de configuration qui ne sont pas locaux à la machine.

Nous avons finalement décidé que /etc devrait être le seul répertoire référencé par les programmes (c'est-à-dire que tous les programmes devraient regarder dans /etc et non dans /usr/etc). Tous les fichiers de configuration qui doivent être globaux sur un site et dont on n'a pas besoin avant que /usr soit monté (ou dans une situation d'urgence) devraient alors être placés dans /usr/etc. Alors, les fichiers spécifiques (dans /etc) sur des machines spécifiques peuvent ou non être liés de manière symbolique aux fichiers de configuration appropriés situés dans /usr/etc. Ceci signifie aussi que /usr/etc est techniquement un répertoire optionnel au sens le plus strict, mais nous recommandons quand même que tous les systèmes Linux l'incorporent.

Il n'est pas recommandé que /usr/etc contienne des liens symboliques qui pointent sur des fichiers dans /etc. Ceci n'est pas nécessaire et interfère avec le contrôle local sur des machines qui partagent un répertoire /usr.

4.6 /usr/include : Répertoire pour les fichiers include standards

Voici où tous les fichiers include d'utilité générale au système pour les langages de programmation C et C++ doivent être placés.

/usr/include -- Include files

|

+-X11 Symlink to /usr/X11R6/include/X11

+-arpa ARPAnet defined protocol definitions

+-asm Symlink to /usr/src/linux/include/asm-<arch>

+-bsd BSD compatibility include files

+-g++ GNU C++ include files

+-gnu GNU include files

+-linux Symlink to /usr/src/linux/include/linux

+-net Generic network-related definitions

+-netax25 +AX25 (ARRL AX.25) specific definitions

+-netinet TCP/IP specific definitions

+-netipx +IPX (Novell IPX/SPX) specific definitions

+-protocols Protocol definitions (mostly INET-based)

+-readline The GNU readline library

+-rpc Sun Microsystems RPC definitions

+-rpcsvc Sun Microsystems RPC service definitions

+-sys System generation include files

Le sous-répertoire arpa contient des définitions d'en-tête de protocoles pour les protocoles ARPAnet, les fonctions de conversion TCP/IP, les définitions pour les prototypes ftp, telnet et du matériel similaire.

Le sous-répertoire net contient des définitions génériques se rapportant au réseau. Il définit l'interface du noyau système, les détails de la famille de protocole, etc.

Le sous-répertoire netinet contient des définitions spécifiques à INET (DARPA Internet, aussi connu sous le nom de TCP/IP).

ARRL AX.25 est mieux connu sous le nom de radio par paquets. Les protocoles Novell IPX/SPX font partie des services de fichiers Novell NetWare.

4.7 /usr/lib : bibliothèques pour la programmation et les packages

/usr/lib contient des bibliothèques d'objets, des binaires de compilateurs, et des données statiques de type variés -- à la fois du code exécutable (par exemple les binaires internes du GCC sont situés dans /usr/lib/gcc-lib) et d'autres types de données.

/usr/lib -- Libraries for programming and packages

|

+-X11 Symbolic link to /usr/X11R6/lib/X11

+-emacs Static support files for the GNU Emacs editor

+-games Static data files for /usr/games

+-groff Libraries/directories for GNU groff

+-gcc-lib System specific files/directories for GCC

+-kbd Keyboard translation tables and related data

+-mh Libraries for the MH mail handling system

+-news Cnews/INN

+-smail Smail

+-terminfo Directories for terminfo database

+-texmf TeX/MF (and LaTeX) data libraries

+-uucp Commands for UUCP

+-zoneinfo Timezone information and configuration

De manière historique, /usr/lib a aussi contenu certaines commandes exécutables comme sendmail et makewhatis.

Puisque makewhatis n'est pas référencé par d'autres programmes, il n'y a pas de problèmes à le déplacer dans un répertoire de binaires. Puisque les utilisateurs ont de bonnes raisons d'utiliser makewhatis, /usr/bin est l'endroit où il appartient. Le binaire catman (qui remplace le script makewhatis sur beaucoup de systèmes Linux) devrait aussi être placé dans /usr/bin.

Le binaire sendmail est référencé par beaucoup de programmes par son nom historique, /usr/lib/sendmail. Ceci devrait être un lien symbolique vers l'emplacement standard pour les agents de transport de courrier possédant une interface à la ligne de commande compatible avec sendmail, /usr/sbin/sendmail.

Les systèmes qui utilisent Smail devraient placer Smail dans /usr/sbin/smail, et /usr/sbin/sendmail devrait être un lien symbolique sur Smail.

Cet arrangement se conforme aussi au nouvel emplacement standard de sendmail défini dans Sendmail 8.6.x and 4.4BSD. Notez que cet emplacement demande que /usr/sbin et /usr/sbin/sendmail soient exécutables par les utilisateurs normaux.

Tout programme ou package qui contient ou demande des données qui n'ont pas besoin d'être modifiées devraient stocker ces données dans /usr/lib (ou /usr/local/lib, en installation locale). Il est recommandé qu'un sous-répertoire soit utilisé dans /usr/lib à cet usage.

Les données de jeux stockées dans /usr/lib/games doivent être des données purement statiques. Tout fichier modifiable, comme les fichiers de scores, les logs de jeux et ainsi de suite, devraient être placés dans /var/lib. Si nécessaire pour la compatibilité avec les anciens jeux de style BSD, un lien symbolique de /usr/games/lib vers /usr/lib/games peut être utilisé.

Note : Aucune donnée spécifique à un hôte pour le système X Window ne devrait être stockée dans /usr/lib/X11 (qui est en fait /usr/X11R6/lib/X11). Les fichiers de configuration spécifiques à l'hôte comme Xconfig ou XF86Config devraient être stockés dans /etc/X11. Ceci doit inclure les données de configuration comme system.twmrc même si elles ne sont que des liens symboliques vers des fichiers de configuration plus généraux (peut-être dans /usr/etc/X11 ou /usr/X11R6/lib/X11).

4.8 /usr/local : hiérarchie locale

L'administrateur système utilise la hiérarchie /usr/local quand il installe un logiciel localement. Elle doit être garantie contre l'effacement quand le logiciel système est mis à jour. Elle peut être utilisée pour les programmes et les données partageables parmi un groupe de machines, mais qu'on ne trouve pas dans /usr.

/usr/local -- Local hierarchy

|

+-bin Local-only binaries

+-doc Local documentation

+-etc Configuration for local-only binaries

+-games Locally installed games

+-lib Libraries for /usr/local

+-info Local info pages

+-man Man page hierarchy for /usr/local

+-sbin Local-only system administration

+-src Local source code

Ce répertoire devrait toujours être vide après la première installation de Linux. Aucune exception à cette règle ne doit être faite autre que les morceaux de répertoires listés.

Les logiciels installés en local devraient être placés dans /usr/local plutôt que dans /usr sauf s'ils sont installés pour remplacer ou mettre à jour des logiciels dans /usr.

Notez que les logiciels placés dans / ou /usr peuvent être effacés par les mises à jour du système (bien que nous recommandons que les distributions n'effacent pas les données dans /etc sous ces circonstances). Pour cette raison, les logiciels locaux ne devraient pas être placés en dehors de /usr/local sans bonne raison.

4.9 /usr/man : pages de manuel

Cette section détaille l'organisation des pages de manuel à travers le système, en incluant /usr/man.

Les pages de manuel sont stockées dans <mandir>/<locale>/man[1-9].

L'explication de <mandir> et <locale> est donnée ci-dessous.

<mandir>/<locale> -- A manual page hierarchy

|

+-man1 User programs

+-man2 System calls

+-man3 Library functions and subroutines

+-man4 Devices

+-man5 File formats

+-man6 Games

+-man7 Miscellaneous

+-man8 System administration

+-man9 Kernel internal variables and functions

Le <mandir> principal du système est /usr/man. /usr/man contient les manuels d'information pour les commandes et les données sous les systèmes de fichiers / et /usr. De manière évidente, il n'y a pas de pages de manuel dans / parce qu'elles ne sont pas demandées au moment du démarrage ni en cas d'urgence.

Des provisions doivent être faites dans la structure de /usr/man pour supporter les pages de manuel écrites dans des langues différentes (ou multiples). Ces provisions doivent prendre en compte le stockage et la référence de ces pages de manuel. Les facteurs pertinents comprennent la langue (en incluant les differences géographiques), et le codage de caractères.

Cette appellation des sous-répertoires de langues dans /usr/man est basée sur l'Appendice E de la norme POSIX 1003.1 qui décrit la chaîne d'identification locale -- la méthode la mieux acceptée pour décrire un environnement culturel. La chaîne <locale> est :

<langue>[_<territoire>][.<code-de-caractères>][,<version>]

Le champ <langue> sera pris dans ISO 639 (un code pour la représentation des noms de langues). Il sera long de deux caractères et spécifié avec des lettres bas-de-casse uniquement.

Le champ <territoire> sera le code de deux lettres d'ISO 3166 (une spécification de la représentation des pays), si possible. (La plupart des gens sont familiers avec les codes de deux lettres utilisés pour les codes de pays dans les adresses de courrier électronique.) Il sera long de deux caractères et spécifié avec des lettres bas-de-casse uniquement. (Une exception majeure à cette règle est le Royaume-Uni (NdT United Kingdom en anglais) qui est 'GB' dans l'ISO 3166, mais 'UK' pour la plupart des adresses de courrier électronique.)

Le champ <code-de-caractères> doit représenter la norme qui décrit le codage de caractères. Si le champ <code-de-caractères> est simplement une spécification numéique, le nombre représente le numéro de la norme internationale qui décrit le code de caractères. Il est recommandé que ce soit une représentation numérique si possible (et surtout des normes ISO), n'inclue pas de symboles de ponctuation, et que toute lettre soit en bas-de-casse.

Un paramètre spécifiant une <version> du profil peut être placé après le champ <code-de-caractères>, délimité par une virgule. Ceci peut être utilisé pour séparer différents besoins culturels ; par exemple, l'ordre dans le dictionnaire contre un ordre d'assemblage plus orienté vers le système. Cette norme recommende de ne pas utiliser le champ <version> sauf si c'est nécessaire.

Les systèmes qui utilisent une langue et un code unique pour toutes les pages de manuel peuvent omettre la sous-chaîne <locale> et stocker toutes les pages de manuel dans <mandir>. Par exemple, les systèmes qui n'ont que les pages de manuel en anglais, codées en ASCII peuvent stocker les pages de manuel (les répertoires man[1-9]) directement dans /usr/man. (Ce sont les circonstances et arrangements traditionnels, en fait.)

Les pays pour lesquels il y a un codage de caractères standard bien accepté peuvent omettre le champ <code-de-caractères>, mais il est fortement recommandé qu'il soit inclus, surtout pour les pays avec plusieurs normes "en compétition".

Exemples variés :

Language Territory Character Set Directory

-----------------------------------------------------------------

English -- ASCII /usr/man/en

English United Kingdom ASCII /usr/man/en_GB

English United States ASCII /usr/man/en_US

French Canada ISO 8859-1 /usr/man/fr_CA

French France ISO 8859-1 /usr/man/fr_FR

German Germany ISO 646-DE /usr/man/de_DE.646de

German Germany ISO 6937 /usr/man/de_DE.6937

German Germany ISO 8859-1 /usr/man/de_DE.88591

German Switzerland ISO 646-CH /usr/man/de_CH.646ch

Japanese Japan JIS /usr/man/ja_JP.jis

Japanese Japan SJIS /usr/man/ja_JP.sjis

Japanese Japan UJIS (or EUC-J) /usr/man/ja_JP.ujis

Les pages de manuel pour les commandes et les données sous /usr/local sont stockées dans /usr/local/man. Les pages de manuel pour le système X Window sont stockées dans /usr/X11R6/man. Il s'ensuit que toutes les hiérarchies de pages de manuel dans le système doivent avoir la même structure que /usr/man. Les répertoires vides peuvent être omis d'une hiérarchie de pages de manuel. Par exemple, si /usr/local/man n'a pas de pages de manuel dans la section 4 (Périphériques), alors /usr/local/man/man4 peut être omis.

Les sections de pages cat (cat[1-9]) contenant les entrées de pages de manuel formatées se trouvent aussi dans des sous-répertoires de <mandir>/<locale>, mais ne sont pas obligatoires ni ne doivent être distribuées à la place des pages de manuel en source nroff.

Les pages de manuel du système de distribution de courrier MH doivent avoir mh ajouté à tous les noms de fichiers de pages de manuel. Toutes les pages de manuel du système X Window doivent avoir un x ajouté au nom de fichier.

La pratique de placer les pages de manuel de langues variées dans des sous-répertoires appropriés de /usr/man s'applique aussi aux autres hiérarchies de pages de manuel, comme /usr/local/man et /usr/X11R6/man.

(Cette partie de la norme s'applique aussi plus loin dans la section sur la structure optionnelle /var/catman.)

Une description de chaque section suit :

* man1: programmes utilisateurs

Les pages de manuel qui décrivent les commandes accessibles publiquement sont contenues dans ce chapitre. La plupart de la documentation des programmes dont l'utilisateur aura besoin est contenue dans ce chapitre.

* man2: Appels système

Cette section décrit tous les appels système (requêtes au noyau Linux pour effectuer des opérations).

* man3: Fonctions et sous-routines de bibliothèques

La section 3 décrit les routines de bibliothèques de programme qui ne sont pas des appels directs aux services du noyau. Ceci et le chapitre 2 ne sont réellement d'intérêt qu'aux programmeurs.

* man4: Fichiers spéciaux

La section 4 décrit les fichiers spéciaux, les fonctions de pilotes qui s'y rapportent, et le support réseau disponible dans le système. Typiquement, ceci comprend les fichiers de périphériques que l'on trouve dans /dev et l'interface du noyau au support du protocole réseau.

* man5: Formats de fichiers

Les formats pour de nombreux fichiers de données non intuituifs sont documentés dans la section 5. Ceci comprend des fichiers include divers, des fichiers de sortie de programmes, et des fichiers système.

* man6: Jeux

Ce chapitre documente les jeux, les démonstrations et les programmes en général triviaux. Des gens différents ont des notions variées du caractère essentiel de ce chapitre.

* man7: Divers

Les pages de manuel difficiles à classer sont désignés comme appartenant à la section 7. Troff et d'autres packages de macro-commandes de traitement de texte se trouvent ici.

* man8: Administration système

Les programmes utilisés par les administrateurs système pour l'opération du système et la maintenance sont documentés ici. Certains de ces programmes sont aussi utiles occasionnellement pour les utilisateurs normaux.

* man9: Variables et fonctions internes au noyau

Ceci est utilisé sur les systèmes Linux pour documenter le code des sources du noyau.

4.10 /usr/sbin : binaires système standard non essentiels

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, à la reconstitution du système, au montage de /usr, ou d'autres fonctions essentielles doivent par contre être placés dans /sbin.

Typiquement, /usr/sbin contient les daemons de réseau, tous les outils d'administration non essentiels, et les binaires pour les programmes serveurs non essentiels. Ceci comprend les daemons internet appelés par inetd (nommés in.*) comme in.telnetd et in.fingerd et les daemons basés sur rpc (nommés rpc.*) comme rpc.nfsd et rpc.mountd.

Ces programmes serveurs sont utilisés en entrant dans les états System V connus sous le nom de "run level 2" (état multi-utilisateurs) et "run level 3" (état réseau) ou l'état BSD connu sous le nom de "mode multi-utilisateurs". À ce point le système rend les services disponibles aux utilisateurs (par exemple, les impressions) et aux autres machines (par exemple, NFS).

Les programmes d'administration système installés en local doivent être placés dans /usr/local/sbin.

4.11 /usr/share : données indépendantes de l'architecture

Toutes les spécifications de /usr/share seront incluses dans une ébauche supplémentaire de la norme FSSTND principale. Notez que c'est l'opinion consensuelle de FSSTND que /usr/share n'est pas nécessaire sur la majorité des systèmes Linux. En ce moment, nous limiter à fournir une définition au sens large de ce répertoire serait une mauvaise idée.

Veuillez vous reporter à la section 6 pour une discussion plus détaillée de /usr/share.

4.12 /usr/src : code source

/usr/src -- Source code

|

+-linux Source code for Linux kernel

Tout code source non local doit être placé dans ce sous-répertoire. Le seul code source qui doit toujours être placé dans un endroit spécifique est le source du noyau (quand il est présent ou lié en partie à la structure /usr/include). Des sous-répertoires peuvent être utilisés si désiré.

Le code source du noyau doit toujours être en place ou au moins les fichiers include du source du noyau. Ces fichiers sont situés dans ces répertoires :

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

/usr/src/linux/include/linux


<< >> Up Title Contents

© 1996-1997 "Logiciels du Soleil"