Comprendre et analyser le système Linux

Le système Linux est à la fois complexe et simple. Comparativement à d'autres systèmes d'exploitation du marché, il est beaucoup plus simple : il repose sur un petit nombre de principes et d'abstractions qui se retrouvent tout le temps. Pourtant, la présente formation dure quatre jours et des années sont nécessaires pour acquérir la maîtrise complète de Linux : c'est donc que c'est un système complexe !

Cette complexité est réelle, mais elle existe aussi dans les systèmes propriétaires modernes : Windows 98, par exemple, totalise environ 30 fois plus de lignes de code que Linux. Simplement, elle n'est pas visible de la même façon. Linux étant un système totalement ouvert, il est possible d'aller au fond des choses : outre l'intérêt purement intellectuel, cette démarche permet de résoudre des problèmes délicats d'administration système.

1 Diffusion du présent document

Ce document appartient à IDEALX. Il est librement diffusable dans les termes de la Licence de Documentation Libre GNU (traduit de la GNU Free Documentation License).

2 Les paquetages --- la commande `rpm`

Tous les fichiers installés par la distribution RedHat (ou toute autre distribution utilisant le format RPM) sont consignés dans une base de données dont les fichiers se trouvent dans /var/lib/rpm. La commande rpm sert à interroger cette base et à l'administrer (installation ou suppression de paquetages) ; elle facilite grandement le travail de l'administrateur, car elle permet de garder facilement les fichiers et répertoires du système Linux dans un état convenable. rpm est le moteur dont kpackage et gnoRPM sont deux carrosseries possibles.

2.1 Les fonctions d'administration de `rpm`

Il s'agit des fonctions qui permettent d'installer ou de désinstaller un paquetage.

