Norme de hrarchie du sysme de fichiers -- Version 2.0 Groupe pour la norme de hirarchie du systme de fichiers dite par Daniel Quinlan ABSTRACT Cette norme consiste en un ensemble d'exigences et de suggestions concernant la disposition des fichiers et des rpertoires dans un systme d'exploitation de type UNIX. Les suggestions sont faites pour faciliter l'interoprabilit des applications, des outils d'administration systme, des outils de dveloppement et des scripts, ainsi qu'une documentation plus uniforme entre ces systmes. February 1, 1998 Norme de hirarchie du systme de fichiers 1er fvrier 1998 Toutes les marques dposes et les copyrights appartiennent leurs propritaires, sauf notification spcifique. L'utilisation d'un terme dans ce document ne devrait pas tre considre comme affectant la validit de toute marque dpose ou marque de fabrique. Copyright 1994, 1995, 1996, 1997 Daniel Quinlan Nous accordons la permission de faire et de distribuer des copies exactes de cette norme la condition que le copyright et cette note de permission soient prserves sur toutes les copies. Nous accordons la permission de copier et distribuer des versions modifies de cette norme sous les conditions de copie exacte, condition que la page de titre indique qu'elle a t modifie en incluant une rfrence la norme d'origine, condition que soient incluses les informations ncessaires la recherche de la norme d'origine, et condition que le travail driv complet soit distribu sous les termes d'une note de permission identique celle-ci. Nous accordons la permission de copier et de distribuer des traductions de cette norme dans une autre langue, avec les conditions ci-dessus pour les versions modifies, part le fait que cette note de permission soit donne dans une traduction approuve par le tenant du copyright. - i - Norme de hirarchie du systme de fichiers 1er fvrier 1998 1. Introduction 1.1 tat de la norme Voici la version 2.0 de la norme de hirarchie du systme de fichiers (FHS 2.0). Les commentaires sur cette norme sont les bienvenus de la part des personnes intresses. Les suggestions de changements devraient tre faites sous la forme d'une proposition de changement du texte, accompagne des commentaires d'explication appropris. Les suggestions de cette norme sont sujettes modification. L'utilisation des informations incluses dans ce document se fait vos propres risques. 1.2 Organisation de la norme Cette norme est divise entre ces sections : 1. Introduction 2. Le systme de fichiers : tablissement de quelques principes cls. 3. Le rpertoire racine. 4. La hirarchie /usr. 5. La hirarchie /var. 6. Annexe spcifique au systme d'exploitation. 1.3 Conventions Nous recommandons que lisiez une version mise en pages de ce documents plutt que la version texte. Dans la version mise en pages, les noms de fichiers et de rpertoire sont affichs dans une police taille fixe. Les parties variables des noms de fichiers sont reprsentes par une description de leur contenu l'intrieur des caractres chevrons "<" et ">", . Les adresses de courrier lectronique sont aussi entoures de chevrons "<" et ">" mais sont indiques dans la police habituelle. Les parties optionnelles des noms de fichiers sont entoures des caractres crochet "[" et "]" et peuvent tre combines avec la convention "<" et ">". Par exemple, si on pouvait trouver un fichier existant avec ou sans extension, on pourrait le reprsenter par [.]. - 1 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Les parties de chanes variables des noms de rpertoires et de fichiers sont indiques par une toile : "*". - 2 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 1.4 Historique de la FHS Le processus de dveloppement d'une hirarchie de systme de fichiers standard a dbut en aot 1993 dans un effort de restructuration de la structure de fichiers et de rpertoires de Linux. La FSSTND, norme pour une hirarchie du systme de fichiers spcifique au systme d'exploitation Linux, est sortie le 14 fvrier 1994. Des versions successives sont sorties le 9 octobre 1994 et le 28 mars 1995. Au dbut de 1995, avec l'aide de membres de la communaut de dveloppement BSD, il a t dcid de dvelopper une version de FSSTND plus complte pour englober non seulement Linux mais aussi les autres systmes de type UNIX. En dfinitive, nous avons fait un effort concert pour nous concentrer sur des problmes gnraux aux systmes de type UNIX. En reconnaissance de cette ouverture, le nom de la norme a t modifi pour devenir Norme de hirarchie du systme de fichiers ou FHS en abrg. (NDT : en anglais, FHS veut dire Filesystem Hierarchy Standard.) Les volontaires qui ont contribu activement cette norme se trouvent la fin de ce document. Cette norme reprsente un consensus entre les points de vue de ceux-ci et d'autres contributeurs. 1.5 tendue Ce document spcifie une hirarchie de systme de fichiers standard pour les systmes de fichiers FHS en spcifiant l'emplacement des fichiers et rpertoires, et le contenu de certains fichiers systme. Cette norme a t faite pour tre utilise par les intgrateurs de systmes, les dveloppeurs de paquetages et les administrateurs systme dans la construction et la maintenance de systmes de fichiers se conformant FHS. Elle est tout d'abord destine servir de rfrence et n'est pas un tutoriel sur la manire de grer une hirarchie de systme de fichiers conforme. La FHS est base sur des travaux prliminaires sur FSSTND, une norme d'organisation du systme de fichiers pour le systme d'exploitation Linux. Elle est base sur la FSSTND pour pallier des problmes d'interoprabilit non seulement dans la communaut Linux mais dans un horizon plus vaste incluant les systmes d'exploitation bass sur 4.4BSD. Elle incorpore les leons concernant le support de plusieurs architectures et les demandes en matire de rseaux htrognes, leons apprises dans le monde BSD ou ailleurs. Bien que cette norme soit plus complte que les tentatives prcdentes sur la normalisation de la hirarchie de systmes de fichiers, des mises jour priodiques peuvent s'avrer ncessaires mesure que les demandes changent par rapport la technologie mergeante. Il est aussi possible que de meilleures solutions aux problmes voqus ici soient dcouvertes ou que nos solutions ne soient plus les meilleures possibles. Des brouillons supplmentaires pourront tre apports en plus des mises jour priodiques de ce document. Cependant, un des buts - 3 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 suivis est la compatibilit ascendante entre une version de ce document et la suivante. Les commentaires relatifs cette norme sont les bienvenus. Tout commentaire ou suggestion de changement devraient tre adresss l'diteur de la FHS (Daniel Quinlan ), ou si vous prfrez, la liste de distribution FHS. Les commentaires de nature typographique ou grammaticale doivent tre adresss directement l'diteur de la FHS. Nous vous demandons de contacter en premier l'diteur de la FHS avant d'envoyer un courrier la liste de distribution afin d'viter un nouveau dbat sur des sujets anciens. Les messages mal conus ne seront pas bien vus sur la liste de distribution. Des questions concernant l'interprtation des objets de ce documents peuvent se poser de temps en temps. Si vous avez besoin de prcisions, veuillez contacter l'diteur de la FHS. Puisque cette norme reprsente le consensus de beaucoup de participants, il est important de s'assurer que toute interprtation reprsente aussi l'opinion collective. Pour cette raison, il peut ne pas tre possible de fournir une rponse immdiate sauf si la demande a dj fait l'objet d'une discussion. 1.6 Suggestions gnrales Voici quelques unes des suggestions qui ont t utilises dans le dveloppement de cette norme : Rsoudre des problmes techniques en limitant les difficults lies la transition. Faire une spcification relativement stable. Obtenir l'approbation des distributeurs, des dveloppeurs, et autres dcideurs dans les groupes de dveloppement adquats et encourager leur participation. Fournir une norme attractive pour les implmenteurs des diffrents systmes de type UNIX. 1.7 Audience vise L'audience vise par cette norme comprend, mais n'est pas limite aux groupes de personnes suivants : Dveloppeurs de systmes Intgrateurs et distributeurs de systmes - 4 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Dveloppeurs d'applications Auteurs de documentations Administrateurs systme et autres personnes intresses ( des fins d'information) 1.8 Conformit_avec ce document Cette section dfinit la signification des termes "conforme" et "compatible" en ce qui concerne cette norme, et de conformit et compatibilit "partielle". Une "implmentation" fait ici rfrence une distribution, un systme install, un programme, un paquetage (ou toute partie similaire d'un logiciel ou de donnes), ou tout composant de ceux-ci. Une implmentation est totalement conforme cette norme si chaque exigence de cette norme est satisfaite. Chaque fichier ou rpertoire faisant partie de l'implmentation doit tre situ comme il est spcifi dans ce document. Si le contenu d'un fichier est dcrit ici, le contenu vritable doit correspondre sa description. L'implmentation doit aussi tenter de trouver tout fichier ou rpertoire (extrieur lui- mme) au premier abord ou exclusivement l'endroit spcifi dans cette norme. Une implmentation est totalement compatible avec cette norme si chaque fichier ou rpertoire qu'elle contient peut tre trouv en regardant l'endroit spcifi ici et sera trouv avec un contenu identique ce qui est spcifi ici, mme si ce n'est pas l'emplacement de base ou physique du fichier ou du rpertoire en question. L'implmentation doit, quand elle essaie de trouver un fichier ou un rpertoire n'en faisant pas partie, le faire l'endroit spcifi dans cette norme, bien qu'elle puisse aussi tenter de le trouver d'autres endroits (non standards). Une implmentation est partiellement conforme ou compatible si elle est conforme ou compatible avec une partie significative de ce document. La conformit ou compatibilit partielle n'est faite pour s'appliquer qu'aux distributions et non des programmes spars. L'expression "une partie significative" est effectivement subjective, et dans les cas limites, la personne concerne devrait contacter l'diteur de la FHS. Nous avons anticip le fait que des variations soient tolres dans les cas limites. Afin de se dfinir comme partiellement conforme la FHS ou partiellement compatible avec la FHS, une implmentation doit fournir une liste de tous les endroits auxquels elle et le document FHS diffrent, en plus d'une explication brve de la raison de cette diffrence. Cette liste sera fournie avec l'implmentation en question, et aussi mise disposition de la liste de distribution FHS ou de l'diteur de la FHS. - 5 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Les termes "doit", "devrait", "contient", "est" et ainsi de suite doivent tre lus comme des exigences pour la conformit ou la compatibilit. Notez qu'une implmentation n'a pas besoin de contenir tous les fichiers et rpertoires spcifis dans cette norme pour tre conforme ou compatible. Il est simplement ncessaire que les fichiers qu'elle contient soient placs correctement. Par exemple, si le systme de fichiers minix n'est pas support par une distribution, les outils minix n'ont pas besoin d'tre inclus, mme s'ils sont mentionns explicitement dans la section sur /sbin. De plus, certaines parties de ce document sont optionnelles. Dans ce cas, ceci sera dit explicitement, ou indiqu__l'aide d'un ou plusieurs mots parmi "peut", "recommande" ou "suggre". Les objets indiqus comme optionnels n'ont pas de porte sur la conformit_ou la compatibilit_ d'une implmentation ; ce sont des suggestions faites pour encourager la pratique courante, mais ils peuvent tre situs n'importe o_au gr_de l'implmenteur. - 6 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 2. Le systme de fichiers Le systme de fichiers UNIX est caractris par : Une structure hirarchique Le traitement uniforme des fichiers de donnes La protection des fichiers de donnes Cette norme suppose que le systme d'exploitation sous-jacent au systme de fichiers conforme la FHS supporte les mmes possibilits de scurit de base que l'on trouve dans la plupart des systmes de fichiers UNIX. Notez que cette norme n'essaie pas d'tre en accord au mieux possible avec une implmentation particulire d'un systme UNIX. Cependant, beaucoup d'aspects de cette norme sont bases sur des ides que l'on trouve dans UNIX et autres systmes de type UNIX. Ceci aprs une considration attentive d'autres facteurs, comprenant : Des pratiques courantes et saines dans les systmes de type UNIX. L'implmentation d'autres structures de systmes de fichiers Des normes applicables Il est possible de dfinir deux catgories orthogonales de fichiers : partageables contre non partageables, et variables contre statiques. Les donnes partageables sont ce qui peut tre partag entre plusieurs machines diffrentes ; non partageables est ce qui doit tre spcifique une machine particulire. Par exemple, les rpertoires personnels des utilisateurs sont des donnes partageables, mais pas les fichiers de blocage de priphriques (locks). Les donnes statiques comprennent les binaires, les bibliothques, la documentation, et tout ce qui ne change pas sans l'intervention de l'administrateur systme ; les donnes variables sont tout le reste qui change sans l'intervention de l'administrateur systme. Pour faciliter la sauvegarde, l'administration et le partage de fichiers sur des rseaux de systmes htrognes, il est prfrable d'tablir une correspondance simple et aisment comprhensible entre les rpertoires (surtout les rpertoires considrs comment des points de montage potentiels) et le type de donnes qu'ils contiennent. travers ce document, et dans tout systme de fichiers bien organis, la comprhension de ce principe de base aidera diriger la structure et lui apporter une cohrence supplmentaire. La distinction entre donnes partageables et non partageables est ncessaire pour plusieurs raisons : - 7 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Dans un environnement en rseau (par exemple, plus d'un hte par site), il y a une bonne partie des donnes qui peuvent tre partages entre les diffrentes machines pour sauver de la place et faciliter la tche de maintenance. Dans un environnement en rseau, certains fichiers contiennent des informations spcifiques une seule machine. Par consquent ces systmes de fichiers ne peuvent tre partags (sans prendre des mesures spciales). Historiquement, certaines implmentations des systmes de fichiers de type UNIX ont mlang des donnes partageables et non partageables dans la mme hirarchie, rendant difficile le partage de grandes parties du systme de fichiers. La distinction "partageable" peut tre utilise pour supporter, par exemple : Une partition /usr (ou des composants de /usr) monts (en lecture seule) travers le rseau (en utilisant NFS). Une partition /usr (ou des composants de /usr) monts partir d'un support en lecture seule. Un CD-ROM peut tre considr comme un systme de fichiers en lecture seule partag avec d'autres systmes conformes la FHS, en utilisant le systme de courrier comme un "rseau". La distinction "statique" contre "variable" affecte le systme de fichiers de deux manires principales : Puisque / contient _la fois des donnes statiques et variables, il doit tre mont_en lecture-criture. _Puisque le traditionnel /usr contient la fois des donnes variables et statiques, et puisque nous voudrions le monter en lecture seule (voir ci-dessus), il est ncessaire de fournir une mthode pour avoir /usr mont_en lecture seule. Ceci est obtenu par la cration d'une hirarchie /var qui est monte en lecture-criture (ou qui fait partie d'une autre partition en lecture-ecriture, telle que /), qui remplace bien des fonctions traditionnelles de la partition /usr. Voici un tableau pour rsumer le tout. Puisque ce graphique contient des exemples gnraliss, il peut ne pas s'appliquer chaque implmentation possible d'un systme conforme la FHS. - 8 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 +---------+-----------------+-----------------+ | | partageable | non partageable | +---------+-----------------+-----------------+ |statique | /usr | /etc | | | /opt | /boot | +---------+-----------------+-----------------+ |variable | /var/mail | /var/run | | | /var/spool/news | /var/lock | +---------+-----------------+-----------------+ - 9 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 3. Le rpertoire racine Cette section dcrit la structure du rpertoire racine (root). Le contenu du systme de fichiers root doit tre adquat pour dmarrer, reconstituer, rtablir et/ou rparer le systme : Pour dmarrer un systme, il doit y avoir suffisamment de choses sur la partition racine pour monter d'autres systmes de fichiers. Ceci comprend les utilitaires, la configuration, les informations du chargeur de dmarrage, et d'autres donnes de dmarrage essentielles. /usr, /opt et /var sont faits pour pouvoir tre situs sur d'autres systmes de fichiers. _Pour permettre le rtablissement et/ou la rparation d'un systme, les utilitaires ncessaires au mainteneur expriment_pour diagnostiquer et reconstruire un systme endommag_doivent tre prsents sur le systme de fichiers racine. _Pour reconstituer un systme, les utilitaires ncessaires _la reconstitution _partir des sauvegardes systme (sur disque, bande, etc.) doivent tre prsents sur le systme de fichiers racine. Le principal argument utilis_pour contrer ces considrations, qui penchent pour mettre beaucoup de choses sur le systme de fichiers racine, est le but de garder la racine aussi petite que possible dans les limites du raisonnable. Pour plusieurs raisons, il est souhaitable de limiter la taille du systme de fichiers racine : _Il est mont_de temps en temps _partir d'un moyen de stockage trs petit. _Le systme de fichiers racine contient beaucoup de fichiers de configuration spcifiques au systme. Les exemples possibles comprennent un noyau spcifique au systme, un nom d'hte diffrent, etc. Ceci veut dire que le systme de fichiers racine n'est pas toujours partageable entre des systmes en rseau. Limiter sa taille sur des systmes en rseau minimise l'espace perdu en fichiers non-partageables sur les serveurs. Cela permet aussi d'avoir des stations de travail avec des disques durs locaux plus petits. _Bien que vous puissiez avoir le systme de fichiers racine sur une grande partition, et pouvez le remplir _votre aise, il y aura des gens avec des partition plus petites. Si vous avez plus de fichiers installs, vous pourrez trouver des incompatibilits avec d'autres systmes qui utilisent des systmes de fichiers racine sur des partitions plus petites. Si vous tes dveloppeur vous pouvez changer votre hypothse en un problme pour un grand nombre d'utilisateurs. _Les erreurs de disque qui corrompent les donnes sur le systme de fichiers racine sont un problme plus important que les erreurs sur - 10 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 tout autre partition. Un systme de fichiers racine petit est moins sujet _la corruption _la suite d'un plantage systme. Les logiciels ne doivent jamais crer ou demander des fichiers spciaux ou des sous-rpertoires dans le rpertoire racine. D'autres emplacements dans la hirarchie FHS fournissent plus de flexibilit_qu'il n'en faut pour tout paquetage. Raison d'tre Il y a plusieurs raisons pour lesquelles l'introduction d'un nouveau rpertoire dans le systme de fichiers racine est interdit : Ceci demande de la place sur une partition racine que l'administrateur systme veut garder petite et simple pour des raisons de performance ou de scurit. Ceci contredit toute logique que l'administrateur systme a pu mettre en place pour distribuer des hirarchies de fichiers standards sur des volumes montables. / -- le rpertoire racine | +-bin Binaires des commandes essentielles +-boot Fichiers statiques du chargeur de dmarrage +-dev Fichiers de ripriques +-etc Configuration systme spcifique la machine +-home pertoires personnels des utilisateurs +-lib Bibliothques partages essentielles et modules du noyau +-mnt Point de montage des partitions temporaires +-opt Paquetages d'applications logicielles supplmentaires +-root pertoire personnel de l'utilisateur root +-sbin Binaires systmes essentiels +-tmp Fichiers temporaires +-usr Hirarchie secondaire +-var Dones variables Chaque pertoire listci-dessus est scifien tail dans des sous- sections paes ci-dessous. /usr et /var ont chacun une section compte dans ce document cause de la complexitde ces pertoires. L'image du noyau du sysme d'exploitation doittre situsoit dans / soit dans /boot. Les informations suppmentaires sur l'emplacement du noyau se trouvent dans la section concernant /boot ci-dessous. 3.1 /bin : binaires de commandes utilisateurs essentielles (pour tous les utilisateurs) /bin contient des commandes qui peuvent tre utilises _la fois par l'administrateur systme et les utilisateurs, mais qui sont obligatoires en mode utilisateur simple. Il peut aussi contenir des commandes utilises indirectement par des scripts. - 11 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Il ne devrait pas y avoir de sous-rpertoires _l'intrieur de /bin. Les binaires des commandes qui ne sont pas suffisamment essentielles pour rester dans /bin doivent tre mises dans /usr/bin, la place. Les objets qui ne sont utiliss que par des utilisateurs non root (mail, chsh, etc.) ne sont pas assez essentiels pour tre placs dans la partition racine. Fichiers obligatoires pour /bin : Commandes gnrales : Les commandes suivantes ont t incluses parce qu'elles sont essentielles. Certaines sont prsentes cause de leur emplacement traditionnel dans /bin. { cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, ed, false, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, setserial, sh, stty, su, sync, true, umount, uname } Si /bin/sh est le Bash, alors /bin/sh devrait tre un lien symbolique ou dur vers /bin/bash puisque Bash se comporte de manire diffrente quand il est appel_en tant que sh ou bash. pdksh, qui peut tre /bin/sh sur certains disques d'installation, devrait tre arrang_de la sorte avec /bin/sh pointant vers /bin/ksh. L'utilisation d'un lien symbolique dans ces cas permet aux utilisateurs de voir aisment que /bin/sh n'est pas un vrai shell de Bourne. Puisque l'emplacement standard de-facto du shell C est /bin/csh, si et seulement si un shell C ou quivalent (comme tcsh) est disponible sur le systme, il devrait tre disponible par le nom /bin/csh. /bin/csh peut tre un lien symbolique vers /bin/tcsh ou /usr/bin/tcsh. Note : les commandes [ et test sont intgres dans les remplacements du shell de Bourne (/bin/sh) les plus couramment utiliss. Ces deux commandes ne doivent pas tre places dans /bin ; elles peuvent tre places dans /usr/bin. Elles doivent tre incluses comme binaires spars avec tout systme UNIX ou de type UNIX essayant de se conformer la norme POSIX.2. Commandes de remise en tat : Ces commandes ont t ajoutes pour permettre la remise en tat d'un systme (en supposant que / soit intact). { tar, gzip, gunzip (lien vers gzip), zcat (lien vers gzip) } - 12 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Si les sauvegardes systme sont faites en utilisant des programmes autres que gzip et tar, alors la partition racine devrait contenir les composants de remise en tat minimaux. Par exemple, beaucoup de systmes devraient inclure cpio puisque c'est l'utilitaire de sauvegarde le plus couramment utilis aprs tar. Inversement, si l'on est sr de ne faire aucune remise en tat de la partition racine, ces binaires peuvent alors tre omis (par exemple, une partition racine en ROM, montant /usr en NFS). Si la remise en tat d'un systme est prvue travers le rseau, alors ftp ou tftp (avec tout ce qui est ncessaire l'tablissement d'une connexion ftp) doit tre disponible sur la partition racine. Les commandes de remise en tat peuvent apparatre soit dans /bin soit dans /usr/bin sur des systmes diffrents. Commandes rseau : Voici les seuls binaires ncessaires pour le rseau, autres que ceux de /usr/bin ou /usr/local/bin, et que la fois root et les utilisateurs voudront ou auront besoin d'excuter. { domainname, hostname, netstat, ping } 3.2 /boot : fichiers statiques du chargeur de dmarrage Ce rpertoire contient tout ce qu'il faut pour le processus de dmarrage part les fichiers de configuration et l'installeur de carte. Ainsi, /boot stocke les donnes utilises avant que le noyau ne commence _ excuter des programmes en mode utilisateur. Ceci peut comprendre les secteurs de dmarrage principaux sauvegards, les fichiers de cartes des secteurs, et tout autre donne qui n'est pas directement dite _la main. Les programmes ncessaires _ce que le chargeur de dmarrage soit capable de dmarrer sur un fichier doivent tre placs dans /sbin. Les fichiers de configuration pour les chargeurs de dmarrage doivent tre placs dans /etc. Le noyau du systme d'exploitation doit tre situ_soit dans / soit dans /boot Note : sur certaines machines i386, il peut tre ncessaire que /boot soit situ_sur une partition spare situe compltement en-dessous du cylindre 1024 du priphrique de dmarrage _cause de contraintes matrielles. 3.3 /dev : fichiers de priphriques Le rpertoire /dev est l'emplacement des fichiers spciaux ou de priphriques. S'il est possible que des priphriques dans /dev aient besoin d'tre - 13 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 crs la main, /dev contiendra une commande nomme MAKEDEV, qui pourra crer les priphriques au besoin. Il peut aussi disposer d'une commande MAKEDEV.local pour tout priphrique local. Au besoin, MAKEDEV doit avoir de quoi crer n'importe quel priphrique qu'on pourrait trouver dans le systme, et non pas simplement ceux qu'une implmentation particulire installe. 3.4 /etc : configuration systme spcifique _la machine /etc contient les fichiers et les rpertoires de configuration spcifiques au systme en cours. Aucun binaire ne devrait tre situ_dans /etc. /etc -- configuration systme spcifique la machine | +-X11 Configuration pour le sysme X Window +-opt Configuration pour /opt La section suivante sert surtout illustrer la description du contenu de /etc avec un certain nombre d'exemples ; ce n'est surtout pas une liste exhaustive. Fichiers obligatoires pour /etc : Fichiers gnraux : { adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group, inittab, confissue, ld.so.conf, lilo.conf, motd, mtab, mtools, passwd, profile, securetty, shells, syslog.conf, ttytype } _Fichiers de rseau : { exports, ftpusers, gateways, host.conf, hosts, hosts.allow, hosts.deny, hosts.equiv, hosts.lpd, inetd.conf, networks, printcap, protocols, resolv.conf, rpc, services } Notes : La mise en place des scripts de commandes invoqus au dmarrage peut ressembler aux modles System V ou BSD. Des spcifications supplmentaires dans ce domaine pourront tre ajoutes _une version future de la norme. Les systmes qui utilisent la suite shadow password auront des fichiers de configuration supplmentaires dans /etc (/etc/shadow et autres) et des programmes dans /usr/sbin (useradd, usermod, et autres). - 14 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 3.4.1 /etc/X11 : Configuration pour le systme X Window /etc/X11 est l'emplacement recommand_pour toute configuration X11 spcifique _la machine. Ce rpertoire est ncessaire pour permettre un contrle local si /usr est mont en lecture seule. Les fichiers qui devraient tre dans ce rpertoire comprennent Xconfig (et/ou XF86Config) et Xmodmap. Les sous-rpertoires de /etc/X11 peuvent inclure ceux pour xdm et pour tout autre programme (certains gestionnaires de fentres, par exemple) qui en a besoin. Nous recommandons que les gestionnaires de fentres qui n'ont qu'un fichier de configuration par dfaut .*wmrc le nomment system.*wmrc (sauf s'il existe un nom de rechange largement reconnu) et n'utilisent pas de sous-rpertoire. Tout sous-rpertoire de gestionnaire de fentres devrait tre nomm_du mme nom que le binaire rel du gestionnaire de fentres. /etc/X11/xdm contient les fichiers de configuration pour xdm. Ce sont la plupart des fichiers que l'on trouve habituellement dans /usr/lib/X11/xdm. Certaines donnes variables et locales pour xdm sont stockes dans /var/state/xdm. 3.4.2 /etc/opt : fichiers de configuration pour /opt Les fichiers de configuration spcifiques la machine pour les paquetages des logiciels d'application supplmentaires seront installs dans le rpertoire /etc/opt/, o_ est le nom du sous-rpertoire de /opt o_les donnes statiques de ce paquetage sont stockes. Aucune structure n'est impose sur la disposition interne de /etc/opt/. Si un fichier de configuration doit rsider dans un endroit diffrent pour que le paquetage ou le systme fonctionne correctement, on peut le placer dans un endroit diffrent de /etc/opt/. Raison d'tre : Voir la raison d'tre pour /opt. 3.5 /home : rpertoires personnels des utilisateurs (optionnel) /home est un concept trs standard, mais c'est clairement un systme de fichiers spcifique au site. Sa mise en place sera diffrente d'une machine _l'autre. Cette section ne dcrit qu'un ordonnancement suggr_ des rpertoires personnels des utilisateurs ; nanmoins nous recommandons que toutes les distributions conformes _la FHS l'utilisent comme emplacement par dfaut des rpertoires utilisateurs. Sur les petits systmes, chaque rpertoire utilisateur est en gnral l'un des nombreux sous-rpertoires de /home comme /home/dupont, /home/torvalds, /home/admin, etc. - 15 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Sur des grands systmes (surtout quand les rpertoires /home sont partags entre beaucoup d'htes par NFS) il est utile de subdiviser les rpertoires personnels des utilisateurs. Le partage peut se faire en utilisant des sous-rpertoires comme /home/equipe, /home/invites, /home/eleves, etc. D'autres personnes prfrent placer les comptes utilisateurs _divers autres endroits. Par consquent, aucun programme ne devrait se fier _ cet endroit. Si vous voulez trouver le rpertoire personnel d'un utilisateur, vous devriez utiliser la fonction de bibliothque getpwent(3) plutt que de compter sur /etc/passwd parce que les informations sur les utilisateurs peuvent tre stockes _distance en utilisant des systmes tels que NIS. 3.6 /lib : bibliothques partages importantes et modules du noyau Le rpertoire /lib contient les images des bibliothques partages ncessaires au dmarrage du systme et pour lancer les commandes du systme de fichiers racine. /lib -- bibliothques partages importantes et modules du noyau | +-modules modules chargeables du noyau Ceci comprend /lib/libc.so.*, /lib/libm.so.*, lditeur de liens dynamiques partas /lib/ld.so, et d'autres bibliothques partages ncessaires pour les binaires de /bin et /sbin. Les bibliothques partages ncessaires uniquement aux binaires de /usr (comme n'importe quel binaire pour X Window) n'appartiennent pas /lib. Seules les bibliothques partages ncessaires au fonctionnement des binaires de /bin et /sbin devraient se trouver ici. La bibliothque libm.so.* peut aussi se trouver dans /usr/lib si elle n'est pas ncessaire dans /bin ou /sbin. Pour des raisons de compatibilit, /lib/cpp doit exister et se rer au p-processeur C installsur le sysme. L'emplacement traditionnel de ce binaire est /usr/lib/gcc-lib///cpp. /lib/cpp peut soit pointer vers ce binaire, soit vers toute rence ce binaire qui existe dans le sysme de fichiers. (Par exemple, /usr/bin/cpp est de mme souvent utilis.) La spcification pour /lib/modules est en cours dlaboration. 3.7 /mnt : point de montage pour les systmes de fichiers monts temporairement Ce rpertoire est install pour que l'administrateur systme puisse monter de manire temporaire et au besoin des systmes de fichiers. Le contenu de ce rpertoire est une affaire locale et ne devrait pas - 16 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 affecter la manire dont n'importe quel programme est lanc. Nous sommes opposs l'utilisation de ce rpertoire par les programmes d'installation, et nous suggrons qu'un rpertoire temporaire convenable non utilis par le systme soit utilis la place. 3.8 /opt : paquetages de logiciels d'applications supplmentaires /opt -- paquetages de logiciels d'applications supplmentaires | +- spare, o est un nom crivant le paquetage logiciel. Les programmes devanttre lans par les utilisateurs seront sits dans le pertoire /opt//bin. Si le paquetage comprend des pages de manuel UNIX, elle seront situes dans /opt//man et la me structure que /usr/share/man sera utilise. Les rpertoires /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, et /opt/man sont rservs l'usage de l'administrateur systme local. Les paquetages peuvent fournir des fichiers de "lancement" (front-end) faits pour qu'un administrateur systme local les place (en faisant un lien ou en les copiant) dans ces rpertoires rservs, mais ils devront fonctionner normalement en l'absence de ces rpertoires rservs. Les fichiers de paquetage variables (qui changent avec un usage normal) devraient tre installs dans /var/opt. Voyez la section sur /var/opt pour plus d'informations. Les fichiers de configuration spcifiques la machine devraient tre installs dans /etc/opt. Voyez la section sur /etc/opt pour plus d'informations. Aucun autre fichier de paquetage ne devrait exister en dehors des hirarchies /opt, /var/opt et /etc/opt sauf pour les fichiers de paquetage qui doivent sider dans des endroits scifiques l'inrieur de l'arborescence du sysme de fichiers afin de fonctionner correctement. Par exemple, les fichiers de bloquage des ripriques doiventtre plas dans /var/lock et les priphriques dans /dev. Raison d'tre L'utilisation de /opt pour les logiciels supplmentaires est une pratique bien tablie dans la communaut_UNIX. L'interface Binaire d'Applications (ABI) System V [AT&T 1990], base sur la Dfinition d'Interface System V (troisime dition) fournit une structure /opt trs - 17 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 similaire celle dcrite ici. La Norme de Compatibilit Binaire Intel version 2 (iBCS2) fournit aussi une structure similaire pour /opt. En gnral, toutes les donnes ncessaires au support d'un paquetage sur un systme doivent tre prsentes dans /opt/, y compris les fichiers destins tre copis dans /etc/opt/ et /var/opt/ ainsi que dans les rpertoires rservs de /opt. 3.9 /root : rpertoire personnel pour l'utilisateur root (optionnel) / est traditionnellement le rpertoire personnel du compte root sur les systmes UNIX. /root est utilis sur de nombreux systmes Linux et sur certains systmes UNIX (afin de rduire l'encombrement du rpertoire /). Le rpertoire personnel du compte root peut tre dtermin_par une prfrence globale au niveau du dveloppeur ou locale. Les possibilits videntes comprennent /, /root et /home/root. Si le rpertoire personnel du compte root n'est pas stock sur la partition racine il sera ncessaire de s'assurer qu'il prendra la valeur / par dfaut si on ne peut le trouver. Note : nous nous opposons _l'utilisation du compte root pour des choses simples comme le courrier lectronique ou les nouvelles, et recommandons qu'il ne soit utilis_qu'au titre de l'administration systme. Pour cette raison, nous recommandons que les sous-rpertoires tels que Mail et News n'apparaissent pas dans le rpertoire personnel du compte root, et que le courrier _destination des rles administratifs comme root, postmaster ou webmaster soient redirigs vers un utilisateur appropri. 3.10 /sbin : binaires systmes (qui se trouvaient autrefois dans /etc) Les utilitaires utiliss pour l'administration systme (et autres commandes faites uniquement pour root) sont stocks dans /sbin, /usr/sbin et /usr/local/sbin. /sbin contient typiquement des binaires essentiels au dmarrage du systme en plus des binaires de /bin. Tout ce qui est excut_aprs qu'il soit sr que /usr soit mont (quand il n'y a pas de problmes) devrait aller dans /usr/sbin. Les binaires d'administration systme spcifiques au systme devraient tre installs dans /usr/local/sbin. Dcider de ce qui va dans les rpertoires "sbin" est simple : si un utilisateur normal (pas un administrateur systme) doit le lancer directement, il devrait alors aller dans l'un des rpertoires "bin". Les utilisateurs ordinaires ne devraient mettre aucun des rpertoires sbin dans leur chemin d'accs (path). Note : par exemple, les fichiers tels que chfn que les utilisateurs n'utilisent que de temps en temps devraient quand mme tre placs dans /usr/bin. ping, bien qu'il ne soit absolument ncessaire que pour root (remise en tat et diagnostic rseau) est souvent utilis_par les - 18 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 utilisateurs et pour cette raison devrait exister dans /bin. Nous recommandons que les utilisateurs aient les permissions de lecture et d'excution pour tout ce qui se trouve dans /sbin mis _part, peut-tre, certains programmes setuid et setgid. La division entre /bin et /sbin n'a pas t_cre pour des raisons de scurit_ou pour empcher les utilisateurs de voir le systme d'exploitation, mais pour fournir une bonne sparation entre les binaires que tout le monde utilise et ceux qui sont tout d'abord utiliss pour des tches d'administration. Il n'y a pas d'avantage spcifique pour la scurit__rendre /sbin inaccessible aux utilisateurs. Fichiers obligatoires pour /sbin : Commandes gnrales : { clock, getty, init, update, mkswap, swapon, swapoff, telinit } _Commandes d'extinction : { fastboot, fasthalt, halt, reboot, shutdown } (ou toute combinaison des fichiers ci-dessus, pourvu que shutdown soit inclus.) _Commandes de gestion du systme de fichiers : { fdisk, fsck, fsck.*, mkfs, mkfs.* } * = un ou plus parmi ext, ext2, minix, msdos, xia et peut-tre d'autres Commandes rseau : { ifconfig, route } 3.11 /tmp : fichiers temporaires Le rpertoire /tmp devra re mis _la disposition des programmes qui ont besoin de crer des fichiers temporaires. Bien que les donnes stockes dans /tmp puissent tre effaces d'une manire spcifique chaque site, il est recommand que les fichiers et rpertoires situs dans /tmp soient effacs _chaque dmarrage du systme. Les programmes ne devront pas supposer que tout fichier ou rpertoire de /tmp est prserv entre deux lancements de ces programmes. - 19 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Raison d'tre : La norme IEEE P1003.2 (POSIX, partie 2) donne des obligations similaires la section ci-dessus. FHS a ajout la recommandation du nettoyage de /tmp au dmarrage sur la base de prcdents historiques et de pratique commune, mais n'en a pas fait une obligation parce que l'administration systme n'entre pas dans l'objectif de cette norme. - 20 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 4. La hirarchie /usr /usr est la deuxime grande partie du systme de fichiers. /usr contient des donnes partageables, en lecture seule. Ceci veut dire qu'on devrait pouvoir partager /usr entre plusieurs machines diverses se conformant _ FHS et on ne devrait pas y crire. Toute information spcifique _la machine ou qui varie avec le temps est stocke autre part. Aucun grand paquetage logiciel ne devrait utiliser un sous-rpertoire direct sous la hirarchie /usr. Exception est faite du systme X Window cause d'un norme prcdent et d'une pratique largement suivie. Cette section de la norme spcifie l'emplacement de la plupart de ces paquetages. /usr -- hirarchie secondaire | +-X11R6 Sysme X Window, version 11 release 6 +-X386 Systme X Window, version 11 release 5 sur des plate-formes x86 +-bin La plupart des commandes utilisateurs +-games Binaires de jeux et d'apprentissage +-include Fichiers d'en-tes inclus par les programmes C +-lib Bibliothques +-local Hrarchie locale (vide aps l'installation principale) +-sbin Binaires systmes non essentiels +-share Dones inpendantes de l'architecture +-src Code source Les liens symboliques vers les rpertoires suivants peuvent tre prsents. Cette possibilit est base sur le besoin de prserver la compatibilit avec les vieux systmes jusqu' ce qu'on soit sr que toutes les implmentations utilisent la hirarchie /var. /usr/spool -> /var/spool /usr/tmp -> /var/tmp /usr/spool/locks -> /var/lock Une fois qu'un systme n'a plus besoin de l'un des liens symboliques ci- dessus, le lien peut tre enlev si dsir. - 21 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 4.1 /usr/X11R6 : Systme X Window, Version 11 Release 6 Cette hirarchie est rserve au systme X Window, version 11 release 6, et aux fichiers apparents. Pour simplifier les choses et rendre XFree86 plus compatible avec le systme X Window sur les autres systmes, les liens symboliques suivants devraient tre prsents : /usr/bin/X11 -> /usr/X11R6/bin /usr/lib/X11 -> /usr/X11R6/lib/X11 /usr/include/X11 -> /usr/X11R6/include/X11 En gnral, les logiciels ne devraient pas tre installs ou grs par l'intermdiaire de ces liens symboliques. Ils ne sont destins qu'_une utilisation par les utilisateurs. La difficult_est lie _la version de sortie du systme X Window -- dans les priodes de transition, il est impossible de savoir quelle version de X11 est en cours d'utilisation. Les donnes spcifiques _la machine dans /usr/X11R6/lib/X11 devraient tre prises comme des fichiers de dmonstration. Les applications ayant besoin d'informations sur la machine courante (grce des fichiers comme Xconfig, XF86Config ou system.twmrc) doivent se rfrer _un fichier de configuration dans /etc/X11, qui peut tre un lien vers un fichier de /usr/X11R6/lib. 4.2 /usr/X386 : systme X Window, Version 11 Release 5, sur les plate- formes x86 Cette hirarchie est en gnral identique /usr/X11R6 ; les liens symboliques de /usr pour X11 devraient pointer vers la version du systme X Window dsire. 4.3 /usr/bin : la plupart des commandes utilisateurs Voici le rpertoire principal des commandes excutables sur le systme. /usr/bin -- Binaires non ncessaires en mode utilisateur unique | +-mh Commandes pour le sysme de gestion de courrier MH +-X11 Lien symbolique vers /usr/X11R6/bin Les interpteurs de scripts shell (qu'on lance avec #! sur la premire ligne d'un script shell) ne pouvant pas compter sur un chemin, il est avantageux de normaliser leur emplacement. Les interprteurs du shell de Bourne et du shell C sont dj fixs dans /bin, mais on trouve souvent Perl, Python et Tcl dans maints endroits difrents. /usr/bin/perl, /usr/bin/python et /usr/bin/tcl devraient faire rfrence respectivement aux interprteurs de shell perl, python et tcl. Il peut y avoir des liens symboliques vers l'emplacement ritable des interpteurs shell. - 22 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 4.4 /usr/include : rpertoire pour les fichiers d'en-ttes standards. Voici l'endroit o tous les fichiers d'en-ttes usage gnral pour les langages de programmation C et C++ devraient tre placs. /usr/include -- fichiers d'en-ttes | +-X11 lien symbolique vers /usr/X11R6/include/X11 +-bsd fichiers d'en-tes de compatibilitBSD (si cessaire) +-g++ fichiers d'en-ttes pour le GNU C++ 4.5 /usr/lib : bibliothques pour la programmation et les paquetages /usr/lib contient des fichiers objets, des bibliothques et des binaires internes qui ne sont pas destins _tre excuts par les utilisateurs ou les scripts shell. Les applications peuvent utiliser un sous-rpertoire unique sous /usr/lib. Si une application utilise un sous-rpertoire, toutes les donnes dpendantes de l'architecture utilises exclusivement par cette application devraient tre places dans ce sous-rpertoire. Par exemple, le sous-rpertoire perl5 pour les modules et les bibliothques de Perl 5. Les fichiers et rpertoires divers, statiques, indpendants de l'architecure et spcifiques _une application devraient aller dans /usr/share. Certaines commandes excutables telles que makewhatis et sendmail ont aussi t places de manire traditionnelle dans /usr/lib. makewhatis est un binaire interne et devrait tre plac dans un rpertoire de binaires ; les utilisateurs accdent uniquement catman. Les nouveaux binaires sendmail sont maintenant placs par dfaut dans /usr/sbin ; un lien symbolique devrait rester de /usr/lib. En plus, les systmes qui utilisent Smail devraient placer Smail dans /usr/sbin/smail et /usr/sbin/sendmail devrait tre un lien symbolique vers celui-ci. Un lien symbolique /usr/lib/X11 pointant vers le rpertoire lib/X11 de la distribution X par dfaut est ncessaire si X est install. Note : aucune donne spcifique _la machine pour le systme X Window ne devrait tre stock_dans /usr/lib/X11. Les fichiers de configuration spcifiques la machine tels que Xconfig ou XF86Config devraient exister dans /etc/X11. Ceci devrait comprendre les donnes de configuration tels que system.twmrc mme si l'on n'en fait qu'un lien symbolique vers un fichier de configuration plus global (probablement dans /usr/X11R6/lib/X11). - 23 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 4.6 /usr/local : hirarchie locale La hirarchie /usr/local est destine _l'utilisation de l'administrateur systme quand il installe des logiciels en local. Il doit tre mis _l'abri de tout effacement lors de la mise _jour du logiciel systme. On peut l'utiliser pour des programmes et des donnes qu'on peut partager parmi un groupe de machines, mais qu'on ne trouve pas dans /usr. /usr/local -- Hirarchie locale | +-bin Binaires locaux +-games Binaires de jeux locaux +-include Fichiers d'en-tes C locaux +-lib Bibliothques locales +-sbin Binaires sysme locaux +-share Hirarchie indpendante de la machine locale +-src Code source local Ce pertoire devrait toujourstre vide aps la premre installation d'un sysme se conformant la FHS. Aucune exception cette gle ne devraittre faite part les morceaux de pertoires liss. Les logiciels instals localement devraienttre plas dans /usr/local plutt que dans /usr sauf si on l'installe pour remplacer ou mettre jour un logiciel de /usr. Notez que les logiciels placs dans / ou /usr peuvent tre crass par les mises jour systmes (bien que nous recommandons que les distributions n'crasent pas les donnes de /etc dans ces circonstances). Pour cette raison, les logiciels locaux ne devraient pas aller en dehors de /usr/local sans bonne raison. 4.7 /usr/sbin : binaires systmes normaux non essentiels Ce rpertoire contient tous les binaires non essentiels utiliss exclusivement par l'administrateur systme. Les programmes d'administration systme ncessaires la rparation du systme, sa remise en route, le montage de /usr ou d'autres fonctions essentielles devraient plutt tre placs dans /sbin. Typiquement, /usr/sbin contient les daemons rseau, tous les outils d'administration non essentiels et les binaires pour les programmes serveurs non critiques. Ces programmes serveurs sont utiliss _l'entre dans l'tat System V connu sous le nom de "run level 2" (tat multi-utilisateurs) et "run level 3" (tat en rseau) ou dans l'tat BSD connu sous le nom de "mode multi-utilisateurs". _ce point le systme met certains services _la disposition des utilisateurs (par exemple, les impressions) et d'autres machines (par exemple, les exports NFS). - 24 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Les programmes d'administration systme installs en local devraient tre placs dans /usr/local/sbin. 4.8 /usr/share : donnes indpendantes de l'architecture /usr/share -- Donnes indpendantes de l'architecture | +-dict Listes de mots +-doc Documentations diverses +-games Fichiers de dones statiques pour /usr/games +-info pertoire principal du sysme Info de GNU +-locale Informations pour Locale +-man Pages de manuel en ligne +-nls Support pour la langue natale +-misc Dones diverses inpendantes de la machine +-terminfo Rpertoires pour la base de donnes terminfo +-tmac Macros troff non distribes avec groff +-zoneinfo Information et configuration pour le fuseau horaire La hirarchie /usr/share contient tous les fichiers de dones inpendantes de l'architecture en lecture seule. La plupart de ces dones se trouvaient l'origine dans /usr (man, doc) ou /usr/lib (dict, terminfo, zoneinfo). Cette hirarchie est destine tre partage entre toutes les plate-formes et architectures pour un systme d'exploitation donn ; ainsi, par exemple, un site avec des plate-formes i386, Alpha et PPC peut maintenir un seul rpertoire /usr/share qui est montde manre centrale. Notez, cependant, que /usr/share n'est en gnral pas fait pour tre partag par des systmes d'exploitation diffrents ou par diffrentes versions du mme systme d'exploitation. Tout programme ou paquetage qui contient ou ncessite des donnes qui n'ont pas besoin d'tre modifies devrait stocker ces donnes dans /usr/share (ou /usr/local/share en cas d'installation locale). Il est recommand d'utiliser un sous-rpertoire de /usr/share cet effet. Notez que Linux utilise pour le moment des fichiers de bases de dones au format DBM. Bien que ceux-ci ne soient pas inpendants de l'architecture, ils sont autoris dans /usr/share en anticipation d'un passage au format DB 2.0 indpendant de l'architecture. Les donnes de jeux stockes dans /usr/share/games devraienttre des dones purement statiques. Tout fichier modifiable, comme les fichiers de scores, les enregistrements de parties et ainsi de suite, devraient tre plas dans /var/games. Il est recommand que les rpertoire spcifiques une application, indpendants de l'architecture soient placs ici. De tels rpertoires comprennent groff, perl, ghostscript, texmf et kbd (Linux) ou syscons (BSD). Ils peuvent, cependant, tre placs dans /usr/lib pour des raisons de compatibilitascendante, la disction du distributeur. De me, une hrarchie /usr/lib/games peut tre utilise en plus de la - 25 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 hirarchie /usr/share/games si le distributeur sire placer quelques dones de jeux cet endroit. 4.8.1 /usr/share/dict : listes de mots Fichiers recommands pour /usr/share/dict : { words } Traditionnellement, ce rpertoire ne contient que le fichier anglais words, utilis par look(1) et divers programmes de correction orthographique. words peut utiliser l'orthographe amricaine ou britannique. Les sites qui veulent les deux peuvent faire un lien words vers /usr/share/dict/american-english ou /usr/share/dict/british-english. On peut ajouter des listes de mots pour d'autres langues en utilisant le nom anglais de cette langue, par exemple /usr/share/dict/french, /usr/share/dict/danish, etc. Ils devraient, si possible, utiliser un jeu de caractres ISO 8859 appropri__la langue en question ; si possible en utilisant le jeu de caractres Latin1 (ISO 8859-1) -- ce n'est souvent pas possible. D'autres listes de mots, comme le "dictionnaire" web2 devraient y tre inclus, s'ils existent. Raison d'tre : La raison pour laquelle seules les listes de mots sont situes ici est que ce sont les seuls fichiers communs tous les correcteurs d'orthographe. 4.8.2 /usr/share/man : pages de manuel Cette section parcourt en dtails l'organisation des pages de manuel pour le systme entier, en incluant /usr/share/man. Reportez-vous aussi _la section sur /var/cache/man. Les pages de manuel sont stockes dans //man
/. , ,
et sont expliqus ci-dessous. - 26 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 / -- Hirarchie de pages de manuel | +-man1 Programmes utilisateurs +-man2 Appels systme +-man3 Appels de bibliotque +-man4 Fichiers spciaux +-man5 Formats de fichiers +-man6 Jeux +-man7 Divers +-man8 Administration systme Le principal du sysme est /usr/share/man. /usr/share/man contient des informations du manuel pour les commandes et les dones des sysmes de fichiers / et /usr.videmment, il n'y a pas de pages de manuel dans / parce qu'elles ne sont pas utiles au dmarrage ni dans les situations d'urgence. La
crit la section du manuel. Il faut s'assurer de faire de la place dans la structure de /usr/share/man pour supporter les pages de manuel crites en des langues diffrentes (ou multiples). Cette place doit prendre en compte le stockage et la rfrence ces pages de manuel. Les facteurs pertinents comprennent la langue (avec les diffrences gographiques), et le codage des caractres. Le nommage des sous-rpertoires spcifiques la langue dans /usr/share/man est bassur l'annexe E de la norme POSIX 1003.1 qui crit la chne d'identification locale -- la thode la mieux accepe pour crire un environnement culturel. La chne est : [_][.][,] Le champ sera tir d'ISO 639 (un code de reprsentation des noms de langues). Il sera constitu de deux caractres et spcifi en lettres minuscules uniquement. Le champ sera le code deux lettres d'ISO 3166 (scification des repsentations de pays) si possible. (La plupart des personnes sont familres avec les codes deux lettres utilies pour les codes de pays des adresseslectroniques.1) Il sera constitude deux caracres scifs en lettres majuscules uniquement. Le champ devrait reprsenter la norme dcrivant le code de caractres. Si le champ est une simple indication nurique, le nombre repsente le nuro de la norme internationale crivant le code de caracres. Il est recommandque ce soit une repsentation nurique si possible (surtout pour les normes ISO), qu'il n'inclue pas de symboles de ponctuation suppmentaires et que ____________________ 1. Une exception majeure cette rgle est le Royaume Uni, qui est `GB' dans ISO 3166, mais `UK' pour la plupart des adresses lectroniques. - 27 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 toute lettre soit en minuscule. Un paratre scifiant la du profil peut tre plac aprs le champ , parpar une virgule. Ceci peut servir difrencier plusieurs besoins culturels ; par exemple, l'ordre du dictionnaire comparun ordre d'assemblage plus orientsysmes. Cette norme recommande de ne pas utiliser le champ , sauf si c'est ncessaire. Les systmes utilisant une langue et un code de caractres uniques pour toutes les pages de manuel peuvent omettre la sous-chane et stocker toutes les pages de manuel dans . Par exemple, les systmes qui n'ont que les pages de manuel en anglais codes en ASCII peuvent stocker ces pages (les rpertoires man
) directement dans /usr/share/man. (Ce qui reprsente, en fait, la disposition et les circonstances habituelles.) Les pays pour lesquels un ensemble de codes de caractres standard bien accept existe peuvent omettre le champ , mais il est fortement recommandde l'inclure, surtout pour les pays ayant plusieurs normes en comtition. Quelques exemples : Langue Territoire Code de caracre pertoire ------------------------------------------------------------------------ Anglais -- ASCII /usr/share/man/en Anglais Royaume Uni ASCII /usr/share/man/en_GB Anglais tats-Unis ASCII /usr/share/man/en_US Fraais Canada ISO 8859-1 /usr/share/man/fr_CA Fraais France ISO 8859-1 /usr/share/man/fr_FR Allemand Allemagne ISO 646 /usr/share/man/de_DE.646 Allemand Allemagne ISO 6937 /usr/share/man/de_DE.6937 Allemand Allemagne ISO 8859-1 /usr/share/man/de_DE.88591 Allemand Suisse ISO 646 /usr/share/man/de_CH.646 Japonais Japon JIS /usr/share/man/ja_JP.jis Japonais Japon SJIS /usr/share/man/ja_JP.sjis Japonais Japon UJIS (ou EUC-J) /usr/share/man/ja_JP.ujis De me, il faut faire de la place pour les pages de manuel pendant de l'architecture, comme la documentation sur les pilotes de ripriques ou les commandes d'administration sysme de bas niveau. Elles devraient tre plaes dans un pertoire dans le pertoire man
appropri; par exemple, une page de manuel pour la commande i386 ctrlaltdel(8) peuttre plae dans /usr/share/man//man8/i386/ctrlaltdel.8. Les pages de manuel pour les commandes et les dones de /usr/local sont stoces dans /usr/local/man. Les pages de manuel pour X11R6 sont stoces dans /usr/X11R6/man. Il s'ensuit que toutes les hrarchies de pages de manuel du sysme devraient avoir la me structure que /usr/share/man. Les pertoires vides peuventtre oubls d'une hrarchie de pages de manuel. Par exemple, si /usr/local/man n'a pas de - 28 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 pages de manuel pour la section 4 (ripriques), alors /usr/local/man/man4 peuttre omis. Les sections de pages cat (cat
) contenant des entes de pages de manuel formaes se trouvent aussi dans les sous-pertoires de /, mais ne sont pas obligatoires ni ne devraienttre distribes la place des pages de manuel en source nroff. Les sections nuroes "1" "8" sont finies de manre traditionnelle. En ral, le nom de fichier des pages de manuel sites dans une section particulre se termine par .
. De plus, certains grands ensembles de pages de manuel scifiques une application posdent un suffixe suppmentaire accolau nom de fichier de la page de manuel. Par exemple, les pages de manuel du sysme de gestion de courrier MH devraient avoir mh accoltoutes les pages de manuel de MH. Toutes les pages de manuel du sysme X Window devraient avoir un x accolau nom de fichier. La pratique de placer les pages de manuel de diverses langues dans les sous-pertoires approprs de /usr/share/man s'applique aussi aux autres hrarchies de pages de manuel, comme /usr/local/man et /usr/X11R6/man. (Cette partie de la norme s'appliquera aussi plus loin dans la section sur la structure optionnelle /var/cache/man.) Voici une description de chaque section : man1 : programmes utilisateurs Les pages de manuel crivant les commandes accessibles tous se trouvent dans ce chapitre. La majeure partie de la documentation sur les programmes dont aura jamais besoin un utilisateur se trouve ici. man2 : appels sysme Cette section crit tous les appels sysmes (reqtes au noyau pour effectuer des orations). man3 : fonctions et routines de la bibliotque La section 3 crit les routines du programme de la bibliotque qui ne sont pas des appels directs aux services du noyau. Ceci ainsi que le chapitre 2 ne sont vraiment inressants que pour les programmeurs. man4 : fichiers sciaux La section 4 crit les fichiers sciaux, les fonctions scifiques aux pilotes et le support seau disponible sur le sysme. On y trouve typiquement les fichiers de ripriques de /dev et l'interface noyau pour le support des protocoles seau. man5 : formats de fichiers Le format de nombreux fichiers de dones non intuitifs est documentdans la section 5. Ceci comprend divers fichiers d'en- - 29 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 tes, les fichiers de sultats de programmes et les fichiers sysmes. man6 : jeux Ce chapitre documente les jeux, les monstrations et des programmes en ral triviaux. Des personnes difrentes ont des notions vares sur l'opportunitde cette partie. man7 : divers Les pages de manuel difficiles classer sont plaes dans la section 7. Les paquetages de macros pour troff et autres processeurs de texte se trouvent ici. man8 : administration sysme La documentation pour les programmes utilis par les administrateurs sysme pour la bonne marche du sysme et sa maintenance se trouve ici. Certains de ces programmes sont aussi utiles de temps autre pour les utilisateurs normaux. 4.8.3 /usr/share/misc : diverses donnes indpendantes de l'architecture Ce rpertoire contient divers fichiers indpendants de l'architecture qui ne ncessitent pas un sous-rpertoire spar dans /usr/share. C'est un rpertoire obligatoire de /usr/share. Les fichiers suivants, s'ils sont prsents, devraient se trouver dans /usr/share/misc : { ascii, magic, termcap, termcap.db } D'autres fichiers (spcifiques une application) peuvent apparatre ici, mais un intgrateur peut les placer dans /usr/lib _sa discrtion. De tels fichiers comprennent : { airport, birthtoken, eqnchar, getopt, gprof.callg, gprof.flat, inter.phone, ipfw.samp.filters, ipfw.samp.scripts, keycap.pcvt, mail.help, mail.tildehelp, man.template, map3270, mdoc.template, more.help, na.phone, nslookup.help, operator, scsi_modes, sendmail.hf, style, units.lib, vgrindefs, vgrindefs.db, zipcodes } 4.9 /usr/src : code source Tout code source non local devrait tre plac dans ce sous-rpertoire. - 30 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 5. La hirarchie /var /var -- Donnes variables | +-account Historique de la comptabilitdes processus (si suppor) +-cache Donnes de cache des applications +-crash Dones brutes des plantages sysme (si suppor) +-games Donnes variables des jeux +-lock Fichiers de verrous +-log Fichiers et rpertoires d'historique +-mail Fichiers de btes aux lettres utilisateurs +-opt Donnes variables de /opt +-run Fichiers relatifs aux processus en cours +-spool Donnes en attente pour les applications +-state Informations variables dtat +-tmp Fichiers temporaires prservs entre les redmarrages du systme +-yp fichiers de base de dones de NIS (Network Information Service) /var contient des fichiers de donnes variables. Ceci inclut les rpertoires et fichiers en attente (spool), les donnes administratives et d'historique, et les fichiers transitoires et temporaires. Certaines parties de /var ne sont pas partageables entre des sysmes difrents. Par exemple, /var/log, /var/lock et /var/run. D'autres parties peuvent tre partages, comme notamment /var/mail, /var/cache/man, /var/cache/fonts et /var/spool/news. /var est ici scifiafin de rendre possible le montage de /usr en lecture seule. Tout ce qui allait auparavant dans /usr sur lequel on crivait pendant la marche du sysme (au contraire de l'installation et de la maintenance logicielle) doit aller dans /var. Si on ne peut pas faire de /var une partition pae, il est souvent prable de placer /var hors de la partition racine l'intrieur de la partition /usr. (Ceci est parfois effectupour duire la taille de la partition racine ou quand l'espace se duit dans la partition racine.) Cependant, /var ne devrait pas tre un lien vers /usr parce que cela rend la paration de /usr et /var plus difficile et rend plus probable la cation d'un conflit de noms. la place, faites un lien de /var vers /usr/var. Les applications ne devraient en ral pas ajouter de pertoire au niveau surieur de /var. De tels rpertoires ne devraient tre ajouts que s'ils concernent le systme en entier, et en consultant la liste de distribution FHS. Les rpertoires cache, lock, log, run, spool, state et tmp doiventtre inclus et utilis dans toutes les distributions ; les pertoires account, crash, games, mail et yp doivent tre inclus et utiliss si les applications ou possibilits correspondantes sont fournies dans la distribution. Les versions prcdentes de la FSSTND incluaient une hirarchie /var/lib. Pour plus d'informations, voir la section sur /var/state. - 31 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Plusieurs rpertoires sont `rservs' dans le sens o ils ne devraient pas tre utiliss de faon arbitraire par une application nouvelle, puisqu'ils entreraient en conflit avec une pratique historique et/ou locale. Ce sont : /var/backups /var/cron /var/lib /var/local /var/msgs /var/preserve 5.1 /var/account : historique de la comptabilit_des processus (si support) Ce rpertoire contient l'historique en cours de la comptabilit des processus et les donnes composes d'utilisation des processus (utiliss dans certains systme UNIX par lastcomm et sa). 5.2 /var/cache : donnes de cache des applications /var/cache -- rpertoires de cache | +-fonts fontes es en local +-man pages de manuel formates en local +-www dones de cache ou de proxy WWW +-/ (par exemple, fonts/pk/CanonCX/cmr10.300pk). Les fichiers .pk peuvent tre priodiquement purgs de l'arborescence /var/cache/fonts ou peuvent tre dplacs dans l'arborescence /usr/lib/texmf. Si des gnrateurs automatiques de .mf ou .tfm sont utiliss, ils devraient placer leurs donnes dans les sous-rpertoires mf ou tfm de /var/cache/fonts. D'autres fontes cres dynamiquement peuvent aussi tre places dans cette arborescence, dans des sous-rpertoires de /var/cache/fonts nomms de manire adquate. 5.2.2 /var/cache/man : pages de manuel formates en local (optionnel) Ce rpertoire fournit un emplacement standard pour les sites qui fournissent une partition /usr en lecture seule, mais qui veulent permettre le cache des pages de manuel formates en local. Les sites qui montent /usr en criture (par exemple, les installations en utilisateur unique) peuvent choisir de ne pas utiliser /var/cache/man et peuvent crire les pages de manuel formates dans les rpertoires cat
directement dans /usr/share/man. Nous recommandons que la plupart des sites utilisent plutt l'une des options suivantes : _Prformater toutes les pages de manuel _ct_des versions non formates. _Ne permettre aucun cache des pages de manuel formates et obliger _ refaire le formatage _chaque utilisation d'une page de manuel. _Permettre le cache local des pages de manuel formates dans /var/cache/man. ____________________ 2. La raison pour laquelle les outils de Karl Berry sont mentionns est qu'ils sont le standard de-facto pour les installations UNIX de TeX. Ces outils sont largement utiliss dans la communaut UNIX libre. - 33 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 La structure de /var/cache/man ncessite de reflter _la fois les hirarchies multiples de pages de manuel et la possibilit_d'un support multilingue. tant donne une page de manuel non formate qui apparat normalement dans /man//man
, le rpertoire pour placer les pages de manuel formates s'appelle /var/cache/man///cat
, o_ s'inspire de en enlevant toute composante de nom de chemin usr au dbut et/ou share _la fin. (Notez que la composante peut ne pas tre prsente.) Par exemple, /usr/share/man/man1/ls.1 sera formate en /var/cache/man/cat1/ls.1 et /usr/X11R6/man//man3/XtClass.3x en /var/cache/man/X11R6//cat3/XtClass.3x. Les pages de manuel crites dans /var/cache/man peuvent _la fin tre transfres vers les rpertoires prformats appropris dans la hirarchie source man ou bien expires ; De mme, les pages de manuel formates dans la hirarchie source man peuvent tre expires si personne n'y a accd_pendant une certaine priode de temps. Si les pages de manuel prformates sont distribues avec un systme sur des supports en lecture seule (un CD-ROM, par exemple), elles seront installes dans la hirarchie source man (par exemple /usr/share/man/cat
). /var/cache/man est rserv comme cache dans lequel on peut crire les pages de manuel formates. Raison d'tre : La version 1.2 de la norme spcifiait /var/catman pour cette hirarchie. Le chemin a t_chang_en /var/cache pour mieux reflter la nature dynamique des pages de manuel formates. Le nom du rpertoire a t chang en man pour permettre l'agrandissement de la hirarchie et inclure des formats traits autres que "cat", comme PostScript, HTML ou DVI. 5.3 /var/crash : donnes brutes des plantages systme (si support) Ce rpertoire contient des donnes brutes (dump) des plantages systme. la date de la sortie de cette norme, les donnes brutes de plantage systme n'taient pas supports par Linux. 5.4 /var/games : donnes variables des jeux Toute donne variable concernant les jeux de /usr devrait tre place ici. /var/games devrait contenir les donnes variables qu'on trouvait auparavant dans /usr ; Les donnes statiques telles que les textes d'aide, les descriptions de niveaux et ainsi de suite devraient rester autre part, comme dans /usr/share/games. - 34 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Comme pour /var/state, les donnes variables des jeux peuvent tre places dans /var/lib en tant que mesure de transition obsolte. Cependant, cette permission sera leve dans une version future de la norme. Raison d'tre : On a donn une hirarchie /var/games _part entire, plutt que de le laisser mlang_avec l'ancien /var/lib comme dans la version 1.2. La sparation permet un contrle local des stratgies de sauvegarde, permissions et utilisation des disques, ainsi que de permettre un partage inter-machines et de rduire l'encombrement de /var/state. De plus, /var/games est le chemin utilis traditionnellement par BSD. 5.5 /var/lock : fichiers de verrous Les fichiers de verrous devraient tre stocks dans la structure de rpertoires /var/lock. Les fichiers de verrous de priphriques, tels les fichiers de verrous du priphrique srie qu'on trouvait d'habitude soit dans /usr/spool/locks soit dans /usr/spool/uucp doivent maintenant tre stocks dans /var/lock. La convention de nommage utiliser est "LCK.." suivi du nom de base du priphrique. Par exemple, pour verrouiller /dev/cua0 le fichier "LCK..cua0" serait cr. Le format utilis pour les fichiers de verrous de priphrique doit tre le format de fichier de verrou HDB UUCP. Le format HDB permet de stocker l'identificateur du processus (PID) comme un nombre dcimal ASCII sur dix octets, avec un signe nouvelle ligne la fin. Par exemple, si le processus 1230 tenait un fichier de verrou, il contiendrait les onze caractres : espace, espace, espace, espace, espace, espace, un, deux, trois, zro et nouvelle ligne. programme a cr le verrou (uucp, cu ou getty). Alors, tout ce qui voudrait utiliser /dev/cua0 peut lire le fichier de verrou et agir en consquence (tous les verrous de /var/lock devraient tre lisibles par tout le monde). 5.6 /var/log : fichiers et rpertoires d'historique Le rpertoire contient divers fichiers d'historique (log). La plupart des historiques devraient tre crits dans ce rpertoire ou dans un sous-rpertoire appropri. lastlog enregistrement du dernier login de chaque utilisateur messages messages systme de syslogd wtmp enregistrement de chaque login et logout - 35 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 5.7 /var/mail : fichiers de botes aux lettres utilisateurs Ce rpertoire contient les fichiers de botes aux lettres utilisateurs stocks dans le format de botes aux lettres UNIX standard. Raison d'tre : Ce rpertoire a t relog de /var/spool/mail pour amener FHS en accord avec la plupart des implmentations UNIX. Ce changement est important pour l'interoprabilit_puisqu'un /var/mail unique est souvent partag entre plusieurs machines et plusieurs implmentations d'UNIX (malgr les problmes de verrouillage NFS). 5.8 /var/opt : donnes variables de /opt Les donnes variables devraient tre installes dans /var/opt/, o_ est le nom de la sous-arborescence de /opt o_les donnes statiques de tout paquetage logiciel supplmentaire sont stockes, sauf quand elles sont supplantes par un autre fichier dans /etc. Aucune structure n'est impose sur la disposition interne de /var/opt/. Raison d'tre : Voir la raison d'tre pour /opt. 5.9 /var/run : fichiers variables d'excution Ce rpertoire contient des fichiers d'information systme dcrivant le systme depuis qu'il a dmarr. Les fichiers de ce rpertoire devraient tre nettoys (enlevs ou tronqus selon le cas) au dbut du processus de dmarrage. Les fichiers d'identification de processus (PID), qui taient placs l'origine dans /etc, devraient tre placs dans /var/run. La convention de nommage des fichiers PID est .pid. Par exemple, le fichier PID de crond est nomm /var/run/crond.pid. Le format interne des fichiers PID reste inchang. Le fichier consiste en un identificateur de processus en dcimal cod_ASCII, suivi d'un caractre nouvelle ligne. Par exemple, si crond tait le processus numro 25, /var/run/crond.pid contiendrait trois caractres : deux, cinq et nouvelle ligne. Les programmes qui lisent les fichiers PID devraient tre assez souples dans ce qu'ils acceptent ; par exemple, ils devraient ignorer les espaces blancs supplmentaires, les zros au dbut, l'absence d'une nouvelle ligne _la fin ou les lignes supplmentaires dans le fichier PID. Les programmes qui crent des fichiers PID devraient utiliser la spcification simple situe dans le paragraphe ci-dessus. - 36 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 Le fichier utmp, qui stocke les informations sur qui est en train d'utiliser le systme, est plac dans ce rpertoire. Les programmes qui gardent des sockets du domaine UNIX temporaires devraient les placer dans ce rpertoire. 5.10 /var/spool : donnes en attente pour les applications /var/spool -- Rpertoires d'attente | +-lpd pertoire d'attente de l'imprimante +-mqueue File d'attente du courrier l'expdition +-news pertoire d'attente des news +-rwho Fichiers rwhod +-smail pertoire d'attente pour smail +-uucp Rpertoire d'attente pour UUCP /var/spool contient des dones en attente d'un traitement ulrieur. Les dones de /var/spool reprsentent un travail faire dans le futur (par un programme, un utilisateur ou un administrateur) ; les donnes sont souvent effaces aprs avoir t traites. Les fichiers de verrou UUCP doivent tre placs dans /var/lock. Voir la section ci-dessus propos de /var/lock. 5.10.1 /var/spool/lpd : file d'impression du daemon de l'imprimante ligne /var/spool/lpd -- Rpertoire d'attente de l'imprimante | +- Fichiers de sauvegarde ettat dditeurs +-misc Diverses donnes d'tat +-xdm Dones variables du gestionnaire d'affichage X xdm +- Fichiers d'aide au paquetage +- est l'endroit utiliser pour tout le support de paquetage de la distribution. Des distributions difrentes peuvent videmment utiliser des noms difrents. Les versions pdentes de cette norme utilisaient le nom /var/lib pour cette hirarchie. /var/lib est obsote, mais peuttre utilisen paralle avec la hrarchie obligatoire /var/state, comme mesure transitoire pour les donnes spcifiques aux applications. Notez cependant que cette permission sera retire dans une version future de la norme. Par contre, vous pouvez faire un lien symbolique de /var/lib vers /var/state. Raison d'tre : /usr/lib est de plus en plus utilis_uniquement pour les fichiers objets ou leurs archives ; ceci est vrai pour les variantes BSD UNIX actuelles ainsi que les paquetages GNU actuels. Dans le mme ordre d'ides, le nom /var/lib semblait inappropri. BSD utilise le nom /var/db pour un rpertoire similaire. Ce nom semblait - 38 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 trop restrictif, puisqu'il impliquait une structure de rpertoires faite tout d'abord pour les fichiers de base de donnes (.db). 5.11.1 /var/state/ : fichiers de sauvegarde et tat d'un diteur Ces rpertoires contiennent des fichiers sauvegards par toute fin inattendue d'un diteur (par exemple elvis, jove, nvi). D'autres diteurs peuvent ne pas demander de rpertoire pour les fichiers de sauvegarde de plantage, mais peuvent ncessiter un endroit bien dfini pour stocker d'autres informations pendant que l'diteur fonctionne. Ces informations devraient tre stockes dans un sous- rpertoire de /var/state (par exemple, GNU Emacs placerait ses fichiers de verrou dans /var/state/emacs/lock). Des diteurs futurs pourront avoir besoin d'informations d'tat supplmentaires au-del des fichiers de sauvegarde de plantage et des fichiers de verrou -- ces informations devraient aussi tre places dans /var/state/. Raison d'tre : Les versions prcdentes de Linux, ainsi que tous les distributeurs du commerce, utilisaient /var/preserve pour vi et ses clones. Cependant, chaque diteur utilise son propre format pour ces fichiers de sauvegarde de plantage, c'est pourquoi un rpertoire spar_est ncessaire _chaque diteur. Les fichiers de verrous spcifiques _chaque diteur sont en gnral assez diffrents des fichiers de verrous de priphrique ou de ressources stocks dans /var/lock et de ce fait sont stocks dans /var/state. 5.11.2 /var/state/misc : diverses donnes variables Ce rpertoire contient des donnes variables qui ne sont pas places dans un sous-rpertoire de /var/state. Il serait judicieux d'utiliser dans la mesure du possible des noms uniques dans ce rpertoire pour viter les conflits de noms. Notez que cette hirarchie devrait contenir les fichiers de /var/db des versions actuelles de BSD. Celles-ci comprennent locate.database et mountdtab, et la (les) base(s) de donnes des symboles du noyau. 5.12 /var/tmp : fichiers temporaires prservs entre les redmarrages du systme Le rpertoire /var/tmp est mis _la disposition des programmes qui ont besoin de fichiers ou de rpertoires temporaires prservs entre les - 39 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 redmarrages du systme. Par consquent, les donnes stockes dans /var/tmp restent plus longtemps que les donnes de /tmp. Les fichiers et rpertoires situs dans /var/tmp ne doivent pas tre effaces quand le systme dmarre. Bien que les donnes stockes dans /var/tmp soient typiquement effaces d'une manire spcifique au site, il est recommand_que l'effacement se fasse dans un intervalle plus long que pour /tmp. 5.13 /var/yp : fichiers de base de donnes NIS (Network Information Service) Les donnes variables du Service d'Information Rseau (NIS ou Network Information Service), qu'on appelait auparavant Pages Jaunes Sun (YP ou Sun Yellow Pages), seront places dans ce rpertoire. Raison d'tre : /var/yp est le rpertoire normal des donnes NIS (YP) et est utilis_ presque exclusivement dans la documentation et les systmes NIS. Il ne faut pas confondre NIS et Sun NIS+, qui utilise un rpertoire diffrent, /var/nis. - 40 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 6. Annexe spcifique aux systmes d'exploitation Cette section contient des obligations et recommandations supplmentaires qui ne s'appliquent qu' un systme d'exploitation spcifique. Les principes de cette section ne devraient jamais entrer en conflit avec la norme de base. 6.1 Linux Voici l'annexe pour le systme d'exploitation Linux. 6.1.1 / : rpertoire racine Sur les systmes Linux, si le noyau est situ dans /, nous recommandons d'utiliser les noms vmlinux ou vmlinuz, qui sont utiliss dans les paquetages rcents de sources du noyau Linux. 6.1.2 /dev : fichiers de priphriques et fichiers spciaux Tous les fichiers de priphriques et fichiers spciaux de /dev devraient se conformer au document Linux Allocated Devices (priphriques allous dans Linux), que l'on trouve dans les sources du noyau Linux. Il est maintenu par H. Peter Anvin . Les liens symboliques de /dev ne devraient pas tre distribus avec des systmes Linux sauf s'ils sont fournis dans le document Linux Allocated Devices. Raison d'tre : L'obligation de ne pas faire de liens symboliques au hasard est donne parce que la configuration locale diffre souvent de celle de la machine de dveloppement du distributeur. De plus, si un script d'installation de distribution configure les liens symboliques au moment de l'installation, ces liens symboliques ne seront souvent pas mis jour si des changements locaux ont lieu sur le matriel. Utiliss de manire responsable un niveau local, cependant, on peut les utiliser bon escient. 6.1.3 /proc : systme de fichiers virtuel d'information sur le noyau et les processus Le systme de fichiers proc devient la mthode standard de-facto sur Linux pour manipuler les processus et les informations du systme, plutt que par /dev/kmem et autres mthodes similaires. Nous encourageons fortement ce principe pour le stockage et l'obtention d'informations sur un processus ainsi que d'autres informations sur le noyau et la mmoire. - 41 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 6.1.4 /sbin : binaires systmes essentiels Les systmes Linux placent ces fichiers supplmentaires dans /sbin. _Commandes du systme de fichiers tendu deuxime version (ext2 -- optionnel) : { badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs } Installateur de carte du chargeur de dmarrage : { lilo } Fichiers optionnels de /sbin : Binaires statiques : { ldconfig, sln, ssync } Les binaires statiques ln (sln) et sync (ssync) sont utiles quand quelque chose va mal. L'utilisation principale de sln (pour rparer les liens symboliques incorrects dans /lib aprs une mise _jour mal faite) n'est plus d'une importance cruciale maintenant que le programme ldconfig (situ gnralement dans /usr/sbin) existe et peut agir comme guide dans certaines situations d'urgence. Notez qu'ils ne doivent pas forcment tre des versions lies en statique des commandes normales ln et sync, mais elle peuvent l'tre. Le binaire ldconfig est optionnel dans /sbin puisqu'un site peut choisir de lancer ldconfig au dmarrage plutt qu' la mise jour des bibliothques partages. (Il n'est pas clair qu'il soit avantageux de lancer ldconfig _chaque dmarrage.) Mme ainsi, certaines personnes aiment avoir ldconfig porte de clavier pour les situations suivantes (toutes trop frquentes) : (1) Je viens d'enlever /lib/. (2) Je ne peux pas trouver le nom de la bibliothque parce que ls est li en dynamique, j'utilise un shell qui n'a pas ls intgr_et je ne sais pas utiliser "echo *" la place. (3) J'ai un sln en statique, mais je ne sais pas comment appeler le lien. _Divers : { ctrlaltdel, kbdrate } Pour pallier au fait que certains claviers sont livrs avec une frquence de rptition si grande qu'ils en sont inutilisables, - 42 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 kbdrate peut tre install_dans /sbin sur certains systmes. Puisque l'action par dfaut dans le noyau pour la combinaison de touches Ctrl-Alt-Del est un redmarrage brutal instantan, il est recommandable de dsactiver ce comportement avant de monter le systme de fichiers racine en mode lecture/criture. Certaines versions d'init sont capables de dsactiver Ctrl-Alt-Del, mais d'autres ncessitent le programme ctrlaltdel qui peut tre install dans /sbin sur ces systmes. 6.1.5 /usr/include : fichiers d'en-tte inclus par les programmes C Les liens symboliques suivants sont ncessaires si un compilateur C ou C++ est install. /usr/include/asm -> /usr/src/linux/include/asm- /usr/include/linux -> /usr/src/linux/include/linux 6.1.6 /usr/src : code source Le seul code source qui doit tre plac dans un endroit spcifique est le code source du noyau Linux. Il est situ dans /usr/src/linux. Si un compilateur C ou C++ est install, mais que le code source complet du noyau Linux n'est pas install, les fichiers d'en-tte du code source du noyau devront tre situs dans ces rpertoires : /usr/src/linux/include/asm- /usr/src/linux/include/linux est le nom de l'architecture du systme. Note : /usr/src/linux peut tre un lien symbolique vers l'arborescence relle du code source du noyau. Raison d'tre : Il est important que les fichiers d'en-ttes du noyau soient situs dans /usr/src/linux et non dans /usr/include pour qu'il n'y ait pas de problemes quand les administrateurs systme mettent jour la version du noyau pour la premire fois. 6.1.7 /var/spool/cron : travaux cron et at Ce rpertoire contient les donnes variables pour les programmes cron et at. - 43 - Norme de hirarchie du systme de fichiers 1er fvrier 1998 La liste de distribution FHS La liste de distribution FHS est situe . Pour vous abonner la liste envoyez un courrier avec dans le corps du message "ADD fhs-discuss". Merci _Network Operations _l'universit_de Californie _San Diego qui nous a autoriss _utiliser leur super serveur de listes de distribution. Comme il est indiqu_dans l'introduction, veuillez ne pas envoyer de courrier _la liste de distribution sans d'abord contacter l'diteur de la FHS ou un contributeur list. Remerciements Les dveloppeurs de la FHS souhaitent remercier les dveloppeurs, administrateurs systme et utilisateurs dont l'avis a t essentiel cette norme. Nous souhaitons remercier chacun des contributeurs qui ont aid crire, compiler et composer cette norme. Le groupe FHS souhaite aussi remercier les dveloppeurs Linux qui ont support la FSSTND, prdcesseur de cette norme. S'ils n'avaient pas dmontr le bnfice apport par la FSSTND, la FHS n'aurait jamais pu voluer. Contributeurs Brandon S. Allbery Keith Bostic Drew Eckhardt Rik Faith Stephen Harris Ian Jackson John A. Martin Ian McCloghrie Chris Metcalf Ian Murdock David C. Niemi Daniel Quinlan Eric S. Raymond Mike Sangrey David H. Silber Theodore Ts'o Stephen Tweedie Fred N. van Kempen Traducteurs : La traduction franaise a t ralise par Olivier Tharan, . Tous les commentaires sont accepts. - 44 - CONTENTS 1. Introduction ...................................................... 1 1.1 tat de la norme ............................................. 1 1.2 Organisation de la norme ..................................... 1 1.3 Conventions .................................................. 1 1.4 Historique de la FHS ......................................... 3 1.5 tendue ...................................................... 3 1.6 Suggestions gnrales ........................................ 4 1.7 Audience vise ............................................... 4 1.8 Conformit avec ce document .................................. 5 2. Le systme de fichiers ............................................ 7 3. Le rpertoire racine ............................................. 10 3.1 /bin : binaires de commandes utilisateurs essentielles (pour tous les utilisateurs) ...................................... 11 3.2 /boot : fichiers statiques du chargeur de dmarrage ......... 13 3.3 /dev : fichiers de priphriques ............................ 13 3.4 /etc : configuration systme spcifique la machine ........ 14 3.5 /home : rpertoires personnels des utilisateurs (optionnel) . 15 3.6 /lib : bibliothques partages importantes et modules du noyau ....................................................... 16 3.7 /mnt : point de montage pour les systmes de fichiers monts temporairement .............................................. 16 3.8 /opt : paquetages de logiciels d'applications supplmentaires ............................................. 17 3.9 /root : rpertoire personnel pour l'utilisateur root (optionnel) ................................................. 18 3.10 /sbin : binaires systmes (qui se trouvaient autrefois dans /etc) ....................................................... 18 3.11 /tmp : fichiers temporaires ................................. 19 4. La hirarchie /usr ............................................... 21 4.1 /usr/X11R6 : Systme X Window, Version 11 Release 6 ......... 22 4.2 /usr/X386 : systme X Window, Version 11 Release 5, sur les plate-formes x86 ............................................ 22 4.3 /usr/bin : la plupart des commandes utilisateurs ............ 22 4.4 /usr/include : rpertoire pour les fichiers d'en-ttes standards. .................................................. 23 4.5 /usr/lib : bibliothques pour la programmation et les paquetages .................................................. 23 4.6 /usr/local : hirarchie locale .............................. 24 4.7 /usr/sbin : binaires systmes normaux non essentiels ........ 24 4.8 /usr/share : donnes indpendantes de l'architecture ........ 25 4.9 /usr/src : code source ...................................... 30 5. La hirarchie /var ............................................... 31 5.1 /var/account : historique de la comptabilit des processus (si support) ............................................... 32 5.2 /var/cache : donnes de cache des applications .............. 32 5.3 i /var/crash : donnes brutes des plantages systme (si support) ................................................... 34 5.4 /var/games : donnes variables des jeux ..................... 34 5.5 /var/lock : fichiers de verrous ............................. 35 5.6 /var/log : fichiers et rpertoires d'historique ............. 35 5.7 /var/mail : fichiers de botes aux lettres utilisateurs ..... 36 5.8 /var/opt : donnes variables de /opt ........................ 36 5.9 /var/run : fichiers variables d'excution ................... 36 5.10 /var/spool : donnes en attente pour les applications ....... 37 5.11 /var/state : informations variables d'tat .................. 38 5.12 /var/tmp : fichiers temporaires prservs entre les redmarrages du systme ..................................... 39 5.13 /var/yp : fichiers de base de donnes NIS (Network Information Service) ........................................ 40 6. Annexe spcifique aux systmes d'exploitation .................... 41 6.1 Linux ....................................................... 41 ii