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 :
* Pour démarrer un système, il doit y avoir suffisamment pour monter /usr et d'autres parties non-essentielles du système de fichiers. Ceci comprend les utilitaires, la configuration, les informations du chargeur de démarrage, et d'autres données de démarrage essentielles.
* Pour permettre le rétablissement et/ou la réparation d'un système, les utilitaires nécessaires au mainteneur expérimenté pour diagnostiquer et reconstruire un système endommagé doivent être présents sur le système de fichiers root.
* Pour reconstituer un système, les utilitaires nécessaires à la reconstitution à partir des sauvegardes système (sur disque, bande, etc.) doivent être présents sur le système de fichiers root.
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 :
* Il est souvent monté à partir d'un moyen de stockage très petit. Par exemple, beaucoup d'utilisateurs Linux installent et rétablissent les systèmes en montant root à partir d'un disque virtuel en RAM, qui est copié d'une simple disquette 1.44M ou 1.2M.
* Le système de fichiers root contient beaucoup de fichiers de configuration spécifiques au système. Les exemples possibles comprennent un noyau spécifique au système, un nom d'hôte différent, etc. Ceci veut dire que le système de fichiers root n'est pas toujours partageable entre des systèmes en réseau. Le garder petit sur des systèmes en réseau minimise l'espace perdu en fichiers non-partageables sur les serveurs. Cela permet aussi d'avoir des stations de travail avec des disques durs locaux plus petits.
* Alors que vous pouvez avoir le système de fichiers root sur une grande partition, et pouvez le remplir à votre aise, il y aura des gens avec des partition plus petites. Si vous avez plus de fichiers installés, vous pourrez trouver des incompatibilités avec d'autres systèmes qui utilisent des systèmes de fichiers root sur des partitions plus petites. Si vous êtes développeur vous pouvez changer votre hypothèse en un problème pour un grand nombre d'utilisateurs.
* Les erreurs de disque qui corrompent les données sur le système de fichiers root sont un problème plus important que les erreurs sur tout autre partition. Un système de fichiers root petit est moins sujet à corruption en résultat d'un plantage système.
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.
/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.
* Commandes générales :
Les commandes suivantes ont été incluses parce qu'elles sont essentielles. Quelques unes sont présentes à cause de leur emplacement traditionnel dans /bin.
{ arch, 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 doit être un lien symbolique ou physique vers /bin/bash puisque le Bash se comporte différemment s'il est appelé en tant que sh ou bash. pdksh, qui peut être le /bin/sh sur les disques d'installation, doit être disposé de la même manière, avec /bin/sh étant un lien symbolique vers /bin/ksh. L'utilisation d'un lien symbolique dans ces cas permet aux utilisateurs de voir aisément que /bin/sh n'est pas un véritable shell de Bourne.
Puisque l'emplacement standard de facto du C-shell est /bin/csh, si et seulement si un C-shell ou équivalent (comme tcsh) est disponible sur le système, il devrait être disponible par le nom /bin/csh. /bin/csh peut être un lien symbolique vers /bin/tcsh ou /usr/bin/tcsh.
Les commandes [ et test sont intégrées dans le Bash, pdksh, zsh, et les Korn shells récents -- essentiellement pour chaque shell de Bourne de remplacement pour Linux. Ces commandes doivent être placées dans /usr/bin. (Elles doivent être incluses comme des binaires séparés avec chaque système Linux qui essaie de se conformer à la norme POSIX.2.)
/bin/arch doit produire la même sortie que uname -m, spécifiquement i386 ou i486 pour les systèmes Intel et compatibles Intel.
* Commandes de remise en état :
Ces commandes ont été ajoutées pour rendre la remise en état d'un système possible (à condition que / soit intact).
{ tar, gzip, gunzip (lien vers gzip), zcat (lien vers gzip) }
Si les sauvegardes système sont effectuées avec des programmes autre que gzip et tar, alors la partition root doit contenir les composants de remise en état minimaux. Par exemple, beaucoup de systèmes doivent inclure cpio puisque c'est l'utilitaire de sauvegarde le plus couramment utilisé après tar. Inversement, si on est sur de ne faire aucune remise en état de la partition root, ces binaires peuvent alors être omis (par exemple, une partition root en ROM, montant /usr en NFS). Si la remise en état d'un système est prévue à travers le réseau, alors ftp ou tftp (avec tout ce qui est nécessaire à l'établissement d'une connexion ftp) doit être disponible sur la partition root.
Les commandes de remise en état peuvent apparaître soit dans /bin soit dans /usr/bin sur différents systèmes Linux.
* Commandes réseau :
Voici les seuls binaires nécessaires pour le réseau, autres que ceux de /usr/bin ou /usr/local/bin, et que à la fois root et les utilisateurs voudront ou auront besoin d'exécuter.
{ domainname, hostname, netstat, ping }
Ce 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.
Voici 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.
/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 généraux :
Ces fichiers sont nécessaires sur la plupart des systèmes Linux.
{ adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group, inittab, issue, ld.so.conf, lilo.conf, magic, motd, mtab, mtools, passwd, profile, psdatabase, securetty, shells, syslog.conf, termcap, ttytype }
* Fichiers de réseau :
Ces fichiers doivent être installés sur la plupart des systèmes Linux.
{ exports, ftpusers, gateways, hosts, host.conf, hosts.equiv, hosts.lpd, inetd.conf, networks, printcap, protocols, resolv.conf, rpc, services }
Il y a deux modèles pour la mise en place des scripts de commandes "rc" qui sont invoqués par init(8) au moment du lancement, le modèle BSD /etc/rc.* et le modèle System V /etc/rc.d/*. Chaque modèle peut être utilisé, ou un mélange des deux.
Les systèmes qui utilisent la suite des shadow passwords auront des fichiers de configuration supplémentaires dans /etc (/etc/shadow et autres) et /usr/sbin (useradd, usermod, et autres).
/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.
Le 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.
Ce 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.
Le 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.
/ 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é.
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.
* Commandes générales :
{ clock, getty, init, update, mkswap, swapon, swapoff, telinit}
* Commandes d'extinction :
{ fastboot, fasthalt, halt, reboot, shutdown }
(Ou toute combinaison des précédents, du moment que shutdown soit inclus.)
* Commandes de gestion du système de fichier :
{ fdisk, fsck, fsck.*, mkfs, mkfs.* }
* = n'importe lequel parmi ext, ext2, minix, msdos, xia et peut-être d'autres
* Commandes du système de fichiers e2fs (optionnelles) :
{ badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs }
* Installateur de la carte de démarrage :
{ lilo }
* Commandes réseau :
{ arp, ifconfig, route }
* Binaires statiques :
Le ln statique (sln) et le sync statique (ssync) sont utiles quand les choses vont mal. L'utilisation première de sln (pour réparer les liens symboliques incorrects dans /lib après une mise à jour mal faite) n'est guère plus d'un grand secours maintenant que le programme ldconfig (situé en général dans /usr/sbin) existe et peut agir comme une aide en mettant les bibliothèques dynamiques à jour. Le sync statique est utile dans la plupart des situations d'urgence. Notez que ceux-ci n'ont pas besoin d'être des versions compilées en statique des commandes standard ln et sync, mais peuvent l'être.
Le binaire ldconfig est optionnel pour /sbin puisqu'un site peut choisir de faire tourner ldconfig au démarrage, plutôt qu'uniquement le jour où on met les bibliothèques partagées à jour. (Il n'est pas clair qu'il soit avantageux ou non de faire tourner ldconfig à chaque démarrage.) Même ainsi, certaines personnes aiment avoir ldconfig à portée de main pour la situation (trop courante) suivante :
(1) Je viens d'enlever /lib/<file>.
(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 }
/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.
