Guide d'installation et de configuration de Linux

Comme tout logiciel d'une certaine taille, un système d'exploitation est d'une grande complexité. Tous les systèmes d'exploitation récents sont en effets constitués d'un grand ensemble de composants qui interagissent entre eux et qui doivent fonctionner de concert afin d'assurer la bonne marche du système et répondre aux besoins de l'utilisateur.

Cette complexité implique un grand nombre d'erreurs, d'anomalies et de dysfonctionnements possibles, ainsi qu'une grande difficulté à en comprendre l'origine. En effet, pour qu'un système informatique fonctionne correctement, il faut tout prévoir pour donner une action appropriée à tous les événements possibles, et trouver la cause d'un problème est d'autant plus difficile qu'il y a de composants qui interviennent dans la fonction défaillante. Cela n'est pas humainement réalisable quand le système devient trop complexe si l'on n'est pas organisé et qu'on ne connaît pas les grandes lignes de l'architecture du système.

Pour résoudre ce problème, il est courant de subdiviser les systèmes complexes en composants indépendants, dont le mauvais fonctionnement potentiel ne peut perturber que partiellement les autres parties du système. Par ailleurs, ces composants sont regroupés en couches logicielles successives, les couches supérieures s'appuyant sur les services des couches inférieures. Ainsi, des points de synchronisation à partir desquels le système peut reprendre un fonctionnement normal après une défaillance peuvent être définis. Ces points de synchronisation permettent donc d'assurer la viabilité du système, ou du moins des couches inférieures, même en cas d'erreur inopinée d'un composant dans une couche de plus haut niveau.

Il va de soi que, lorsqu'un composant se plante, ceux qui l'utilisent risquent de se retrouver dans un état d'erreur assez difficile à gérer. Cela peut souvent provoquer leur propre perte. Par conséquent, plus un composant est utilisé, plus il doit être fiable. Autrement dit, les composants des couches inférieures doivent nécessairement être beaucoup plus fiables que ceux des couches de plus haut niveau, car ils sont utilisés par tout le reste du système.

Pour quelques systèmes, le découpage fonctionnel est trop grossier, voire inexistant. Il arrive également que les interactions entre les composants soient trop importantes et impliquent une dépendance entre eux qui annihile le bénéfice de leur isolation. Dans ces systèmes, une défaillance d'un composant peut donc entraîner un dysfonctionnement global sévère, et en pratique peut nécessiter jusqu'à un redémarrage de l'ordinateur. Les systèmes monolithiques et les systèmes dont les composants sont trop interdépendants sont donc sujets à de nombreux redémarrages, parfois même pour des raisons mineures (modification de la configuration du système, ajout d'un logiciel, ou même simple erreur d'un logiciel).

Il est d'usage de considérer que Linux est un système monolithique. En effet, toute la gestion du matériel, ainsi que la gestion de certaines fonctionnalités de haut niveau, est prise en charge au niveau du noyau (« kernel » en anglais). On pourrait donc craindre une faible fiabilité de ce système d'exploitation. Toutefois, cette vision des choses n'est pas tout à fait juste, car, comme on l'a déjà dit, le noyau n'est qu'une partie du système d'exploitation, et en réalité un système Linux est effectivement constitué de différentes couches fonctionnelles. De plus, le noyau reste d'une taille raisonnable. Pour l'essentiel, il est constitué que d'une base relativement petite et très bien testée, à laquelle beaucoup de pilotes de périphériques ont été ajoutés. La complexité du noyau reste donc limitée, car les pilotes de périphériques ne sont bien entendu pas tous utilisés en même temps sur une même machine.

Par ailleurs, le noyau Linux est d'une très, très grande fiabilité, et il n'est pas rare de voir un système Linux fonctionner plusieurs mois ou années sur des serveurs. Cette grande fiabilité provient du modèle de développement de Linux, qui est ouvert à tout le monde (chacun peut récupérer, lire, modifier, et compléter ou corriger le noyau à condition de savoir bien programmer). Ainsi, à partir d'une taille critique en terme de nombre d'utilisateurs, taille que Linux a atteinte, il existe suffisamment de développeurs pour détecter et corriger les erreurs. En pratique, dès qu'une erreur est détectée, elle est souvent corrigée dans les jours qui suivent si la fonctionnalité concernée est effectivement utilisée, ce qui assure finalement une très grande qualité.