rpm --upgrade <fichier.rpm>: Installe un paquetage RPM (téléchargé depuis l'Internet ou obtenu sur un CD-ROM). Cette forme supprime le précédent paquetage installé du même nom si il existe ; elle doit être utilisée pour installer des programmes.
rpm --install <fichier.rpm>: Installe un paquetage RPM. Cette forme ne supprime pas un éventuel paquetage du même nom plus ancien ; c'est elle qu'il faut utiliser pour installer des bibliothèques dynamiques (ainsi les programmes qui veulent utiliser l'ancienne version le peuvent encore).
rpm --erase <nom>: Supprime du disque le paquetage RPM <nom>. <nom> peut comporter un numéro de version ou non, au choix de l'administrateur ; si il n'y a pas de numéro de version, et que plusieurs paquetages du même nom existent, rpm émet un avertissement et ne fait rien.

Les options suivantes peuvent être rajoutées à la fin de l'une des lignes de commande ci-dessus :

--nodeps: Ignore les dépendances entre paquetages pendant l'opération. Par exemple, pour passer de sendmail à postfix comme agent de transfert du courrier électronique, il faut bien sûr désinstaller sendmail puis installer postfix. Cependant la première opération est normalement interdite par le mécanisme des dépendances, puisque de nombreux programmes nécessitent un agent de transfert (à commencer par les agents utilisateurs de courrier électronique, comme mutt).
--force: Ignore les problèmes qui se posent en-dehors des dépendances (comme par exemple des fichiers qui appartiennent à un autre paquetage et qui seraient écrasés par l'installation du nouveau).

Note : rpm ne peut pas être utilisé pour recréer un fichier .rpm à partir de sa version installée sur disque. Cette limitation est volontaire, elle impose un cycle de test rigoureux lors de la création d'un fichier RPM. On ne doit pas pouvoir créer un RPM «à la va-vite», car il risquerait de ne pas être portable ou d'être impossible à reproduire, même en disposant des sources.

2.2 `rpm` et les fichiers de configuration

Lors de la mise à jour d'un programme par rpm --upgrade, les fichiers de configuration du précédent programme ne sont pas effacés. La base de données rpm sait quels fichiers sont des fichiers de configuration ; suivant les dates de modification respectives du fichier de configuration installé et modifié par l'administrateur d'une part, et de celui du nouveau paquetage d'autre part, rpm prendra la décision qui s'impose :

soit il installe le nouveau fichier de configuration sous le nom <fichier>.rpmnew et ne touche pas à celui de l'administrateur,
soit il déplace le fichier déjà installé sous le nom <fichier>.rpmorig et il installe le nouveau à la place.

La notion de fichier de configuration employée dans les paquetages RPM est flexible (elle ne dépend pas du répertoire dans lequel se situe le fichier) et large (les scripts de /etc/rc.d en font partie) : cela supprime les mauvaises surprises et permet d'utiliser rpm --upgrade avec confiance.

2.3 Les fonctions d'interrogation de `rpm`

La fonction d'interrogation de la base de données que propose rpm est vitale : grâce à elle, l'administrateur peut connaître très facilement des données sur les fichiers installés qui sont indispensables à son travail. rpm peut aussi être utilisé pour examiner des paquetages qui ne sont pas encore installés : voir l'option -p ci-dessous.

Toutes les lignes de commande qui interrogent la base commencent par rpm -q. On ajoute ensuite une ou plusieurs options parmi celles-ci pour choisir le type de rapport voulu :

-i: Affiche des informations détaillées sur les paquetages sélectionnés.
-l: Affiche la liste des fichiers qui appartiennent aux paquetages sélectionnés.

À défaut d'option -i ou -l, les noms et les numéros de version des paquetages sélectionnés seront affichés. Pour savoir quels paquetages seront sélectionnés, c'est-à-dire feront l'objet de la description ainsi spécifiée, on ajoute un ou plusieurs des arguments suivants :

-f <fichier>: Le paquetage installé qui contient le fichier <fichier> sera sélectionné.
-a: Tous les paquetages installés seront sélectionnés.
-p <chemin>: Le paquetage <chemin> sera sélectionné : <chemin> peut être un fichier RPM ou bien une URL (FTP ou HTTP) qui pointe vers un fichier RPM. Il n'est pas nécessaire qu'il soit déjà installé.
<nom>: Sélectionne le ou les paquetages installés qui s'appellent <nom>. <nom> peut contenir un numéro de version ou non, au choix.

Si on regroupe le tout, la commande rpm -q -a liste tous les paquetages installés, tandis que rpm -q -i -l -f /usr/share/magic donne toutes les informations (description et liste des fichiers) du paquetage qui contient le fichier /usr/share/magic. La page de manuel de rpm liste encore de nombreuses autres options, certaines d'entre elles ayant trait à la création de nouveaux paquetages RPM.

3 Bibliothèques partagées

Les bibliothèques partagées sont des regroupements de fonctions couramment utilisées par différents programmes. Plutôt que d'être dupliquées dans les binaires de tous les programmes, elles sont isolées dans des fichiers spéciaux qui se trouvent dans les répertoires /lib , /usr/lib, /usrlocallib ou encore /usrX11R6lib et possèdent l'extension .so . Les avantages de cette méthodes sont les suivants :

Économie de place : le code dupliqué n'existe qu'en un seul exemplaire, tant sur le disque qu'en mémoire vive grâce aux fonctions avancées de partage de la mémoire qu'offre Linux.
Facilité de mise à jour : le code fréquemment utilisé se trouve regroupé en un seul endroit, ce qui permet de faciliter la mise à jour globale du système notamment en cas de problème de sécurité.

Il y a des bibliothèques dynamiques à propos de tout, depuis la bibliothèque C (/lib/libc.so.6) qui contient virtuellement toutes les fonctions de base du langage C et est utilisé par quasiment tous les programmes, jusqu'à des bibliothèques bizarres comme /lib/libcom_err.so qui a pour rôle de signaler les erreurs dans les systèmes de fichiers ext2 (!). Il y a même une bibliothèque partagée pour charger des bibliothèques partagées¹, qui s'appelle le chargeur dynamique (/libld-linux.so.2).

3.1 Utilitaires d'administration des bibliothèques partagées

la commande ldd <prog> permet de savoir quelle(s) bibliothèque(s) partagée(s) le programme <prog> utilise ;
la commande ldconfig régénère tous les liens symboliques dans les répertoires contenant des bibliothèques partagées (ces répertoires sont répertoriés dans le fichier /etc/ld.so.conf). L'usage des liens symboliques permet de conserver plusieurs versions de chaque bibliothèque, tout en passant de l'une à l'autre en un seul appel système : ainsi la mise à jour d'une bibliothèque peut se faire sans arrêter le système !
La commande ltrace permet de suivre les appels à des fonctions de bibliothèques dynamiques effectués par un programme, exactement de la même façon que strace le fait pour les appels système (voir le paragraphe 5.1.2) : de même que strace, c'est un outil précieux pour étudier le comportement d'un programme qui ne fonctionne pas correctement.

3.2 Que faire en cas de panne des bibliothèques partagées ?

Lorsque, par exemple, la bibliothèque C est effacée, plus aucun programme ne peut être lancé sauf ceux qui n'utilisent pas du tout les librairiebibliots partagées. C'est l'un des cas où une petite erreur d'administration peut faire le plus de dégâts... Le symptôme est que tous les programmes se plaignent d'une librairie manquante au lancement, ou bien ne semblent pas exécutables (si c'est /libld-linux.so.2 qui est touché). Heureusement, les programmes déjà lancés ne meurent pas : ils conservent un descripteur de fichier ouvert vers l'ancienne bibliothèque, dont les blocs sur disque ne seront pas récupérés par le noyau tant qu'au moins un programme restera dans cette situation.

Si vous n'avez pas la main au moment où le problème ce produit, vous n'avez plus qu'à éteindre brutalement la machine et à la relancer à l'aide d'une disquette de secours (voir le paragraphe 4.1). Si vous avez un shell ouvert, en revanche, tout n'est pas perdu : vous pouvez encore lancer les programmes statiquement liés, en particulier ldconfig, rpm (qui peut vous permettre de réinstaller la librairie C) et sash. Ce dernier programme est un shell qui contient quelques commandes d'administration usuelles en interne : contrairement à un shell traditionnel, il ne fait pas appel à des sous-programmes pour lancer des commandes telles que cp, tar, ou même mount qui peut permettre de récupérer des programmes depuis une disquette.

4 Les systèmes de fichiers sous Linux

Un système de fichiers est une façon d'organiser en fichiers le tas d'octets que représente un disque dur ou une connexion réseau. Le système de fichier standard de Linux s'appelle ext2, mais il en supporte de nombreux autres, tant sur supports de type disque qu'en réseau. Le but de ce paragraphe est de rappeler des points importants au sujet des systèmes de fichiers et de permettre à l'utilisateur de s'en servir.

4.1 Comment réparer un système de fichiers planté ?

Dans certaines circonstances, le système automatique de correction des erreurs disque au démarrage du système refuse de fonctionner en mode automatique parce qu'il se trouve face à une décision qu'il ne peut pas prendre seul. Il faut alors effectuer la correction à l'aide du programme e2fsck. Voici la marche à suivre :

Si c'est la partition racine qui est corrompue, utiliser une disquette d'amorçage de secours, telle que celle livrée avec la distribution RedHat ou bien l'excellente Tom's Root/Boot. Sinon, rentrer le mot de passe de root à l'invite du système pour passer en mode de maintenance (mono-utilisateur).
Lancer e2fsck /dev/<partition>. Si l'utilitaire se plaint de ne pas retrouver ses petits, c'est que le super-bloc (la table des matières) de cette partition n'est pas lisible : ce peut être parce que ce n'est pas la bonne partition, ou bien parce qu'il a été effacé suite à une corruption du disque. Essayer l'un des super-blocs de secours, avec une commande comme e2fsck /dev/<partition> -b n , où n est un multiple de 8192 plus 1.
Répondre aux questions concernant le système de fichiers (presque systématiquement y sauf quand les chiffres présentés deviennent aberrants, ce qui est signe qu'e2fsck perd les pédales). Certains fichiers perdus dans le système de fichiers et dont l'entrée de répertoire a disparu seront reconnectés au répertoire lost+found en haut de l'arborescence de la partition (équivalent des fichiers FILE0001.CHK de Scandisk).
Si des fichiers ont été connectés à lost+found, remonter la partition dans un sous-répertoire de /mnt (par exemple). Utiliser la commande file sur tous les fichiers qui se trouvent dans /mntlost+found pour les trier par type (scripts, images, fichiers binaires, etc). Ensuite, il ne reste plus qu'à les remettre chacun à leur place.
Démonter la partition et réamorcer.

5 Le noyau Linux : sa vie, son oeuvre

Les paragraphes précédents traitaient surtout de concepts standard sinon dans l'informatique, du moins dans le monde UNIX. Dans celui-ci, nous allons nous aventurer d'un seul coup beaucoup plus profondément dans le système Linux et ses spécificités !

5.1 Qu'est-ce que le noyau ?

Le noyau est le premier programme chargé en mémoire vive au démarrage de l'ordinateur. Il faut se le représenter comme les fondations du système Linux, et les programmes comme une maison bâtie par-dessus. Les ordinateurs compatibles PC sont d'une infinie diversité par leur puissance, le type et le nombre de leurs périphériques, etc. ; mais le noyau est une plateforme de béton standardisée qui fait se ressembler tous les PC du monde.

Techniquement parlant, le noyau de tout système d'exploitation qui se respecte est en charge des fonctionalités suivantes :

Chargement des programmes :: c'est la fonctionalité la plus indispensable. Pour diverses raisons, l'image sur disque d'un programme n'est pas identique à sa copie en mémoire ; le noyau a pour fonction d'initialiser tout ce qui est nécessaire pour que les programmes puissent tourner.
Multitâche préemptif :: même sur une machine monoprocesseur, qui ne peut exécuter qu'une seule instruction assembleur à la fois, Linux doit pouvoir faire tourner plusieurs programmes à la fois. Il y parvient en attribuant à chaque programme une petite fraction de seconde pour s'exécuter, à tour de rôle pour chacun d'eux ; et ce de façon préemptive, c'est-à-dire en interrompant le programme sans délai quelle que soit l'opération qu'il est en train d'effectuer.
Gestion et protection de la mémoire :: comme plusieurs programmes et le noyau doivent coexister en mémoire vive, les différents programmes ne doivent pas pouvoir écrire sur les zones mémoire des autres ou du noyau. Le microprocesseur doit donc être équipé de fonctionalités qui lui permettent de «faire attention à ce qu'il fait», car il suffit d'une instruction assembleur mal placée pour écrire n'importe où en mémoire... Tout manquement aux règles de gestion de la mémoire fixées par le noyau doit être sanctionnée par la terminaison immédiate du programme fautif.
En guise d'extension (supportée par Linux, bien entendu), le noyau du système d'exploitation peut offrir les fonctions de mémoire virtuelle ou swap (certaines zones de la mémoire vive attribuée aux programmes sont copiées sur le disque dur pour faire de la place), ou inversement d'antémémoire ou cache (les zones inutilisées de la mémoire sont remplies avec des copies des données présentes sur disque, pour limiter le nombre d'accès en lecture-écriture au disque et donc améliorer les performances). Bien évidemment, ces deux fonctions doivent s'accomplir de façon totalement transparente pour les programmes : ils ne doivent pas avoir à réclamer à nouveau leurs zones de mémoire si elles ont disparu dans la mémoire virtuelle, et si ils ont besoin de plus de mémoire l'antémémoire doit être immédiatement réduite pour leur faire de la place.
Abstraction des périphériques :: un fichier est un fichier, et une souris est une souris ! Le noyau doit proposer aux programmes une interface standardisée d'accès aux périphériques qui soit identique selon le type du système de fichiers, de la souris, de la carte réseau, etc. De cette façon, le code qui gère la communication avec un nouveau matériel se retrouve factorisé à un seul et même endroit : dans un pilote de périphérique, un composant du noyau.
Droits d'accès :: le noyau est responsable du fait que les accès aux ressources de la machine (fichiers, communications réseau, périphériques etc) se fassent dans l'ordre et la discipline. C'est donc lui seul qui a le droit de parler aux périphériques² : il n'y a pas d'autre moyen pour un programme Linux pour lire ou écrire dans un fichier que d'en faire la demande au noyau, au moyen d'une procédure spéciale qu'on nomme un appel système. Et si le noyau considère, au vu des politiques de sécurité pour lesquelles il a été programmé, que le programmes appelant n'a pas les droits convenables pour l'opération qu'il demande, il peut rejeter l'appel système et renvoyer une erreur.
Le concept de droits d'accès peut englober celui de multi-utilisateurs, comme c'est le cas sous Linux : plusieurs utilisateurs différents peuvent cohabiter sur le même système informatique, chacun d'eux étant protégé des accès intempestifs à ses ressources (notamment ses fichiers) de la part des autres utilisateurs.

5.1.1 Frontière utilisateur / noyau

Dans le système Linux, le noyau est un composant logiciel du système qui ne ressemble à aucun autre. Il occupe une zone de la mémoire vive qui lui est réservée à perpétuité (elle n'est jamais envoyée en mémoire virtuelle), il configure le processeur pour se donner tous les droits d'accès à la mémoire et aux périphériques (et il restreint à nouveau ces droits avant de rendre la main à un programme). Il peut ainsi lire et écrire dans les plages d'adresse mémoire de tous les programmes, mais l'inverse n'est pas possible. C'est lui seul qui réceptionne les interruptions déclenchées par les périphériques, et qui stocke les données échangées avec eux dans ses tampons avant de les distribuer aux programmes concernés.

En un mot, le noyau Linux dispose des privilèges maximaux sur le matériel de l'ordinateur, et il défend ces privilèges par rapport aux programmes pour assurer la sécurité du système. Ceci ce conceptualise sous la forme d'une frontière entre les programmes et le noyau : on distingue les morceaux de code qui s'exécutent en espace utilisateur avec des privilèges réduits (tous les programmes, y compris les démons d'arrière-plan, les shells, le programme init etc.) de ceux qui s'exécutent en espace noyau, avec les privilèges maximaux (les pilotes de périphérique, le code réseau, le gestionnaire de tâches etc.). Tous les programmes de l'espace utilisateur ont la même forme : sous Linux, on les appelle des processus. On peut en voir la liste à l'aide de la commande ps, ils ont chacun un espace mémoire distinct³, des intervalles de temps distincts dans le système du multitâche, des fichiers ouverts distincts, un répertoire courant distinct, des variables d'environnement distinctes. Le noyau, au contraire, est monolithique (les modules, que nous verrons au paragraphe suivant, se «fondent» dans la masse du noyau) ; le gestionnaire de réseau partage la même zone mémoire que le système de gestion des fichiers ou que le pilote du disque dur SCSI. Le noyau n'ouvre pas de fichiers (ce concept n'est qu'une abstraction à l'usage des processus), il lit et écrit des blocs de 512 octets sur un disque et c'est le seul à pouvoir le faire. Il ne connaît pas les utilisateurs par leur nom, mais par un numéro. Il «voit» le bus PCI, les intrerruptions, etc., alors que ces concepts n'ont pas de sens du point de vue des processus.

5.1.2 Appels système --- commande `strace`

Cette barrière assure les fonctions d'abstraction (un processus n'a pas besoin de tout savoir) et de sécurité (un processus ne peut pas tout faire). Mais évidemment, elle n'est pas totalement étanche : les processus ont tout de même le droit de faire et de savoir certaines choses ! Toutefois, pour ce faire, ils doivent en demander la permission au noyau. Pour cela, ils exécutent une séquence codifiée d'instructions assembleur⁴ qui avertit le noyau que le processus a besoin de lui. Le noyau exécute la requête codifiée (si la politique de sécurité le permet), inscrit les résultats soit dans la mémoire du processus, soit dans les registres du processeur et rend la main au processus, à l'instruction assembleur qui suit immédiatement celle qui a provoqué l'appel.

