Copyright et Information de Licence Préface 1 Généralités Copyright et Information de Licence Préface 1 Généralités 2 Le système de fichiers 3 Le répertoire racine 4 La hiérarchie /usr 5 La hiérarchie /var 5.3.1 /var/lib/emacs 5.3.2 /var/lib/games 5.3.3 /var/lib/news 5.3.4 /var/lib/texmf 5.3.5 /var/lib/xdm 5.4 /var/local : données variables des logiciels de /usr/local 5.5 /var/lock : fichiers lock 5.6 /var/log : fichiers et répertoires de rapports 5.7 /var/named : fichiers de DNS 5.8 /var/nis : fichiers de la base de données du Service d'Information Réseau (NIS) 5.9 /var/preserve : fichiers sauvés après un crash ou un blocage de ex ou vi 5.10 /var/run : fichiers variables d'exécution 5.11 /var/spool : épertoires de spool 5.12 /var/tmp : fichiers temporaires, utilisés pour garder /tmp petit 6 Problèmes et analyse supplémentaire La liste de distribution FSSTND Remerciements
Copyright et Information de Licence Linux n'est pas une marque déposée, et n'a aucun rapport avec UNIX. UNIX est une marque déposée de X/Open Company, Ltd. HP-UX est une marque déposée de Hewlett-Packard. Novell et Novell NetWare sont des marques déposées de Novell. SunOS, Sun Microsystems, Sun NIS, Sun RPC, et NFS sont des marques déposées de Sun Microsystems, Inc. System V et SVR4 sont des marques déposées de AT&T. X Window System est une marque déposée de X Consortium, Inc.Tous les autres copyrights appartiennent à leurs propriétaires, sauf si c'est noté spécifiquement autrement. L'usage d'un terme dans ce document ne devrait pas être ragardé comme affectant la validité de toute marque déposée ou marque de service.
Copyright (C) 1994, 1995 Daniel Quinlan
La permission est accordée de copier et distribuer des copies exactes de cette norme pourvu que le copyright et cette notice de permission soient préservées sur toutes les copies.
La permission est accordée aux contributeurs et participants de FSSTND de copier et distribuer des versions modifiées de cette norme sous les conditions de copie exacte pour des usages d'activités de normalisation de systèmes de fichiers uniquement, et sujets aux restrictions listées ci-dessous.
Les restrictions suivantes s'appliquent à la reproduction ou la transmission du document sous n'importe quelle forme :
Toutes les copies ou portions de celle-ci doivent identifier le titre du document et la section, et doivent être accompagnées de cette notice en entier dans un emplacement proéminent. Aucune portion de ce document ne peut être redistribuée dans quelque forme modifiée ou abrégée sans l'accord préalable du coordinateur FSSTND.Toute entité cherchant la permission de distribuer tout matériel dérivé de ce document (autre que des copies conformes) doivent contacter le coordinateur FSSTND pour la licence appropriée.
Statut de la NormeVoici la version 1.2 de la Structure du Système de Fichiers Linux (FSSTND).
Les indications dans cette norme sont sujettes à changement. L'utilisation des informations contenues dans ce document se fait sous votre responsabilité.
Organisation de la normeCette norme est divisée en 6 parties :
Conventions typographiquesLa police Courier est utilisée pour les noms de fichiers et de répertoires.
Les composants des noms de fichiers qui varient sont représentés par une description des contenus entourés entre les caractères "<" et ">", <ainsi>.
Les adresses de courrier électronique sont aussi entourées entre "<" et ">" mais sont montrées dans la police tranditionnelle.
Les composants optionnels des noms de fichiers sont entourés entre les caractères "[" et "]" et peuvent être combinés avec la convention "<" et ">". Par exemple, si un fichier existait qui pourrait être trouvé soit avec ou sans extension, il pourrait être représenté par <nomfichier>[.<extension>].
Les sous-chaînes variables des noms de répertoires et de fichiers sont indiquées par "*".
1.1 ÉtendueCe document spécifie une structure de système de fichiers standard pour les systèmes Linux, comprenant l'emplacement des fichiers et répertoires, ainsi que le contenu de certains fichiers système.
Le système de fichiers standard a été élaboré pour être utilisé par les développeurs de distributions Linux, les développeurs de packages, et les implémenteurs du système. Cependant, il se propose d'abord d'être une référence et n'est pas un tutoriel sur la manière d'administrer un système de fichiers Linux ou une hiérarchie de répertoires.
Voici quelques uns des problèmes fondamentaux qui ont motivé de prime abord cet effort de standardisation :
Des différences d'opinion sont soulevées dans tout effort de standardisation. Le besoin de consensus et la pratique courante à l'intérieur de la communauté Linux devrait surpasser ces différences.
Cette norme de système de fichiers a été développée tout d'abord à l'intérieur de la liste de distribution FSSTND et avant, sur le canal FSSTND de la liste de distribution Linux-activists. Un grand nombre de développeurs Linux, de programmeurs Linux renommés, d'administrateurs système et d'utilisateurs ont envoyé des demandes et commentaires. Les volontaires qui ont contribué intensément à cette norme sont listés à la fin de ce document. Cette norme représente la vue consensuelle de ceux-ci et d'autres collaborateurs.
Cette norme cherche à approcher ces problèmes en décrivant une structure de système de fichiers bien faite, dont nous espérons que la communauté Linux la suivra volontairement. Bien que cette norme soit plus exhaustive et complète que toute autre tentative précédente de standardisation, elle ne sera probablement jamais vraiment terminée. Les besoins de la communauté Linux changeront continuellement en relation avec les technologies apparaissantes. Il est aussi possible que de meilleures solutions aux problèmes auxquels nous faisons face seront découvertes ou que nos solutions ne soient plus les meilleures possibles. Pour ces raisons, le groupe FSSTND prévoit de diffuser des ébauches supplémentaires en supplément des mises à jour périodiques de ce document.
Les commentaires se rapportant à cette norme sont les bienvenus parmi le groupe FSSTND. Tout commentaire ou suggestion de changement doit être adressé au coordinateur FSSTND, ou si vous préférez, à n'importe lequel des contributeurs listés. Les commentaires d'ordre typographique ou grammatical doivent être envoyés au coordinateur FSSTND.
Il y a aussi une FAQ, maintenue par Ian McCloghrie, qui répond à certaines des questions les plus couramment posées au sujet de cette norme. Si vous désirez implémenter la FSSTND ou si vous avez des questions, veuillez lire la FAQ FSSTND d'abord. Celle-ci est disponible par FTP anonyme à tsx-11.mit.edu dans /pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ.
S'il vous plaît n'envoyez pas de courrier électronique à la liste de distribution sans avoir contacté d'abord le coordinateur FSSTND ou l'un des contributeurs listés. Les messages non conformes ne seront pas bien reçus sur la liste de distribution.
Certaines questions sur la manière d'interpréter certains objets de ce document peuvent se poser de temps à autre. Si vous avez besoin d'une clarification, veuillez contacter le coordinateur FSSTND. Puisque cette norme représente le consensus de nombreux participants, il est important d'être certain 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 préalable.
Le coordinateur FSSTND est Daniel Quinlan <Daniel.Quinlan@linux.org>
1.2 Problèmes spécifiquesNaturellement, pendant la standardisation de la structure du système de fichiers Linux, il y a eu des problèmes spécifiques que nous avons cherché à corriger. Voici quelques uns des plus évidents et des plus grands :
Alors qu'il y a quelques uns des principaux problèmes auxquels nous avons fait face, il y a eu de nombreux problèmes supplémentaires qui demandaient à être résolus. Cette norme essaie de s'occuper de beaucoup de ces autres problèmes, mais quelque chose a peut-être été oublié. Si vous voulez porter quelque chose à notre attention, veuillez noter que certaines choses ont longtemps été débattues, mais n'ont pas été incluses dans la norme.
1.3 ObjectifsEn essayant de résoudre les problèmes ci-dessus, plusieurs objectifs ont été identifiés qui demandaient à être résolus en supplément des problèmes plus techniques. Ces buts comprennent la correction des problèmes de première importance ainsi que la validation de cette norme.
Certains de ces objectifs ont deja été atteints en totalité ou partiellement grâce à la distribution limitée d'une ébauche anticipée à tout développeur qui la demandait.
1.4 Historique et progrèsLe message originel qui a motivé cet effort de restructurer le système de fichiers Linux a été écrit par Olaf Kirsh <okir@monad.swb.de> le 2 août 1993, au canal NORMAL de la liste de distribution Linux-activists.
Peu de temps après, il a été décidé que la meilleure manière possible d'accomplir la restructuration nécessaire du système de fichiers Linux serait de créer une liste de distribution dans le but de développer une norme consensuelle.
Après une discussion exhaustive, avec étonnamment peu de flammes, une ébauche préliminaire fut écrite. Avec l'aide de plusieurs personnes consacrées, l'ébauche fut terminée et l'ébauche résultante soumise au canal FSSTND pour une discussion supplémentaire. La première ébauche fut soumise au canal le 18 septembre 1993 par Daniel Quinlan.
Alors que la discussion se poursuivait et que les ébauches préliminaires des recommandations FSSTND étaient développées plus avant, des contacts furent établis avec les distributeurs Linux accessibles qui ont alors offert leur demandes et leur support à notre effort. Beaucoup de développeurs Linux s'accordèrent sur le fait que cet effort de standardisation valait la peine et l'ont supporté.
Voici quelques uns des développeurs qui tendent à suivre la norme FSSTND, en partie ou complètement, listés par ordre alphabétique :
1.5 Conformité avec ce documentCette section définit les significations des termes "conforme" et "compatible" en ce qui concerne cette norme, et de conformité et compatibilité "partielle".
Une "implémentation" fait référence ici à une distribution, un système installé, un programme, un package (ou tout morceau similaire de programme ou de données) ou tout composant de ceux-ci.
Une implémentation est totalement conforme avec 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 spécifié dans ce document. Si le contenu d'un fichier est décrit ici, le contenu réel doit correspondre à la description. L'implémentation doit aussi essayer de trouver tous les fichiers et répertoires (externes à elle-même) tout d'abord et exclusivement aux endroits spécifiés dans cette norme.
Une implémentation est totalement compatible avec cette norme si chaque fichier ou répertoire qu'elle comporte peut être trouvé en regardant dans les endroits spécifiés ici et seront trouvés avec les contenus spécifiés ici, même si ce n'est pas la position primaire 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 qui n'en fait pas partie, le faire aux endroits spécifiés par cette norme, bien qu'elle puisse aussi essayer de les trouver à d'autres endroits (non standards).
Une implémentation est partiellement conforme ou compatible si elle est conforme à, ou est compatible avec une partie significative de ce document.
La conformité ou la compatibilité partielle n'est faite que pour s'appliquer aux distributions et non aux programmes séparés. Il faut reconnaître que l'expression "Une partie significative" est subjective, et dans les cas limites, la personne concernée devrait contacter le coordinateur FSSTND. Il est envisagé que des variations seront tolérées dans les cas limites.
Afin de se définir comme partiellement conforme à FSSTND ou partiellement compatible avec FSSTND, une implémentation doit fournir une liste de tous les endroits auxquels elle et le document FSSTND 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 FSSTND ou du coordinateur FSSTND.
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 situés correctement. Par exemple, si le système de fichiers ext2 n'est pas supporté par une distribution, les outils ext2 n'ont pas besoin d'être inclus, même s'ils sont mentionnés explicitement dans la section sur /sbin.
De plus, certaines parties de ce document sont optionnelles. Dans ce cas, ceci sera dit explicitement, ou indiqué à l'aide d'un ou plusieurs "peut", "recommende" ou "suggère". Les objets marqué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 peuvent être situées n'importe où au choix de l'implémenteur.
Le système de fichiers UNIX est caractérisé par :
Cette norme sur le système de fichiers Linux suit les mêmes principes de base que suivent la plupart des systèmes de fichiers UNIX. Notez que ce standard n'essaie pas de s'accorder sur chaque point avec une implémentation particulière du système UNIX. Cependant, beaucoup d'aspects de cette norme sont basés sur des idées trouvées dans UNIX et d'autres systèmes comme UNIX.
Ceci après une considération attentive d'autres facteurs, comprenant :
Il est possible de définir deux classements orthogonaux par catégorie de fichiers : partageables contre non partageables, et variables contre statiques.
Les données partageables sont ce qui peut être partagé entre plusieurs machines différentes; non partageables est ce qui doit être local à 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 (device lock files).
Les données statiques comprennent les binaires, les librairies, la documentation, et tout ce qui ne change pas sans intervention de l'administrateur système ; les données variables sont tout le reste qui change sans intervention de l'administrateur système.
A travers ce document, et dans tout système de fichiers bien organisé, la compréhension de ces principes 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 :
La distinction "partageable" peut être utilisée pour supporter, par exemple :
La distinction "statique" contre "variable" affecte le système de fichiers de deux manières principales :
Tableau résumé avec exemples :
| * | shareable | unshareable |
|---|---|---|
| static | /usr /home |
/etc /boot |
| variable | /var/spool/mail /var/spool/news |
/var/run /var/lock |
Cette section décrit la structure du répertoire racine. 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 :
Le principal argument utilisé pour contrer ces considérations, qui penchent pour mettre beaucoup de choses sur le système de fichiers root, est le but de garder la racine aussi petite que possible dans les limites du raisonnable. Pour plusieurs raisons, il est souhaitable de garder le système de fichiers racine petit :
Ce document, dans son état actuel d'ébauche, demande un système de fichiers sur lequel on puisse écrire (principalement dû à /etc/mtab). Cependant ceci ne nécessite pas une racine stockée entièrement en local. La partition root n'est pas obligée d'être stockée localement simplement dans le but d'être spécifique au système -- par exemple, elle peut être montée à partir d'un serveur NFS.
Les logiciels ne doivent jamais créer ou demander des fichiers spéciaux ou des sous-répertoires dans le répertoire racine. La structure du système de fichiers Linux fournit une flexibilité plus que suffisante pour n'importe quel package. Tout package qui occupe un répertoire sous la racine du système de fichiers souffre d'arrogance pure.
/ -- the root directory | +-bin Essential command binaries +-boot Static files of the boot loader +-dev Device files +-etc Machine-local system configuration +-home User home directories +-lib Shared libraries +-mnt Mount point of temporary partitions +-proc Process information pseudo-filesystem +-root Home directory for root +-sbin Essential system binaries +-tmp Temporary files +-usr Second major hierarchy +-var Variable data
Chaque répertoire listé sera discuté en détail dans une sous-section séparée ci-dessous. /usr et /var ont chacun leur propre section principales dans ce document.
L'image du noyau Linux doit être située soit dans / soit dans /boot. Si elle est située dans /, nous recommandons l'utilisation du nom vmlinux ou vmlinuz qui ont été utilisés dans les packages récents de source du noyau Linux. Des informations supplémentaires sur l'emplacement du noyau peuvent être trouvées dans la section concernant /boot, ci-dessous.
3.1 /bin : Commandes binaires utilisateur essentielles (pour tous les utilisateurs)/bin 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.
Tous les binaires uniquement pour root tels que les daemons, init, getty, update, etc. doivent être placés dans /sbin ou /usr/sbin, selon qu'ils sont essentiels ou non. Pour une discussion plus approfondie sur la définition de ce qui est essentiel sur le système de fichiers root, veuillez lire la section 6, "Problèmes et analyse supplémentaire".
Il ne doit pas y avoir de sous-répertoires à l'intérieur de /bin.
Les commandes binaires qui ne sont pas suffisamment essentielles pour rester dans /bin doivent être mises dans /usr/bin à la place. Les objets qui ne sont utilisés que par des utilisateurs non root (mail, chsh, etc.) ne sont pas assez essentiels pour être placés dans la partition root.
Fichiers obligatoires pour /bin : 3.2 /boot : fichiers statiques du chargeur de lancementCe répertoire contient tout pour le démarrage sauf les fichiers de configuration et l'installateur de carte. Au sens le plus simple, /boot est fait pour tout ce qui est utilisé avant que le noyau n'exécute /sbin/init. Ceci comprend les secteurs de boot maître sauvegardés, les fichiers de localisation des secteurs, et tout ce qui ne peut pas être édité directement à la main. Les programmes indispensables pour permettre au chargeur de boot d'être capable de lancer un fichier (comme l'installeur lilo) doivent être placés dans /sbin. Les fichiers de configuration des chargeurs de lancement doivent être situés dans /etc.
Comme déjà indiqué ci-dessus, le noyau Linux peut-être placé soit dans / soit dans /boot. Il est recommandé qu'un nom de fichier plus instructif soit utilisé si le noyau est placé dans /boot.
3.3 /dev : fichiers de périphériquesVoici le répertoire des périphériques. Il doit contenir une entrée pour chaque périphérique pour lequel le noyau Linux a été configuré et qu'il supporte.
/dev contient aussi un script nommé MAKEDEV qui peut créer des périphériques à la demande. Il peut aussi contenir un fichier MAKEDEV.local pour tout périphérique local.
MAKEDEV doit avoir des réserves pour créer n'importe quel fichier spécial de périphérique listé dans la liste majeurs/mineurs de Linux, et non seulement ceux qu'une distribution particulière installe.
Les liens symboliques de /dev ne doivent pas être distribués avec les systèmes Linux sauf ceux fournis dans la liste de périphériques Linux. Ceci parce que des configurations locales contiendront souvent des différences par rapport à la machine de développement d'un distributeur. Aussi, si un script d'installation de distribution configure les liens symboliques au moment de l'installation, ces liens symboliques ne seront pas souvent mis à jour si des changements matériels locaux ont lieu. Par contre, s'ils sont utilisés de façon responsable à un niveau local, ils peuvent être utilisés à bon escient.
Cette norme incorpore par référence la Liste de Périphériques Linux qui est maintenue par H. Peter Anvin <Peter.Anvin@linux.org>, the Linux Device Registrar. Tous les fichiers spéciaux de périphériques doivent suivre la norme de ce document, qui est disponible par ftp anonyme à ftp.yggdrasil.com dans /pub/device-list.
3.4 /etc : configuration système spécifique à la machine/etc contient des fichiers de configuration et des répertoires, qui sont locaux au système en cours.
Aucun binaire ne doit aller directement dans /etc. Les binaires qui se trouvaient dans /etc dans le passé doivent être placés dans /sbin ou /usr/sbin. Ceci comprend des fichiers tels que init, getty, et update. Les binaires comme hostname utilisés par les utilisateurs ordinaires comme l'utilisateur root ne doivent pas être placés dans /sbin mais dans /bin.
/etc -- Machine-local system configuration | +-X11 Configuration for the X Window System +-skel User skeleton configuration
/etc/skel est l'emplacement pour le "squelette" des fichiers d'utilisateurs donné par défaut aux nouveaux utilisateurs qui reçoivent un compte. Ce répertoire peut contenir des sous-répertoires pour différents groupes d'utilisateurs (par exemple, /etc/skel/staff ou /etc/skel/users).
/etc/X11 est l'emplacement recommandé pour toute la configuration X11 locale. Ce répertoire est nécessaire pour permettre un contrôle local si /usr est monté en lecture seule. Les fichiers qui doivent être dans ce répertoire comprennent Xconfig (et/ou XF86Config) et Xmodmap.
Les sous-répertoires de /etc/X11 peuvent inclure ceux de xdm et de tout autre programme (certains gestionnaires de fenêtres, par exemple) qui en ont besoin. Nous recommandons que les gestionnaires de fenêtres avec un seul fichier de configuration qui est un fichier par défaut en .*wmrc le nomment system.*wmrc (sauf s'il y a un nom de remplacement accepté partout) et n'utilisent pas de sous-répertoire. Tous les sous-répertoires de gestionnaires de fenêtre doivent être nommés de manière identique à l'instar du binaire réel du gestionnaire de fenêtres.
/etc/X11/xdm contient les fichiers de configuration de xdm. Ce sont la plupart des fichiers que l'on trouve normalement dans /usr/lib/X11/xdm ; voir la section 5, /var/lib/xdm, pour plus d'informations.
La section suivante est faite en partie pour éclairer la description du contenu de /etc avec un certain nombre d'exemples ; ce n'est pas une liste exhaustive par définition.
Fichiers obligatoires pour /etc : 3.5 /home : répertoires personnels des utilisateurs (optionnel)/home est un concept assez standard, mais c'est clairement un système de fichiers spécifique à un site. La configuration changera d'une machine sur l'autre. Cette section ne décrit qu'une suggestion d'emplacement pour les répertoires personnels des utilisateurs ; néanmoins nous recommandons que toutes les distributions Linux l'utilisent comme emplacement par défaut des répertoires personnels.
Sur de petits systèmes, chaque répertoire d'utilisateur est typiquement l'un des nombreux sous-répertoires de /home comme /home/smith, /home/torvalds, /home/operator, etc.
Sur les grands systèmes (surtout quand les répertoires /home sont partagés entre beaucoup de machines par NFS) il est utile de subdiviser les répertoires personnels des utilisateurs. La subdivision peut être faite en utilisant des sous-répertoires comme /home/personnel, /home/invites, /home/etudiants, etc.
Différentes personnes préfèrent placer les comptes utilisateurs dans des endroits variés. Par conséquent, aucun programme ne doit se fier à cet emplacement. Si vous voulez trouver le répertoire personnel d'un utilisateur, vous devez utiliser la fonction de bibliothèque getpwent(3) plutôt que de se fier au /etc/passwd parce que les informations utilisateurs peuvent être stockées à distance en utilisant des systèmes tels que NIS.
3.6 /lib : bibliothèques partagées essentielles et modules du noyauLe répertoire /lib contient les images des bibliothèques partagées nécessaires au démarrage du système et au lancement des commandes du système de fichier root.
/lib -- essential shared libraries and kernel modules | +-modules Loadable kernel modules
Ceci comprend /lib/libc.so.*, /lib/libm.so.*, le lieur dynamique partagé /lib/ld.so, et d'autres bibliothèques partagées nécessaires aux binaires de /bin et /sbin.
Les bibliothèques partagées qui ne sont nécessaires que pour les binaires de /usr (comme n'importe quel binaire X Window) n'appartiennent pas à /lib. Seules les bibliothèques nécessaires au fonctionnement des binaires de /bin et de /sbin doivent être ici. La bibliothèque libm.so.* peut aussi être placée dans /usr/lib si elle n'est pas nécessaire pour quelquechose de /bin ou /sbin.
Pour des raisons de compatibilité, /lib/cpp doit exister comme référence pour le préprocesseur C installé sur le système. L'emplacement traditionnel de ce binaire est /usr/lib/gcc-lib/<target>/<version>/cpp. /lib/cpp peut soit pointer vers ce binaire, soit vers n'importe quelle référence à ce binaire qui existe dans le système de fichiers. (Par exemple, /usr/bin/cpp est aussi souvent utilisé.)
La spécification de /lib/modules est en cours d'élaboration.
3.7 /mnt : point de montage pour les systèmes de fichiers montés temporairementCe répertoire est fourni pour que l'administrateur système puisse monter temporairement des systèmes de fichiers s'il le désire. Le contenu de ce répertoire est un problème local et ne doit pas affecter la manière dont laquelle n'importe quel programme sera exécuté.
Nous recommandons aux programmes d'installation de ne pas utiliser ce répertoire, et suggérons qu'un répertoire temporaire convenable non utilisé par le système soit utilisé à la place.
3.8 /proc : système de fichiers virtuel d'information du noyau et des processusLe système de fichiers proc est en train de devenir la méthode standard de facto sous Linux pour manipuler les informations sur les processus et le système, plutôt que /dev/kmem et autres méthodes similaires. Nous encourageons fortement ceci pour le stockage et la recherche des informations autant sur les processus que sur le noyau et la mémoire.
3.9 /root : répertoire personnel de root (optionnel)/ est par tradition le répertoire personnel du compte root sur les systèmes UNIX. /root est utilisé sur beaucoup de systèmes Linux et sur certains systèmes UNIX. Le répertoire personnel du compte root peut être déterminé par une préférence d'un développeur ou localement. Les possibilités évidentes comprennent /, /root, et /home/root.
Si le répertoire personnel de root n'est pas stocké sur la partition root il sera nécessaire de s'assurer qu'il se mettra par défaut à / s'il ne peut être localisé.
Note : nous recommandons de ne pas utiliser le compte root pour des choses courantes comme le courrier électronique ou les nouvelles, mais plutôt de l'utiliser uniquement pour l'administration des systèmes. Pour cette raison, nous recommandons que les sous-répertoires tels que Mail et News n'apparaissent pas dans le répertoire personnel du compte root. Nous recommandons que le courrier pour root et postmaster soit redirigé vers un utilisateur plus approprié.
3.10 /sbin : binaires système (binaires auparavant mis dans /etc)Les utilitaires utilisés pour l'administration du système (et autres commandes accessibles uniquement à root) sont stockés dans /sbin, /usr/sbin, et /usr/local/sbin. /sbin contient en général des binaires essentiels au démarrage du système en supplément des binaires de /bin. Tout ce qui est exécuté après que /usr soit effectivement monté (quand il n'y a pas de problèmes) doit être placé dans /usr/sbin. Les binaires d'administration système utilisés localement doivent être placés dans /usr/local/sbin.
Décider de quelles choses mettre dans les répertoires sbin est simple : si un utilisateur aura besoin de l'utiliser, elle doit aller autre part. Si elle ne sera exécutée que par les administrateurs système ou root à partir de scripts de gestion du système, elle doit alors aller dans /sbin (ou dans /usr/sbin ou /usr/local/sbin si l'objet n'est pas vital à la bonne marche du système).
Des fichiers tels que chfn que les utilisateurs n'utiliseront qu'occasionnellement doivent encore être placés dans /usr/bin. ping, bien qu'il soit absolument nécessaire pour root (réparation de réseau et diagnostic) est souvent utilisé par les utilisateurs et doit être dans /bin pour cette raison.
Les utilisateurs ordinaires ne doivent pas avoir de répertoire sbin dans leur chemin (path).
Nous recommandons que les utilisateurs aient droit d'écriture et d'exécution dans tous les fichiers de /sbin sauf, peut-être, certains programmes setuid et setgid. La division entre /bin et /sbin 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 limite entre les binaires utilisés par tout le monde et ceux utilisés principalement pour des tâches administratives. Il n'y a pas d'avantage propre en sécurité en rendant /sbin inaccessible aux utilisateurs.
Fichiers obligatoires pour /sbin: Fichiers optionnels pour /sbin:(2) Je ne peux pas trouver le nom de la bibliothèque parce que ls est lié dynamiquement, j'utilise un shell qui n'a pas ls intégré, et je ne sais pas utiliser "echo *" en remplacement.
(3) J'ai un sln statique, mais je ne sais pas quel nom donner au lien.
{ ldconfig, sln, ssync }
Divers :
Afin de s'occuper du fait que certains claviers arrivent avec une vitesse de répétition telle qu'ils en sont inutilisables, on peut installer kbdrate dans /sbin sur certains systèmes.
Puisque l'action par défaut du noyau pour la combinaison de touches Ctrl-Alt-Suppr est un redémarrage dur instantané, il est en général conseillé d'empêcher ce comportement avant de monter le système de fichiers root en mode lecture-écriture. Certains jeux de commandes init sont capables de désactiver Ctrl-Alt-Suppr, mais d'autres peuvent nécessiter le programme ctrlaltdel, qui peut être installé dans /sbin sur ces systèmes.
{ ctrlaltdel, kbdrate }
3.11 /tmp : Fichiers temporaires/tmp est utilisé pour les fichiers temporaires, de préférence sur un périphérique rapide (un système de fichiers basé sur la mémoire, par exemple).
La "persistance" des données stockées dans /tmp est différente de celle des données stockées dans /var/tmp. /tmp peut être nettoyé au moment du démarrage ou à intervalles relativement fréquents. Par conséquent, on ne doit pas s'attendre à ce que les données stockées dans /tmp y restent longtemps.
Les programmes doivent utiliser /tmp ou /var/tmp (qui était /usr/tmp à l'origine) selon ce qu'on attend des données, mais ne doivent pas compter sur une persistance particulière de n'importe quel répertoire de stockage temporaire.
Les administrateurs système peuvent faire le choix de lier /tmp à un autre répertoire, comme /var/tmp ; ceci est utile, par exemple, pour conserver de l'espace sur la partition root. En ce cas, la persistance des fichiers de /var/tmp devrait être au moins aussi longue que pour /tmp.
/tmp peut être un disque virtuel en RAM. /var/tmp ne doit jamais être situé sur un périphérique de type RAM.
/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 6Cette 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 x86Cette 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 principalesVoici 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 motsFichiers 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 siteStocker 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 standardsVoici 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 localeL'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 manuelCette 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 :
4.10 /usr/sbin : binaires système standard non essentielsCe 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'architectureToutes 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
/var -- Variable data | +-adm System administrative data, symbolic link to /var/log +-catman Locally-formatted manual pages +-lib Application state information +-local Variable data of software from /usr/local +-lock Lock files+-log Log files and directories +-named DNS files, networking only +-nis Network Information Service (NIS) database files +-preserve Saved files after crash or hang-up from ex or vi +-run Files relevant to running processes +-spool Directories for queued work to be performed later +-tmp Temporary files, used to keep /tmp small
/var contient des fichiers de données variables. Ceci inclut les répertoires et fichiers de spool, les données administratives et de rapports, et les fichiers éphémères et temporaires.
Certaines portions de /var ne sont pas partageables entre différents systèmes. Par exemple, /var/log, /var/lock, et /var/run. D'autres portions sont partageables, notamment /var/spool/mail et /var/spool/news.
/var est spécifié ici pour qu'il soit possible de monter /usr en lecture seule. Tout ce qui jadis allait dans /usr et dans lequel on écrit pendant l'opération du système (à l'opposé de l'installation et de la maintenance logicielle) devrait être dans /var.
Si on ne peut pas mettre /var dans une partition séparée, il est souvent préférable de déplacer /var hors de la partition root dans la partition /usr. (Ceci est fait quelquefois pour réduire la taille de la partition root ou quand l'espace devient petit dans la partition root.) Cependant, /var ne devrait pas être lié à /usr parce que ceci rend la séparation de /usr et de /var plus difficile et risque de créer des conflits de dénomination. À la place, liez /var à /usr/var.
5.1 /var/adm : fichiers de rapports et compte-rendus (obsolète)Ce répertoire a été remplacé par /var/log et d'autres répertoires. Ce devrait être un lien symbolique vers /var/log jusqu'à ce que tous les programmes ne se réfèrent plus à aucun fichier dans /var/adm.
utmp a été déplacé vers /var/run. Tous les fichiers de rapport ont été déplacés dans /var/log, en incluant le fichier wtmp.
Le support pour le paquetage des distributions devrait être stocké dans /var/lib/<name>.
Note : le lien symbolique /var/adm ne doit pas être nécessaire sur la plupart des systèmes ELF linux-i386 puisque le changement a été introduit avant que ELF ne soit donné au public.
5.2 /var/catman : pages de manuel formatées localement (optionnel)Ce répertoire fournit un emplacement standard pour les sites qui fournissent une partition /usr en lecture seule, mais qui veulent permettre de faire un cache des pages de manuel formatées en local. Les sites qui montent /usr en écriture (par exemple, les installations en utilisateur simple) peuvent opter de ne pas utiliser /var/catman et d'écrire les pages de manuel formatées dans les répertoires cat[1-9] de /usr directement. Nous recommandons que la plupart des sites utilisent une des options suivantes à la place :
La structure de /var/catman a besoin de refléter à la fois le fait de hiérarchies de pages de manuel multiples et la possibilité du support de plusieurs langues.
Étant donnée une page de manuel non formatée qui apparaît normalement dans /usr/<path1>/man/man[1-9], la version formatée dans le cache devrait aller dans /var/catman/<path2>/cat[1-9], où <path2> est <path1>. Les composants <path1> et <path2> sont absents dans le cas de /usr/man et /var/catman.
Par exemple, /usr/man/man1/ls.1 est formatée dans /var/catman/cat1/ls.1, et /usr/X11R6/man/<locale>/man3/XtClass.3x dans /var/catman/X11R6/<locale>/cat3/XtClass.3x.
Les pages de manuel écrites dans /var/catman/cat[1-9] peuvent à la fin être transférées dans /usr/<path>/cat[1-9] ou expirées ; de la même façon, les pages de manuel formatées dans /usr/<path>/cat[1-9] peuvent être expirées si elles n'ont pas été accédées pendant une certaine période de temps.
Si les pages de manuel pré-formatées arrivent avec un système Linux sur un support en lecture seule (un CD-ROM, par exemple), ils devraient être installés dans /usr/<path>/cat[1-9]. /var/catman est réservé à un cache en écriture pour les pages de manuel formatées.
5.3 /var/lib : information sur l'état des applications
/var/lib -- Application state information | +-emacs State directory for Emacs +-games Variable game data (score files) +-news Variable files for Cnews/INN +-texmf Variable data associated with TeX +-xdm X display manager authentication files and error logs
/var/lib/<name> est l'emplacement approprié pour le support de tous les packages de distributions. Des distributions Linux différentes peuvent utiliser des noms différents, bien sûr.
5.3.1 /var/lib/emacsLe répertoire d'état de GNU Emacs, l'emplacement des fichiers de données indépendants de l'architecture qu'Emacs modifie quand il tourne, devrait être /var/lib. En ce moment, Emacs ne situe que son répertoire de fichiers lock sous le répertoire d'état (dans <statedir>/emacs/lock), mais il pourrait faire un usage plus intensif du répertoire d'état dans le futur.
Notamment, il ne faut que l'addition d'une simple option au programme configure d'Emacs pour provoquer ce changement (avant la compilation).
5.3.2 /var/lib/gamesTout comme les sous-répertoires listés ci-dessus, toute donnée variable ayant un rapport avec les jeux situés dans /usr/games devrait être placée ici. /var/lib/games devrait tenir les données variables trouvées précédemment dans /usr/lib/games ; les données statiques, comme le texte d'aide, les descriptions de niveaux, et ainsi de suite, devraient rester dans /usr/lib/games.
5.3.3 /var/lib/news/var/lib/news devrait être utilisé pour stocker toutes les données variables associées avec les serveurs de nouvelles comme Cnews ou INN, en comprenant le fichier d'historique, le fichier actif, et ainsi de suite.
5.3.4 /var/lib/texmf/var/lib/texmf devrait être utilisé pour stocker les données variables associées avec TeX. En particulier, /var/lib/texmf/fonts stockera toutes les fontes qui sont générées automatiquement par MakeTeXPK.
Il devrait y avoir un lien de /usr/lib/texmf/fonts/tmp vers /var/lib/texmf/fonts. Ce lien permet aux utilisateurs d'utiliser le chemin unique /usr/lib/texmf/fonts/tfm en faisant des changements à leur variable d'environnement TEXFONTS. (Ceci est le chemin par défaut pour les outils TeX de Karl Berry, distribués sur ftp.cs.umb.edu:/pub/tex. (La raison pour laquelle les outils de Karl Berry sont mentionnés est qu'ils sont la norme de-facto pour les installations UNIX de TeX. Ces outils sont largement utilisée, un lien du répertoire de fontes approprié vers /var/lib/texmf/fonts devrait être fait.)
Le MakeTeXPK qui est distribué avec dvipsk placera les fichiers .pk dans fonts/pk/<device>/<fontname> (par exemple, fonts/pk/CanonCX/cmr10.300pk).
Les fichiers .pk peuvent être purgés périodiquement de l'arborescence /var/lib/texmf, ou bien peuvent être déplacées dans l'arborescence /usr/lib/texmf. Si des générateurs automatiques .mf ou .tfm sont utilisés, ils devraient placer leurs données dans les sous-répertoires mf ou tfm de /var/lib/texmf/fonts.
5.3.5 /var/lib/xdm/var/lib/xdm contient les données variables de xdm, qui consiste en les fichiers xdm-errors et tous les fichiers d'autorité xdm. Les binaires xdm comme le chooser devraient toujours être situés dans l'emplacement historique /usr/X11R6/lib/X11/xdm. Le fichier xdm-pid devrait être placé dans /var/lib/xdm malgré l'existence de /var/run. Les fichiers restants devraient être placés dans /etc/X11/xdm.
5.4 /var/local : données variables des logiciels de /usr/localCe répertoire contient toutes les données variables relatées aux logiciels trouvés dans /usr/local. Naturellement, l'implémentation de ce répertoire est laissé aux soins de l'administrateur du site. Cependant, les informations que l'on peut classer dans un autre répertoire /var ne devraient pas être placées dans /var/local. Par exemple, tous les fichiers lock vont quand même dans /var/lock.
5.5 /var/lock : fichiers lockLes fichiers lock devraient être stockés à l'intérieur de la structure de répertoire /var/lock.
Pour préserver la possibilité de monter /usr en lecture seule, aucun fichier lock ne devrait être placé sur la partition /usr.
Les fichiers lock de périphériques, comme les fichiers lock du périphérique série que l'on trouvait soit dans /usr/spool/locks soit dans /usr/spool/uucp, devraient maintenant être stockés dans /var/lock. La convention de dénomination qui devrait être utilisée est 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 lock de périphériques Linux devraient être dans le format de fichier lock HDB UUCP. Le format HDB va stocker l'identificateur de processus (PID) comme un nombre décimal en ASCII sur dix octets, avec une nouvelle ligne à la fin. Par exemple, si le processus 1230 contient un fichier lock, il contiendrait les onze caractères : espace, espace, espace, espace, espace, espace, un, deux, trois, zéro, et nouvelle ligne.
Alors, n'importe quoi qui voudrait utiliser /dev/cua0 peut lire le fichier lock et agir en conséquence (tous les locks dans /var/lock devraient être lisibles par tout le monde).
5.6 /var/log : fichiers et répertoires de rapportsLe répertoire contient divers fichiers de rapports. La plupart des rapports devraient être écrits dans ce répertoire ou dans un sous-répertoire approprié.
lastlog record of last login of each user messages system messages from syslogd wtmp record of all logins and logouts
Un lien symbolique de /var/log/utmp vers /var/run/utmp peut être requis jusqu'à ce que les programmes ne se réfèrent plus à /var/adm/utmp (/var/adm est lui-même un lien symbolique de transition vers /var/log).
5.7 /var/named : fichiers de DNSCe répertoire contient tous les fichiers de travail du serveur de nom Internet, named.
Nous recommandons que /etc/named.boot soit un lien symbolique vers /var/named/named.boot puisque /etc/named.boot est le fichier de démarrage par défaut si aucun argument n'est donnée à named.
5.8 /var/nis : fichiers de la base de données du Service d'Information Réseau (NIS)
Le Service d'Information Réseau (NIS) était connu précédemment comme les Pages Jaunes de Sun (YP). La fonctionnalité et l'emplacement des répertoires pour les deux sont les mêmes, mais le nom "Yellow Pages" (NdT Pages Jaunes) est une marque déposée au Royaume-Uni, appartenant à British Telecommunications plc, et ne peut être utilisé sans permission.
5.9 /var/preserve : fichiers sauvés après un crash ou un blocage de ex ou viCe répertoire contient les fichiers sauvés générés par toute terminaison inattendue de ex, vi, ou leurs clones.
5.10 /var/run : fichiers variables d'exécutionCe répertoire contient des fichiers d'informations système qui décrivent le système depuis qu'il a démarré. En général, 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'identificateurs de processus (PID), qui étaient placés à l'origine dans /etc, sont placés dans /var/run. La convention d'appellation des fichiers de PID est <nom-programme>.pid. Par exemple, le fichier PID de crond est appelé /var/run/crond.pid.
Le format interne des fichiers PID reste inchangé. Le fichier doit consister de l'identificateur de processus en décimal codé en ASCII, suivi d'un caractère nouvelle ligne. Par exemple, si crond était le processus numéro 25, /var/run/crond.pid contiendrait trois caractères : deux, cinq et nouvelle ligne.
Les programmes qui lisent les fichiers PID devraient être quelque peu flexibles dans ce qu'ils acceptent ; c'est-à-dire, ils devraient ignorer les espaces blancs supplémentaires, les zéros en tête, l'absence de la nouvelle ligne à la fin, ou les lignes additionnelles 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 utmp, qui stocke les informations sur qui utilise en ce moment le système, est situé dans ce répertoire.
Les programmes qui maintiennent les sockets de domaine UNIX éphémères devraient les placer dans ce répertoire.
5.11 /var/spool : répertoires de spool/var/spool est traditionnellement utilisé pour les données locales à la machine étant mises en attente en direction ou en provenance de sous-systèmes UNIX. Par exemple, les travaux d'impression sont stockés ici avant livraison au daemon de l'imprimante ligne, le courrier électronique vers l'extérieur est stocké avant livraison aux systèmes éloignés, et les fichiers UUCP sont stockés avant transmission aux voisins UUCP. Le courrier qui arrive et les nouvelles sont stockées ici avant livraison aux utilisateurs, et les travaux at et cron sont stockés avant leur exécution retardée par le daemon cron.
/var/spool -- Spool directories | +-at at jobs +-cron cron jobs +-lpd Printer spool directory +-mail User mailbox files +-mqueue Outgoing mail queue +-news News spool directory +-rwho Rwhod files +-smail Spool directories for smail +-uucp Spool directory for UUCP
Les fichiers lock UUCP devraient être placés dans /var/lock. Voyez la section ci-dessus sur /var/lock.
5.11.1 /var/spool/lpd
/var/spool/lpd -- Printer spool directory | +-<printer> Spools for a specific printer
Le fichier lock pour lpd, lpd.lock, devrait être placé dans /var/spool/lpd. Le fichier lock pour chaque imprimante devrait être placé dans le répertoire de spool pour cette imprimante et nommé lock.
5.12 /var/tmp : fichiers temporaires, utilisés pour garder /tmp petitLes fichiers dans /var/tmp sont stockés pour une durée non spécifiée (rappelez-vous s'il vous plaît que les répertoires temporaires du système ne sont pas garantis de garder des données pendant n'importe quelle durée).
Les données stockées dans /var/tmp sont typiquement nettoyées "d'une manière spécifique au système", mais en général à des intervalles moins fréquents que /tmp. Plus d'informations sur les répertoires temporaires se trouvent dans la section de la norme dédiée à /tmp (ci-dessus).
Il devrait y avoir un lien symbolique depuis /usr/tmp vers /var/tmp, pour des raisons de compatibilité.
Cette section traite de plusieurs domaines qui peuvent demander des explications plus détaillées.
6.1 Qu'est-il essentiel de faire ?La réponse est : il est essentiel de nettoyer, créer, préparer, vérifier, trouver et monter d'autres systèmes de fichiers (peut-être sur des machines distantes). Il y a d'autres définitions, mais ceci est une définition générale que la plupart des gens intègreront au moins à la leur.
6.2 RéseauLe réseau présentait un dilemme intéressant. Certaines personnes voulaient séparer la configuration et les binaires pour le réseau des autres binaires et configuration. Cependant, nous ne sommes pas d'accord. Nous pensons que le réseau n'est pas un "package", mais une partie intégrante de la plupart des machines UNIX (et ressemblantes). À cause de ceci, le réseau ne devrait pas être placé dans un répertoire isolé, mais systématiquement placé dans les répertoires appropriés.
Alors que ceci peut paraître confus en premier lieu (et ça prend un moment à digérer), en fait ça a un sens. Si vous ne pouvez monter que root pour une raison ou pour une autre et que vous avez besoin d'accéder au réseau pour réparer votre système, vous n'avez pas besoin que les fichiers soient relégués dans /usr/etc (ce qu'ils sont souvent). Les fichiers indispensables au montage de /usr dans les situations normales (et en cas d'urgence) sont placés dans l'arborescence root et tous les autres sont placés dans /usr pour limiter la taille du système de fichiers root.Les fichiers de configuration pour le réseau appartiennent à /etc.
6.3 Structures indépendantes de l'architectureLe répertoire /usr/share contient en général des fichiers indépendants de l'architecture comme les pages de manuel, la zone temporelle, les informations sur le terminal, etc. En ce moment, il n'y a pas d'architectures différentes pour Linux (NdT maintenant si :-), mais avec le temps nous devrions voir Linux inclure d'autres architectures et d'autres systèmes ressemblant à UNIX.
Une note : aucun programme ne devrait référencer quoi que ce soit dans /usr/share. Par exemple, un programme de pages de manuel ne devrait jamais regarder directement dans /usr/share/man/man1/ls.1, mais il devrait tout le temps se référer à /usr/man/man1/ls.1. Tout ce qui est dans /usr/share sera "pointé" par l'utilisation de liens symboliques provenant d'autres endroits du système, comme /usr/man, /usr/lib/<something>, etc.
On travaille toujours sur les spécifications de /usr/share.
6.4 Liens symboliquesIl y a un large éventail d'utilisations pour les liens symboliques dans chaque système de fichiers. Alors que les liens symboliques ne sont pas encouragés pour une installation par défaut (que l'on trouve après avoir installé Linux) dans une norme comme celle-ci, ils sont souvent utilisés avec bonne raison sur des systèmes différents. Le problème est que les liens symboliques devraient être là pour tout garder quand n'importe qui espère le trouver là.
Soyez préparés à accepter que certains répertoires, même ceux que l'on trouve dans le répertoire root, vont quand même être des liens symboliques. Par exemple, sur certains systèmes /home ne sera pas sur root, mais lié symboliquement à un répertoire /var, ou autre part. /home peut aussi avoir sa propre partition physique, bien sûr, et être monté de son propre chef.
De manière similaire, parce que /usr peut être sur un serveur de fichiers central monté par NFS, /usr/local pourrait être lié à /var/local. Ce changement peut être justifié en se rappelant la raison principale d'avoir /var : séparer les répertoires des fichiers qui varient avec le temps et entre différents systèmes et machines de ceux qui peuvent être partagés et en lecture seule.
Quelquefois les systèmes lieront aussi /tmp à /var/<quelquechose> si la partition root devient trop petite (ou démarre trop petite). Il y a plus d'exemples de "bons" usages des liens symboliques, mais le problème entier se réduit à deux choses : les packages doivent être capables de trouver les choses où elles les attendent (avec raison) et les liens symboliques peuvent être utilisés pour résoudre le problème dans bien des cas.
Cependant, des problèmes peuvent aussi surgir en utilisant trop de liens symboliques. Ces problèmes comprennent une sur-confiance pour que les liens symboliques résolvent les problèmes, des confusions résultant de la sur-utilisation des liens symboliques, et les préférences esthétiques de gens différents.
6.5 Binaires liés en statiqueLinux tourne en ce moment sur une grande variété de systèmes, certains en utilisateur simple avec des petits disques, certains comme serveurs dans des grands environnements en réseau. À cause de cette variété, cette norme ne met pas de règle en ce qui concerne quels binaires sont statiques ou dynamiques avec les deux exceptions suivantes. À la fois ln et sync devraient exister dans /bin ; toutes les versions liées en statique peuvent être placées dans /sbin, ou remplacer ceux de /bin.
Les grands systèmes Linux peuvent vouloir inclure d'autres binaires liés en statique (sh, init, mkfs, fsck, tunefs, mount, umount, swapon, swapoff, getty, login, et autres). Les développeurs et/ou les administrateurs système sont libres de lier statiquement/dynamiquement ceux-ci et d'autres binaires comme ils le souhaitent, tant que l'emplacement des binaires ne change pas.
Les systèmes en réseau (surtout ceux qui n'ont pas de lecteurs de disquettes), peuvent vouloir lier ifconfig, route, hostname, et d'autres utilitaires réseau en statique aussi. Ceci n'est en général pas nécessaire.
La liste de distribution FSSTND est située à <fhs-discuss@ucsd.edu>. Cette liste était située à l'origine sur la liste <linux-activists@Niksula.hut.fi> "Mail-Net" en tant que canal FSSTND. (Pour s'inscrire à la liste envoyez un courrier électronique à <listserv@ucsd.edu> avec dans le corps du message "ADD fhs-discuss".)
Merci à Network Operations à l'Université de Californie à San Diego qui nous a permis d'utiliser leur excellent serveur de listes de distribution.
Comme noté dans l'introduction, s'il vous plaît n'envoyez pas de courrier électronique à la liste de distribution sans d'abord contacter le coordinateur FSSTND ou un contributeur listé.
RemerciementsLes honneurs pour ce texte devraient être donnés aux activistes FSSTND, aux développeurs, aux administrateurs système, et aux utilisateurs dont l'avis a été essentiel à cette norme. Je voudrais aussi remercier chacun des contributeurs qui m'ont aidé à écrire, compiler, et composer ceci, une norme de consensus.
Je voudrais aussi donner des remerciements à ces développeurs Linux qui ont vu que donner un plan commun du système de fichiers à Linux est quelquechose qui va prolonger le développement du système d'exploitation Linux. Je voudrais aussi noter la bravoure et la persévérance de ces développeurs Linux qui ont commencé à suivre cette norme avant qu'elle ne soit finie.
Contributeurs d'origineDrew Eckhardt <drew@colorado.edu> Ian Jackson <ijackson@cus.cam.ac.uk> Ian McCloghrie <ian@ucsd.edu> Daniel Quinlan <Daniel.Quinlan@linux.org> Mike Sangrey <mike@sojurn.lns.pa.us> David H. Silber <dhs@glowworm.firefly.com> Theodore Ts'o <tytso@athena.mit.edu> Stephen Tweedie <sct@dcs.ed.ac.uk>
Contributeurs supplémentairesBrandon S. Allbery <bsa@kf8nh.wariat.org> Rik Faith <faith@cs.unc.edu> Stephen Harris <sweh@spuddy.mew.co.uk> Fred N. van Kempen <waltje@infomagic.com> John A. Martin <jmartin@csc.com> Chris Metcalf <metcalf@lcs.mit.edu> Ian Murdock <imurdock@debian.org> David C. Niemi <niemidc@clark.net>
Traduit le 2 juillet 1996 par Olivier Tharan