Ainsi, un système Linux est constitué, outre du noyau, d'un certain nombre d'autres couches logicielles, qui s'appuient les unes sur les autres. Nous allons donc présenter brièvement ces couches ici.

Le noyau se trouve bien évidemment à la base de toutes les autres couches, puisqu'il gère quasiment tout le matériel (mémoire, disques, systèmes de fichiers, réseau, clavier, etc.). Mais comme il n'est pas exploitable tel quel (par exemple, il n'est pas capable d'offrir une interface utilisateur permettant de lui donner les commandes que l'ordinateur doit exécuter) il faut au moins une interface utilisateur.

Cette interface utilisateur, c'est ce qu'on appelle le « shell » (ce qui signifie grosso modo « environnement utilisateur »). Le shell est capable de lire des commandes saisies au clavier, de les exécuter et d'afficher leurs résultats à l'écran. En général, les programmes capables de réaliser ces opérations sont appelés des interpréteurs de commandes. Mais le shell est bien plus que cela, car il peut être programmé, et il peut gérer les processus (en arrêter un, en lancer un autre, etc.). Bien entendu, il existe plusieurs shells, mais le plus utilisé sous Linux est le shell bash, qui est développé par la Free Software Foundation et distribué sous licence GPL.

En fait, les commandes que le shell peut exécuter sont en nombre très réduit. La plupart des commandes sont donc tout simplement prises en charge par d'autres programmes. Ces programmes, que l'on peut utiliser directement dans le shell, sont ce que l'on appelle des programmes « en ligne de commande », parce qu'ils sont propres à être utilisés dans les lignes de commandes que l'on saisit au clavier dans le shell. Ces programmes sont, encore une fois, développés soit par la Free Software Foundation, soit par des bénévoles, toujours sous la licence GPL. Toutes ces commandes sont des commandes compatibles Unix, et nous apprendrons à nous en servir dans le Chapitre 5.

Bien entendu, ces commandes sont absolument essentielles pour pouvoir utiliser le système, mais elles sont assez rébarbatives et peu d'utilisateurs acceptent de s'en contenter. C'est pour cela qu'une couche graphique a été développée, pour introduire une interface graphique plus conviviale : XWindow. Encore une fois, cette couche logicielle est constituée de plusieurs composants, dont la base est le serveur X. Le serveur X est un programme capable de fournir les services graphiques (d'où le nom de serveur) aux autres applications. Plusieurs implémentations concurrentes existent. L'une d'elles est particulièrement utilisée sous Linux, puisqu'elle est libre : X.org. À vrai dire, un serveur X ne fait pas grand-chose d'autre que de réaliser des affichages sous les ordres d'autres programmes. D'autres composants permettent donc d'obtenir des fonctionnalités de plus haut niveau.

Le gestionnaire de fenêtres (« Window Manager » en anglais) est un de ces composants. Il se place juste au-dessus du serveur X et prend en charge, comme son nom l'indique, la gestion des fenêtres des applications graphiques sous X. C'est le gestionnaire de fenêtres qui prend en charge la gestion des décorations des fenêtres de premier niveau (c'est-à-dire des fenêtres principales des programmes). Par exemple, il s'occupe d'afficher les bords, la barre de titre, les boutons de réduction et de restauration, etc. des fenêtres. C'est également lui qui s'occupe du positionnement des fenêtres, et qui donc permet à l'utilisateur de déplacer et de réduire les fenêtres des applications graphiques. L'utilisateur est libre d'utiliser le gestionnaire de fenêtres qu'il désire, selon ses propres goûts et ses désirs, la différence est souvent une pure question de style.

Il existe également des environnements graphiques complets qui, en plus de fournir un gestionnaire de fenêtres, fournissent la plupart des outils classiques que l'on est en droit d'attendre d'un système graphique moderne. Ainsi, ces environnements comprennent des éditeurs, des outils de configuration, des navigateurs Internet, des logiciels multimédias… En plus de ces applications, ils fournissent un cadre standard pour les applications graphiques qui savent communiquer avec eux. Ce cadre permet d'améliorer l'intégration des diverses applications entre elles, et c'est la raison pour laquelle on appelle souvent ces environnements des gestionnaires de bureau. KDE et Gnome sont des exemples de tels environnements de travail.

Enfin, au-dessus de toutes ces couches logicielles, on trouve les applications X, qui sont aussi diverses que variées (traitement de texte, tableurs, logiciels de dessin…). Quelques-unes de ces applications sont simplement des « front-end » d'applications en ligne de commande, c'est-à-dire des interfaces graphiques pour des programmes non graphiques. Ce concept permet d'avoir un composant unique réalisant une action, utilisable en ligne de commande et donc scriptable, et une ou plusieurs interfaces graphiques pour ce composant. De plus, ce modèle permet de séparer clairement l'interface graphique du traitement qu'elle permet de réaliser. La stabilité en est d'autant plus accrue.

Bon nombre d'applications pour XWindow sont libres, ou utilisables librement à des fins non commerciales (dans ce cas, on a le droit de les utiliser tant que ce n'est pas pour réaliser un travail qu'on revendra). On peut donc considérer qu'il est actuellement possible, avec Linux, d'avoir un environnement logiciel complet, fiable et performant… pour un prix de revient minime.

Note : Il n'est pas évident d'établir un parallèle entre l'architecture d'un système comme Linux avec celle de MS Windows. Cependant, on peut considérer que le noyau Linux correspond aux modules KERNEL de Windows et de tous les services de type pilote de périphérique, que le shell correspond à l'interpréteur de commandes CMD.EXE, que les programmes en ligne de commande correspondent aux programmes en mode console classique (xcopy, fdisk, format…), que le serveur X correspond au couple (pilote de carte graphique, GDI), que le gestionnaire de fenêtres correspond au module USER, et que le gestionnaire de bureau correspond à l'explorateur, Internet Explorer, aux fonctionnalités OLE permettant la communication entre applications, et aux programmes fournis avec Windows lui-même.

La différence essentielle vient du fait que le shell est à peine programmable sous Windows, que le pilote de carte graphique, la GDI et le module USER sont tous intégrés dans le système au lieu d'en être séparés (ce qui multiplie les chances de crash du système complet), et que la plupart des applications Windows ne peuvent fonctionner que dans l'environnement graphique. Elles sont donc entraînées par le système lorsque les modules graphiques de Windows plantent (je n'ai d'ailleurs jamais vu un processus DOS survivre à un crash de l'interface graphique de Windows).

En résumé, un système GNU/Linux est structuré de la manière suivante :

• le noyau Linux ;
• les programmes en ligne de commande et le shell ;
• le serveur XWindow ;
• le gestionnaire de fenêtres et le gestionnaire de bureau ;
• les applications XWindow.

La figure suivante vous présente comment ces différentes couches logicielles s'agencent les unes par rapport aux autres.

Cette architecture est, comme on peut le voir, très avantageuse :

• les systèmes Unix, donc Linux, sont très structurés, donc plus simples à utiliser, à configurer, à maintenir et à développer ;
• ils sont très stables, car les composants de haut niveau n'interfèrent pas sur les composants de bas niveau ;
• ils sont faciles à personnaliser, puisque l'utilisateur a le choix des outils à chaque niveau ;
• Linux a de plus la particularité d'être parfaitement modifiable, puisque si l'on sait programmer, on peut personnaliser les composants du système ou en rajouter à tous les niveaux ;
• et il n'est pas propriétaire, c'est-à-dire que l'on n'est pas dépendant d'un éditeur de logiciel pour résoudre un problème donné.

En bref, c'est la voie de la vérité.

Les systèmes Unix, depuis leurs origines, ont toujours pris en compte les problèmes de sécurité. En particulier, les développeurs d'application Unix ont toujours fait attention à ce que leurs logiciels se comportent relativement bien en termes de sécurité. En pratique, bien que la sécurité des programmes soit loin d'être parfaite, surtout pour les plus anciens, des principes de base ont toujours été respectés, ce qui fait que les applications Unix ne font pas, en règle générale, n'importe quoi avec le système.

Ainsi, il est beaucoup plus facile de faire fonctionner une application Unix dans un contexte de sécurité restreint qu'une application Windows, car les développeurs de ces dernières ont longtemps été habitués à une très grande liberté et ont donc réalisé des applications qui ne peuvent pas être utilisées si elles n'ont pas les pleins pouvoirs. Les applications Unix qui se comportent mal sont donc très rares, ce qui fait que les systèmes Unix peuvent faire peu de cas d'elles et n'ont pas à maintenir une compatibilité ascendante avec elles. Les systèmes Unix ont donc un modèle de sécurité beaucoup plus simple et strict, et n'ont pas à s'embarrasser avec des techniques complexes et des circonvolutions insensées telles que la virtualisation de l'ensemble du système pour les applications afin d'assurer un semblant de sécurité tout en permettant la compatibilité ascendante.

Par ailleurs, la sécurité permet de protéger non seulement le système, mais aussi l'utilisateur de ses propres erreurs. En effet, le système est capable de se protéger contre les fausses manipulations de l'utilisateur. Cela peut être extrêmement utile avec les débutants, puisqu'ils peuvent expérimenter à loisir tout en étant sûrs qu'ils ne feront pas de bêtise irrémédiable. Ainsi, ils seront plus sereins et n'auront pas « peur de faire une bêtise ». Mais cela est très utile même pour les utilisateurs chevronnés, car tout le monde peut effectivement faire une erreur !

La sécurité permet également de protéger les données de chaque utilisateur vis-à-vis des autres. En effet, par défaut, les données d'un utilisateur ne peuvent pas être modifiées par un autre utilisateur. Vous n'aurez donc aucune crainte que vos chères têtes blondes puissent effacer ou détruire par mégarde votre correspondance professionnelle ou l'ensemble des photos de famille…

Enfin, ayant été prise en compte dès le départ, la sécurité sait se rendre très discrète sur les systèmes Unix, et bien que parfaitement fonctionnelle, elle n'ennuie pas l'utilisateur et reste facilement configurable. Ces deux aspects sont fondamentaux, car du coup, l'utilisateur n'a pas la tentation - ni le besoin - de tout désactiver pour faire fonctionner ses applications !

En résumé, la sécurité sous Linux, c'est :

• une fonctionnalité à part entière, qui est parfaitement intégrée dans le système ;
• un moyen de se protéger contre ses propres erreurs ainsi que celles des autres utilisateurs ;
• une facilité d'utilisation et une transparence qui la rendent utilisable en pratique sans perturber le travail de l'utilisateur.

Linux dispose de plusieurs modèles de sécurité, mais, historiquement, la sécurité se base sur la notion d'utilisateur. Nous allons donc nous intéresser ici à la notion d'utilisateur, et voir comment cette notion peut être utilisée pour mettre en pratique les contrôles de sécurité du système.

Comme vous le savez sans doute déjà, Linux est un système multi-utilisateur. Cela signifie que plusieurs personnes peuvent utiliser l'ordinateur simultanément (et pas uniquement les unes à la suite des autres), et que le système se charge de faire respecter la loi entre elles. Le système protège les données de chaque utilisateur des actions que peuvent effectuer les autres utilisateurs. Il veille également à partager équitablement les ressources de la machine entre les utilisateurs, tant au niveau de la puissance de calcul qu'au niveau de la mémoire, du disque, des imprimantes, etc.

Note : Si vous vous demandez comment plusieurs personnes peuvent se partager le clavier et l'écran et ainsi utiliser l'ordinateur en même temps, la réponse est simple : ils ne le peuvent pas. Par contre, il est possible que plusieurs personnes soient connectées à l'ordinateur via le réseau, utilisant d'autres claviers et d'autres écrans (on appelle un couple clavier/écran un « terminal »). Il est de plus théoriquement possible de connecter plusieurs claviers, souris et écrans à une même unité centrale, même si ces configurations sont encore très rares et non standards. Les utilisateurs peuvent également lancer des programmes en arrière-plan, et laisser ces programmes tourner même lorsqu'ils ne sont plus connectés à l'ordinateur. Évidemment, cela nécessite que les programmes ainsi lancés ne soient pas interactifs. Autrement dit, ils doivent être capables de fonctionner sans intervention de celui qui les a lancés.

Ne croyez pas que ce dernier cas de situation est extrêmement rare. En effet, le système utilise des tâches qui tournent en arrière-plan dans des comptes dédiés et différents du vôtre, afin de prendre en charge certaines fonctionnalités ou de réaliser des opérations de maintenance.

En interne, le système affecte un numéro unique à chaque utilisateur afin de pouvoir l'identifier. Ce numéro d'utilisateur est défini lors de la création de son compte dans le système, et ne peut être modifié par la suite. Ainsi, toute action effectuée dans le système peut être rattachée à un utilisateur particulier. L'utilisation du système requiert donc que chaque utilisateur s'identifie au niveau du système avant toute autre opération. Généralement, cela se fait en indiquant son nom d'utilisateur, que l'on appelle classiquement le « login ». Bien entendu, afin d'éviter qu'un utilisateur puisse usurper l'identité d'un autre utilisateur, le système exige que l'utilisateur fournisse un mot de passe après s'être identifié pour s'authentifier.

La sécurité du système se base alors, lorsqu'une opération est exécutée, sur l'identité de l'utilisateur qui réalise cette commande et sur les droits dont cet utilisateur dispose sur les objets que cette commande doit manipuler. Par exemple, la suppression d'un fichier système ne peut pas être réalisée par un utilisateur lambda, parce que cet utilisateur n'a pas les droits de suppression (ni de modification d'ailleurs, et parfois même de lecture) sur ce fichier.

L'administration du système lui-même revient à la charge d'un utilisateur particulier. Cet utilisateur, classiquement nommé « root », a virtuellement tous les droits sur le système. C'est ce qu'on appelle l'administrateur du système, ou encore le super utilisateur. En interne, le super utilisateur est identifié par le numéro 0, qui lui est réservé. Ainsi, seul l'utilisateur dont le numéro est 0 peut modifier les fichiers de configuration du système.

Note : Bien entendu, travailler sous l'identité du super utilisateur est extrêmement dangereux, car dès lors tous les mécanismes de sécurité du système sont désactivés. Une erreur de manipulation avec cette identité peut donc être fatale et détruire complètement le système ! C'est pour cette raison que la plupart des distributions imposent de définir un compte utilisateur standard en plus du compte root, et que vous ne devriez travailler que sous ce compte. Ce n'est pas une restriction, c'est tout simplement pour votre bien. Ne vous inquiétez pas, comme il l'a déjà été dit plus haut, vous n'avez quasiment jamais besoin des droits administrateurs pour travailler sous Linux, parce que les applications sont en général conçues dès le départ pour être utilisables dans des comptes restreints. Alors n'ayez aucune crainte, et respectez les bonnes manières : ne travaillez jamais sous le compte root.

Les nouveaux utilisateurs de Linux qui ont fait leurs premiers pas en informatique sous Microsoft Windows ont souvent tendance à considérer cette recommandation comme un « faites ce que je dis, pas ce que je fais » et croient donc que les utilisateurs chevronnés ne la respectent pas. Qu'ils se détrompent, la plupart des utilisateurs de Linux respectent cette règle en permanence ! Ce n'est pas parce que ce n'est pas votre habitude que cette recommandation est un « on-dit ». D'ailleurs, elle est tellement importante que certaines distributions désactivent tout bonnement le compte administrateur. Il est donc tout simplement impossible de se connecter sous ce compte, même si l'on est la personne qui a installé le système ! Bien entendu, dans ce cas, les opérations d'administration sont toutes identifiées et nécessitent de fournir le mot de passe administrateur pour être exécutées.

En résumé, les mécanismes de sécurité basés sur la notion d'utilisateur fonctionnent selon les principes suivants :

• l'utilisateur doit s'identifier (généralement, en fournissant son identifiant d'utilisateur, ou « login ») et s'authentifier (classiquement en fournissant son mot de passe, ou « password ») lorsqu'il se connecte à l'ordinateur ;
• le noyau conserve pour chaque processus que l'utilisateur lance l'identité de cet utilisateur ;
• le noyau contrôle les droits de l'utilisateur à chaque accès d'une ressource de chaque programme de cet utilisateur (en particulier, comme nous allons le voir plus loin, au niveau des fichiers) ;
• le noyau assure une indépendance totale des processus, tant au niveau des zones de mémoire utilisées qu'au niveau de l'accès aux ressources de la machine. Un processus ne peut donc, par défaut, ni lire ni écrire dans la mémoire d'un autre processus, et les ressources de calcul ou d'entrée/sortie sont partagées entre les différents processus par les mécanismes du multitâche.

Nous avons vu que le noyau contrôlait les droits de l'utilisateur vis-à-vis des ressources qu'il manipulait pour chaque processus qu'il exécute. En particulier, l'accès à chaque fichier est contrôlé lors de l'ouverture de ce fichier par les processus de l'utilisateur. Ainsi, les données de chaque utilisateur sont protégées par le système, ainsi que les fichiers du système lui-même. De plus, comme l'accès aux périphériques se fait généralement par l'intermédiaire de fichiers spéciaux, les accès aux ressources matérielles sont également contrôlés via les mécanismes de sécurité du système de fichiers. Il est donc important de comprendre comment les systèmes de fichiers gèrent la sécurité.

IV-B-3-a. Les droits sur les fichiers▲

-rw-r--r-- 1 jean users 444 2006-12-10 08:42 lisezmoi.txt

IV-B-3-b. Notion d'ACL▲

IV-B-3-c. Les attributs spéciaux des fichiers▲

Pour commencer, il faut préciser que Linux ne travaille pas directement avec les systèmes de fichiers physiques. En effet, il interpose systématiquement un système de fichiers intermédiaire, nommé « Virtual File System » (« VFS » en abrégé), qui permet aux applications d'accéder à différents systèmes de fichiers de manière indépendante de leur nature et de leur structure interne. Le système de fichiers virtuel ne fait pas grand-chose en soi : il se contente de transférer les requêtes des applications vers les systèmes de fichiers réels. Il fournit donc une interface bien définie pour les applications, que celles-ci doivent utiliser. Les systèmes de fichiers réels, quant à eux, doivent simplement fournir les services dont le système de fichiers virtuel a besoin. Tous les systèmes de fichiers réels ne disposent toutefois pas forcément de toutes les fonctionnalités demandées par le système de fichiers virtuel. Dans ce cas de configuration, la requête de l'application désirant effectuer l'opération manquante échouera tout simplement.

Comme on peut le constater, cette architecture est modulaire. Et comme on l'a vu pour l'architecture du système en général, cela apporte beaucoup de bénéfices. Les plus évidents sont indiqués ci-dessous :

• Linux est capable de gérer plusieurs systèmes de fichiers réels. La seule condition est qu'ils doivent tous fournir les services de base exigés par le système de fichiers virtuel ;
• les applications peuvent utiliser plusieurs de ces systèmes de fichiers réels de manière uniforme, puisqu'elles n'utilisent que le système de fichiers virtuel. Cela simplifie leur programmation, et permet d'éviter autant de bogues potentiels ;
• chaque système de fichiers réel étant indépendant des autres, il ne perturbe pas leur fonctionnement. En particulier, un système de fichiers corrompu ne corrompt pas les autres.

Avec cette architecture, un grand nombre de systèmes de fichiers ont été développés pour Linux. Parmi ces systèmes de fichiers, on retrouve les plus connus, à savoir :

• le système de fichiers EXT2, qui est le système de fichiers natif de Linux ;
• le système de fichiers EXT3, qui est une évolution du système de fichiers EXT2 capable de prendre en charge également les mécanismes de journalisation (voir la note ci-dessous pour savoir ce qu'est la journalisation d'un système de fichiers) ainsi que les blocs défectueux sur le support physique ;
• le système de fichiers ReiserFS, qui supprime la notion de bloc disque et qui est également journalisé ;
• les systèmes de fichiers FAT, FAT32 et FAT32X (utilisés par les systèmes DOS et Windows, ainsi que par les clefs USB et les cartes mémoire) ;
• le système de fichiers NTFS (utilisé par Windows NT, Windows 2000 et XP), en lecture et partiellement en écriture (seul l'écrasement des données existantes dans un fichier, sans redimensionnement, est autorisé à l'heure actuelle) ;
• le système de fichiers ISO9660, qui est utilisé par tous les CD-ROM. Les extensions permettant de gérer les noms longs sont également gérées. Ces extensions comprennent en particulier le système de fichiers Joliet (extensions de Microsoft pour Windows 95) et Rock Ridge (extensions utilisées par tous les systèmes Unix) ;
• le système de fichiers NFS (utilisé pour distribuer sur un réseau un système de fichiers).

Note : La journalisation consiste à écrire sur le disque toutes les opérations en cours à chaque instant. Ainsi, lorsqu'un redémarrage intempestif se produit, le système peut ramener rapidement la structure de données du système de fichiers dans un état cohérent. La journalisation accroît donc encore à la fiabilité du système de fichiers.

Linux gère également d'autres systèmes de fichiers natifs ou utilisés par d'autres systèmes d'exploitation (Unix ou non). Il permet même d'intégrer des pseudo systèmes de fichiers générés par le noyau. Ces systèmes de fichiers sont complètement fictifs : leur structure et leurs fichiers sont générés dynamiquement par le noyau lorsqu'une application y accède. Ils sont principalement utilisés pour fournir aux applications des informations que le noyau met à leur disposition, pour réaliser des systèmes de fichiers en mémoire, et pour gérer l'ensemble des fichiers spéciaux de périphériques installés sur l'ordinateur.

Les systèmes de fichiers natifs de Linux sont de loin les systèmes de fichiers les plus fonctionnels, les plus fiables et les plus courants. Le choix du système de fichiers dépend donc généralement de l'usage que l'on en fera, certains systèmes de fichiers étant plus appropriés pour certains types d'utilisation. Si l'on recherche essentiellement la stabilité, je recommande le système de fichiers EXT3, car c'est pour l'instant le seul système de fichiers capable de prendre en compte les blocs défectueux sur le support physique.

Quoi qu'il en soit, on ne pourra installer Linux que sur un système de fichiers de type Unix. Ces systèmes de fichiers sont tous plus fonctionnels et plus performants que les systèmes de fichiers FAT. Leurs principales fonctionnalités sont les suivantes :

• les accès aux fichiers sont rapides, même plus rapides que les systèmes de fichiers basés sur la FAT sous Windows, qui pourtant ne gèrent pas les droits des utilisateurs ni les autres fonctionnalités avancées des systèmes de fichiers Unix ;
• la fragmentation des fichiers est quasiment inexistante. En fait, la fragmentation des fichiers existe effectivement, mais les algorithmes utilisés par les systèmes de fichiers pour allouer les blocs du disque dur lors de l'écriture dans un fichier sont suffisamment évolués pour éviter qu'elle ne se produise de manière trop importante. De plus, les algorithmes de lecture anticipée des blocs et de mise en mémoire cache des données lues du sous-système d'entrée/sortie masquent complètement les latences dues à la fragmentation. De ce fait, en pratique, la fragmentation n'a pas d'impact sur les performances du système, et peut être tout simplement ignorée. Pour donner un ordre de grandeur, après installation, suppression, manipulation d'un grand nombre d'applications et de petits fichiers sur une partition EXT2 de 800 Mo, le tout réalisé par plusieurs processus fonctionnant en même temps, la fragmentation reste inférieure à 1% sur 57571 fichiers (sur un total de 249856 fichiers que le système de fichiers pourrait contenir) ;
• quant à la fiabilité, elle est gérée grâce à un stockage redondant des principales structures de données internes. Ainsi, si une erreur apparaît dans le système de fichiers, les parties défectueuses peuvent être reconstituées à partir des informations sauvegardées. Cette réparation est réalisée automatiquement à chaque redémarrage de la machine si nécessaire.

Une fonctionnalité intéressante fournie par les systèmes de fichiers Unix est la possibilité de réaliser des liens sur des fichiers ou des répertoires.

Un lien est une référence à un fichier ou un répertoire existant, qui peut être manipulé exactement comme sa cible. Il existe deux sortes de liens : les liens physiques, qui sont réellement une référence sur les données du fichier au niveau de la structure même du système de fichiers, et les liens symboliques, qui ne sont rien d'autre qu'un fichier additionnel contenant les informations nécessaires pour retrouver la cible.

Les liens physiques présentent les inconvénients de ne pas pouvoir référencer des répertoires, et de ne pouvoir référencer que des objets du même système de fichiers que celui dans lequel ils sont créés. La limitation sur les répertoires permet d'éviter de construire des cycles dans la structure du système de fichiers. Quant à la limitation à la frontière des systèmes de fichiers, elle est obligatoire puisque les liens physiques sont gérés directement au niveau de la structure du système de fichiers. En revanche, ils présentent des avantages certains :

• le déplacement des cibles ne les perturbe pas si celles-ci restent dans le même système de fichiers, parce que dans ce cas les données ne sont pas déplacées sur le disque ;
• la suppression de la cible ne détruit pas le lien physique. Tous les liens physiques sur un fichier partagent la même structure de données du système de fichiers, et celle-ci n'est réellement détruite qu'à la destruction du dernier lien physique.

En fait, toute entrée de répertoire est un lien physique sur le contenu du fichier. Le fait d'avoir plusieurs liens physiques sur les mêmes données correspond à disposer de plusieurs entrées de répertoire donnant accès aux mêmes données dans le système de fichiers. Il serait possible de créer des liens physiques dans un système de fichiers FAT, mais ils seraient interprétés comme des références croisées par les outils de vérification de disque. Le système de fichiers FAT de Linux interdit donc la création des liens physiques, tout comme le font DOS et Windows.

Les liens symboliques, quant à eux, permettent de référencer des fichiers ou des répertoires se trouvant dans d'autres systèmes de fichiers que le leur. C'est pour cette raison qu'ils sont très couramment utilisés (en fait, les liens physiques ne sont quasiment pas utilisés, parce qu'il est très courant de faire un lien sur un répertoire, ce que seuls les liens symboliques savent faire). En revanche, ils sont extrêmement dépendants de leur cible : si elle est supprimée ou déplacée, tous les liens symboliques qui s'y réfèrent deviennent invalides.

La référence sur le fichier ou le répertoire cible contenue dans les liens symboliques peut être soit relative à l'emplacement de leur cible, soit absolue dans le système de fichiers. Chacune de ces méthodes a ses avantages et ses inconvénients : les liens symboliques qui contiennent des références relatives ne sont pas brisés lors d'un déplacement de la cible, pourvu qu'ils soient déplacés également et restent à la même position relative par rapport à celle-ci dans la hiérarchie du système de fichiers. En revanche, ils sont brisés s'ils sont déplacés et que la cible ne l'est pas. Les liens symboliques utilisant des références absolues sont systématiquement brisés lorsque la cible est déplacée, mais ils restent valides lorsqu'ils sont eux-mêmes déplacés. Comme en général c'est le comportement que l'on recherche, les liens symboliques sont toujours créés avec des références absolues, mais vous êtes libre de faire autrement si vous en ressentez le besoin. Sachez cependant que déplacer une source de données n'est jamais une bonne idée. Le tableau suivant récapitule les avantages et les inconvénients des différents types de liens :

Tableau 4-1. Caractéristiques des liens physiques et symboliques

Les systèmes de fichiers de Linux fournissent également des fonctionnalités qui peuvent être intéressantes, mais que l'on utilise généralement moins souvent.

La première de ces fonctionnalités est les quotas. Ceux-ci permettent de définir la proportion d'espace disque que chaque utilisateur peut consommer dans le système de fichiers. Ainsi, il est possible de restreindre les utilisateurs et d'éviter qu'un seul d'entre eux ne consomme l'ensemble des ressources disque. En pratique, cette fonctionnalité n'est pas d'une grande utilité pour un particulier, qui souvent est le seul utilisateur de sa machine.

Note : Sachez toutefois que les systèmes de fichiers réservent généralement une petite partie (environ 5%) de l'espace disque pour l'administrateur du système, afin de s'assurer que celui-ci pourra toujours effectuer les opérations de maintenance en cas de saturation du système de fichiers. Cet espace libre est également utilisé pour les mécanismes de défragmentation automatique des systèmes de fichiers.

Les systèmes de fichiers permettent également d'enregistrer des informations complémentaires sur les fichiers, afin par exemple de pouvoir les marquer pour un traitement spécifique. Ces informations complémentaires sont stockées sous la forme « d'attributs », pouvant contenir virtuellement n'importe quel type d'information. Certains systèmes de fichiers utilisent cette fonctionnalité pour implémenter les mécanismes de sécurité basés sur les ACL.

Enfin, les systèmes de fichiers Unix sont également capables de prendre en charge ce que l'on appelle les fichiers « troués » (« sparse files » en anglais). Ces fichiers sont des fichiers contenant des données séparées par de grands espaces vides. On peut donc dire qu'ils sont « presque vides ». Pour ces fichiers, il est évident qu'il est inutile de stocker les espaces vides sur le disque. Les systèmes de fichiers mémorisent donc tout simplement qu'ils contiennent des trous, et ils ne stockent que les données réelles et la position des trous avec leurs tailles. Cela constitue une économie de place non négligeable. Les applications classiques des fichiers presque vides sont les bases de données, qui utilisent souvent des fichiers structurés contenant relativement peu de données effectives, et les images disque pour installer des systèmes d'exploitation dans des machines virtuelles.