L'ensemble de l'opération se passe donc exactement comme un appel de fonction dans un langage de haut niveau, et c'est pourquoi ce mécanisme se nomme un appel système. Comme pour les appels de fonction dans une bibliothèque de programmation, le noyau offre un nombre fini d'appels système, chacun avec un certain nombre d'arguments dont le type est bien défini : en un mot, c'est une API. La documentation de cette API se trouve dans les pages de man du système Linux (section 2) ; Linux utilise pour son API noyau la norme de compatibilité POSIX, le standard IEEE que respectent la plupart des systèmes d'exploitation compatibles UNIX et qui définit un certain nombre d'appels système à supporter.

Passer un appel système représente essentiellement⁵ l'unique façon pour un processus de faire passer des données à travers la frontière utilisateur-noyau. Observer les appels système est donc une excellente façon de savoir ce que fabrique un processus ; c'est possible à l'aide de la commande strace.

execve("/bin/date", ["date"],[/* 34 vars */]) = 0

brk(0)                                  = 0x804e6b0

[...]

open("/etc/ld.so.cache", O_RDONLY)      = 4

fstat(4, {st_mode=S_IFREG|0644, st_size=17635, ...}) = 0

old_mmap(NULL, 17635, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40015000

close(4)                                = 0

open("/lib/libc.so.6", O_RDONLY)        = 4

fstat(4, {st_mode=S_IFREG|0755, st_size=4118299, ...}) = 0

read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\250\202"..., 4096) = 4096

old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000

[...]

close(4)                                = 0

[...]

personality(PER_LINUX)                  = 0

getpid()                                = 6595

brk(0)                                  = 0x804e6b0

brk(0x804e850)                          = 0x804e850

brk(0x804f000)                          = 0x804f000

open("/usr/share/locale/locale.alias", O_RDONLY) = 4

[...]

close(4)                                = 0

[...]

open("/usr/share/locale/fr_FR/LC_TIME", O_RDONLY) = 4

fstat(4, {st_mode=S_IFREG|0644, st_size=488, ...}) = 0

old_mmap(NULL, 488, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40017000

close(4)                                = 0

[...]

time([958575003])                       = 958575003

open("/etc/localtime", O_RDONLY)        = 4

read(4, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0"..., 44) = 44

[...]

close(4)                                = 0

[...]

write(1, "mer mai 17 16:50:03 CEST 2000\n", 30) = 30

close(1)                                = 0

munmap(0x40019000, 4096)                = 0

_exit(0)                                = ?

Table 1 : exemple de trace des appels système pour la commande date. La trace a été considérablement abrégée, comme le signalent les points de suspension.

strace peut être employé pour tracer un processus à lancer, dont on donne la ligne de commande (la trace de la figure 1 a été obtenue à l'aide de la commande strace date) ou bien un processus déjà existant (sous la forme strace -p <pid>). Chaque appel système possède une page de man du même nom, de sorte qu'il est facile de se référer à la documentation d'un appel système qu'on ne connaît pas. strace possède d'autres options intéressantes (consulter la page de man), en particulier on peut filtrer les appels système qu'il affiche : ainsi, strace -e trace=open depmod -a donne la liste de tous les fichiers qu'ouvre la commande depmod -a ! (cette commande sert à mettre à jour les dépendances entre les modules du noyau).

5.2 Les modules du noyau

Les modules du noyau sont des morceaux de code du noyau (par exemple, un gestionnaire de périphériques, ou bien un type de système de fichiers comme fat) qui ont été détachés du noyau monolithique pour être chargés et déchargés à volonté. L'utilité de ce système est d'abord la gestion de la mémoire : comme le noyau est à demeure en mémoire vive, il est souhaitable de décharger les morceaux qui ne servent à rien, sans quoi la mémoire est occupée en pure perte. Le système des modules permet également aux vendeurs de matériel de diffuser indépendamment leurs pilotes de périphérique, sous la forme d'un module.

Voici les commandes qui permettent d'administrer les modules :

Pour voir la liste des modules actuellement chargés dans le noyau, taper lsmod.
Pour enlever un module, taper rmmod <nommodule>. Le module doit être [unused] : chaque module a ses propres règles pour décider qui l'utilise (le plus souvent c'est un autre module, une interface réseau, un fichier spécial dans /dev etc. ceci évidemment en rapport avec la fonction du module).
Pour ajouter un module, taper insmod <chemin>. Les modules installés se trouvent dans l'arborescence /lib/modules/<version noyau>.
Pour ajouter un module en le recherchant et en installant éventuellement les modules dont il a lui-même besoin (empilement des modules), taper modprobe <nom>, ou <nom> est le nom du module (sans chemin d'accès et sans extension).
Pour régénérer la table des dépendances des empilements de modules, taper depmod -a.
Pour éditer les options de chargement des modules, lire la page de man de modprobe et modifier le fichier /etc/conf.modules.

Si /etc/conf.modules est correctement configuré, le noyau doit charger lui-même les modules dont il a besoin (il invoque modprobe lui-même). Un alias peut être nécessaire : en effet, quand le noyau a besoin d'initialiser l'interface réseau eth0 il va tenter de charger le module eth0, qui bien sûr n'existe pas. Il faut alors aliaser eth0 au vrai nom du module de la carte réseau (par exemple, 3c59x).

Pour savoir quels modules le noyau a demandé sans les obtenir, consulter les messages d'audit (chercher la chaîne de caractères modprobe). Un alias judicieux dans /etc/conf.modules résoudra alors le problème.

5.3 Configuration, recompilation et installation du noyau

Les sources du noyau Linux sont, bien entendu, libres. Il est donc possible de les recompiler, pour peu qu'on ait installé les outils de développement (non moins libres). Dans les distributions modernes, cette opération n'est plus que rarement indispensable, grâce à l'emploi des modules du noyau (voir le paragraphe 5.2). Mais elle est néanmoins utile : soit pour activer une fonctionalité « exotique » que le noyau standard de la distribution ne propose pas, soit pour réduire sa taille, soit pour le compiler avec les options d'optimisation spécifiques du processeur sur lequel il sera utilisé.

Pour recompiler le noyau, voici la marche à suivre :

Installer les sources du noyau, soit depuis le paquetage RPM, soit depuis l'Internet. Le répertoire suggéré pour ce faire est /usr/src/linux, mais tout autre répertoire convient également.
Aller dans le répertoire en question. Il contient, outre les sources proprement dites, un sous-répertoire Documentation qui contient de nombreux fichiers d'aide pour des pilotes de périphériques ou des fonctionalités particulières du noyau.
Taper make menuconfig ou make xconfig, selon que vous êtes dans une console texte ou en mode graphique. Le menu de configuration apparaît ; vous pouvez naviguer dedans pour configurer plus 300 options. Voici les points qu'il vous faut savoir :
- Lisez l'aide... Il y a un texte d'aide presque pour chaque option.
- Répondez y à la question «prompt for development and/or incomplete drivers» : les pilotes instables vous seront tout de même signalés par un marquage <NEW>, mais vous découvrirez ainsi toutes les possibilités du noyau !
- Répondez n à la question «set kernel version information on all symbols for modules». Des bogues peuvent se produire dans le système de contrôle de version des modules si on ne le fait pas.
- N'oubliez pas de laisser au moins le système de fichiers de la partition racine et le format de binaire ELF comme composants internes du noyau (c'est-à-dire pas en modules), sinon l'ordinateur ne démarrera pas en raison d'un problème d'oeuf et de poule !...
Après avoir sauvegardé et quitté, taper make dep && make bzImage && make modules pour, dans l'ordre, calculer les dépendances (l'ordre dans lequel les fichiers doivent être compilés), compiler le noyau, et compiler les modules. Si tout se passe bien, un fichier bzImage sera créé dans le sous-répertoire archi386boot (c'est le noyau en personne) et le sous-répertoire modules se remplira de liens symboliques pointant vers les modules.
Tapez make modules_install. Cette procédure installe les nouveaux modules.
Pour installee le nouveau noyau sur une disquette d'amorçage⁶ afin de le tester, insérez-la dans le lecteur de disquettes et tapez make bzdisk. Réamorcez l'ordinateur avec cette disquette dans le lecteur.
Si tout fonctionne normalement, vous pouvez remplacer l'ancien noyau (il se trouve dans /boot) par le nouveau, et relancer lilo pour mettre à jour le secteur d'amorçage du disque dur⁷ .

5.4 Les messages du noyau

Le noyau Linux en cours de fonctionnement émet divers messages de diagnostic, depuis les bannières d'installation des modules jusqu'aux erreurs réseau. Ces messages constituent une source précieuse d'informations pour l'administrateur système ; celui-ci peut les consulter dans les messages d'audit de /var/log, ou mieux, utiliser la commande dmesg qui affiche le contenu d'un tampon circulaire de messages du noyau d'une taille de 4096 octets. Comme le tampon est circulaire, ce sont toujours les 4096 derniers octets de messages que fournit cette commande.

1: Évidemment, elle-même est chargée par le noyau, ce qui peut facilement se vérifier à l'aide d'un éditeur binaire : tous les programmes utilisant les bibliothèques partagées contiennent le nom /lib/ld.so.2 tout en haut de leur en-tête ELF.
2: ici encore, cette règle nécessite une logique d'auto-contrôle codée en dur dans le silicium du processeur
3: ...par défaut. Deux processus volontaires peuvent décider de partager une certaine zone de mémoire, qui constitue alors un canal de communication très rapide entre eux.
4: Sous Linux et pour l'architecture i386 et compatibles, on fait un appel système en appelant l'interruption logicielle numéro 80 (INT 80h).
5: Une autre façon étant l'usage de la mémoire partagée, qui peut prendre plusieurs formes : grâce à l'appel système mmap il est possible de projeter en mémoire le contenu d'un fichier, de sorte que toutes les modifications de la zone mémoire sont répercutées dans le fichier. Il existe une troisième façon, assez marginale, qui est d'exécuter volontairement une instruction interdite.
6: Il convient de l'installer «brut», octet par octet, sans respecter aucun système de fichiers. Pour le faire à la main, la commande à utiliser pour ce faire serait dd.
7: Il est également possible de faire cohabiter les deux noyaux, et de choisir l'un ou l'autre au démarrage. Consultez la documentation de lilo.

Ce document a été traduit de L^AT_EX par H^EV^EA.