Guide d’installation et de configuration

de Linux

Christian Casteyde
Guide d’installation et de configuration de Linux
par Christian Casteyde

Copyright © 2004 Christian Casteyde

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any
later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU Free Documentation License".

Permission vous est donnée de copier, distribuer et modifier ce document selon les termes de la licence GNU pour les documentations libres,
version 1.1 ou toute autre version ultérieure publiée par la Free Software Foundation.
Une copie de cette licence est incluse dans l’annexe intitulée "Licence de Documentation Libre GNU".

Historique des versions

Version 2.6.3 30/08/2005 Revu par : CC
Utilisation d’entités pour les lettres ligaturées (e et a dans l’o). Passage au noyau [Link]. Mise à jour pour gcc 3.4.4, les binutils 2.16,
Version 2.6.2 19/03/2005 Revu par : CC
Passage au noyau [Link]. Passage à la glibc 2.3.4. Mise à jour pour gcc 3.4.3. Mise à jour pour [Link] 6.8.2 et Mesa 6.2.1. Mise à jour
Version 2.6.1 01/11/2004 Revu par : CC
Passage au noyau 2.6.9. Description des options de définition des pages de code et des jeux de caractères pour les systèmes de fichiers V
Version 2.6.0 15/05/2004 Revu par : CC
Passage au noyau 2.6.6. Description des pilotes ALSA et révision des sections décrivant le système des modules du noyau. Description
Version 2.4.1 14/06/2003 Revu par : CC
Corrections orthographiques. Mise à jour pour le noyau 2.4.21 et la glibc 2.3.2. Mise à jour pour gcc 3.2.3 et binutils 2.14. Mise à jour p
Version 2.4.0 30/11/2002 Revu par : CC
Corrections orthographiques. Mise à jour pour le noyau 2.4.20, glibc 2.3.1, binutils 2.13.1, gcc 3.2.1, XFree86 4.2.1, Qt 3.0.6, KDE 3.0
Version 2.2.1 26/01/2002 Revu par : CC
Mise à jour pour XFree86 4.2.0 et la Glibc 2.2.5. Mise à jour pour LessTiff 0.93.18.
Version 2.2.0 13/01/2002 Revu par : CC
Mises à jour diverses (noyau 2.4.17, Binutils 2.11.2, Glibc 2.2.4, Mesa 4.0.1, KDE 2.2.2, Qt 2.3.1, Samba 2.2.2). Description de la com
Version 2.0.2 28/04/2001 Revu par : CC
Corrections orthographiques. Configuration du protocole DHCP. Compléments sur la configuration de base du système. Mise à jour du
Version 2.0.1 04/04/2001 Revu par : CC
Ajout d’une traduction de la FDL en français. Corrections diverses. Mise à jour pour le noyau 2.4.3. Mise à jour pour la Glibc 2.2.2. Mi
Version 2.0.0 07/01/2001 Revu par : CC
Mise à jour pour le noyau 2.4.0. Mise à jour pour la Glibc 2.2. Mise à jour pour XFree86 4.0.2. Compilation des binutils. Compilation d
Version 1.0.32 02/11/2000 Revu par : CC
Passage au format de fichier SGML. Ajout des liens hypertextes. Gestion des connexions à la demande sur les liaisons PPP. Configurati
Version 0.31 09/09/2000 Revu par : CC
Mise à jour pour le noyau 2.2.17.
Version 0.30 09/07/2000 Revu par : CC
Changement du titre du document vers un titre plus générique permettant de traiter des sujets plus larges que ce que le titre originel ne p
Version 0.29 10/06/2000 Revu par : CC
Mise à jour pour le noyau 2.2.16. Corrections et modifications mineures.
Version 0.28 03/06/2000 Revu par : CC
Mise à jour pour le noyau 2.2.15. Mise à jour pour make 3.79.
Version 0.27 01/05/2000 Revu par : CC
Corrections orthographiques diverses.
Version 0.26 22/04/2000 Revu par : CC
Correction sur le bit sticky. Corrections mineures sur l’éditeur vi. Description des variables d’environnement. Achèvement du paragraph
Version 0.25 16/02/2000 Revu par : CC
Release partielle. Mise à jour pour le noyau 2.2.14 et XFree86 3.3.6. Ajout pour la compilation de ttmkfdir. Corrections sur la compilat
Version 0.24 29/01/2000 Revu par : CC
Modification et mise à jour de la licence. Mise à jour pour make 3.78.1. et la bibliothèque crypt 2.1.2. Ajout du paragraphe sur la config
Version 0.23 03/11/1999 Revu par : CC
Mise à jour pour gcc 2.95.2.
Version 0.22 01/11/1999 Revu par : CC
Ajout de l’historique des modifications. Ajout de la licence. Description des protocoles PAP et CHAP. Mise à jour pour le noyau 2.2.13
Version 0.21 08/10/1999 Revu par : CC
Corrections orthographiques.
Version 0.20 14/07/1999 Revu par : CC
Première version publique.
Table des matières
Remarques de l’auteur ...............................................................................................................................i
1. Introduction............................................................................................................................................1
2. GNU, Linux et les logiciels libres..........................................................................................................4
3. Concepts de base ....................................................................................................................................7
Architecture du système.....................................................................................................................7
Sécurité et utilisateurs ......................................................................................................................10
Fonctionnalités des systèmes de fichiers..........................................................................................14
Structure du système de fichiers.......................................................................................................18
4. Installation du système de base ..........................................................................................................26
Récupération des informations sur le matériel.................................................................................26
Sauvegarde des données...................................................................................................................28
Amorçage .........................................................................................................................................28
Partitionnement du disque................................................................................................................29
Notion de partition et d’amorçage du système .......................................................................29
Plan de partitionnement..........................................................................................................32
Trouver de la place pour installer le système .........................................................................35
Utilisation de parted......................................................................................................35
Utilisation de fips ..........................................................................................................38
Utilisation de fdisk .................................................................................................................39
Création des systèmes de fichiers.....................................................................................................40
Création de la partition de swap.......................................................................................................43
Installation des composants de base.................................................................................................44
Amorçage du système et configuration multiboot ...........................................................................46
Réalisation d’un multiboot avec LILO ...................................................................................46
Réalisation d’un multiboot avec le GRUB .............................................................................51
Réalisation d’un multiboot avec NTLDR...............................................................................54
5. Commandes Unix de base ...................................................................................................................56
Login et déconnexion.......................................................................................................................56
Arrêt et redémarrage du système .....................................................................................................57
Pages de manuel...............................................................................................................................58
Opérations de base sur les répertoires..............................................................................................60
Notions sur les chemins Unix ..........................................................................................................62
Opérations de base sur les fichiers ...................................................................................................64
Autres commandes utiles .................................................................................................................65
Gestion des liens.....................................................................................................................65
Recherche de fichiers..............................................................................................................66
Recherche d’un texte dans un fichier......................................................................................66
Remplacement de texte dans les fichiers ................................................................................67
Compression et décompression des fichiers ...........................................................................68
Archivage de fichiers ..............................................................................................................68
Passage en mode superviseur .................................................................................................69
Changement des droits des fichiers, du propriétaire et du groupe..........................................69
Changement de propriétaire et de groupe .....................................................................69
Modification des droits Unix sur les fichiers ................................................................70

iv
 Utilisation des ACLs.....................................................................................................71
vi, l’éditeur de fichiers de base.........................................................................................................73
Utilisation du shell bash ...................................................................................................................75
Contrôle des processus ...........................................................................................................76
Lancement d’un programme en arrière-plan.................................................................76
Listing des processus ....................................................................................................77
Notion de signal ............................................................................................................77
Arrêt d’un processus .....................................................................................................78
Gel d’un processus........................................................................................................79
Relancement d’un processus.........................................................................................79
Redirections............................................................................................................................79
Principe de base ............................................................................................................80
Redirections de données en entrée................................................................................80
Redirection de données en sortie ..................................................................................81
Insertion de documents .................................................................................................83
Les tubes.................................................................................................................................83
Syntaxe des tubes..........................................................................................................83
Les tubes nommés.........................................................................................................85
La commande tee ..........................................................................................................86
La commande xargs ......................................................................................................87
Manipulation des variables d’environnement.........................................................................87
Caractère d’échappement et chaînes de caractères.................................................................92
Les substitutions .....................................................................................................................94
Génération de chaînes de caractères selon un motif .....................................................94
Substitution du nom d’utilisateur..................................................................................94
Remplacements de variables.........................................................................................95
Substitution du résultat d’une commande.....................................................................97
Évaluation d’expressions arithmétiques........................................................................98
Substitution de commandes ..........................................................................................98
Découpage en mots .......................................................................................................99
Remplacement des caractères génériques...................................................................100
Les expressions rationnelles .................................................................................................100
Structures de contrôle ...........................................................................................................101
Les instructions composées.........................................................................................101
Les tests.......................................................................................................................103
Le branchement conditionnel......................................................................................106
Les boucles..................................................................................................................107
Les itérations...............................................................................................................108
Les ruptures de séquence ............................................................................................108
Les fonctions...............................................................................................................109
Les entrées / sorties de données ..................................................................................110
Les alias ................................................................................................................................111
Les scripts shell ....................................................................................................................112

v
6. Administration du système de base..................................................................................................114
Sauvegarde de la configuration d’installation ................................................................................114
Mise à l’heure du système..............................................................................................................115
Gestion des utilisateurs et de la sécurité ........................................................................................118
Mécanismes d’authentification des utilisateurs ....................................................................119
Création et suppression des utilisateurs................................................................................121
Description de la bibliothèque PAM ....................................................................................124
Gestion des paquetages ..................................................................................................................127
Le gestionnaire de paquetages rpm ......................................................................................127
Le gestionnaire de paquetages apt........................................................................................128
Le gestionnaire de paquetages pkgtool.................................................................................130
Notion de niveau d’exécution et amorçage du système .................................................................131
Maintenance des systèmes de fichiers............................................................................................133
Création des systèmes de fichiers .........................................................................................133
Montage des systèmes de fichiers.........................................................................................134
Démontage des systèmes de fichiers ....................................................................................136
Vérification des systèmes de fichiers....................................................................................137
Configuration du montage des systèmes de fichiers.............................................................140
Montage des systèmes de fichiers à la demande ..................................................................143
Gestion des volumes ......................................................................................................................146
Gestion des fichiers images ..................................................................................................146
Agrégation de volumes.........................................................................................................147
Chiffrement des systèmes de fichiers ...................................................................................149
Configuration des terminaux virtuels .............................................................................................150
Configuration de la console............................................................................................................153
Pages de codes et Unicode....................................................................................................153
Principe de fonctionnement du clavier .................................................................................154
Principe de fonctionnement de l’écran de la console ...........................................................157
Configuration du clavier .......................................................................................................159
Définition de scancodes ..............................................................................................159
Définition d’un plan de clavier ...................................................................................162
Modification des paramètres du clavier ......................................................................166
Choix de la police de caractères ...........................................................................................167
Configuration des paramètres du terminal............................................................................168
Description des terminaux....................................................................................................169
Paramétrage des applications................................................................................................173
Configuration du clavier pour la bibliothèque readline ..............................................173
Configuration du clavier pour vi .................................................................................174
Configuration du clavier pour less ..............................................................................177
Configuration de la souris.....................................................................................................179
Configuration de l’imprimante.......................................................................................................180
Concepts de base de l’impression sous Unix .......................................................................181
Le système d’impression LPRng..........................................................................................181
Le mécanisme des filtres APSFILTER .......................................................................182
Installation des filtres et configuration des files d’impression ....................................183
Commandes d’impression...........................................................................................184
Description du fichier /etc/printcap.............................................................................185
Le système d’impression CUPS ...........................................................................................186

vi
 Le mécanisme des filtres de CUPS .............................................................................186
Configuration d’une imprimante CUPS......................................................................187
Les fichiers de configuration de CUPS .......................................................................188
Configuration du lancement automatique des tâches .....................................................................190
Gestion de l’énergie .......................................................................................................................192
Généralités sur la gestion de l’énergie..................................................................................192
Configuration de la gestion de l’énergie...............................................................................193
Le démon ACPI ....................................................................................................................194
7. Notions de compilation et configuration du noyau .........................................................................197
Notions de base ..............................................................................................................................197
Définition des termes............................................................................................................197
Processus de génération........................................................................................................201
Compilation de GCC......................................................................................................................203
Prérequis ...............................................................................................................................204
Installation des sources.........................................................................................................205
Configuration........................................................................................................................205
Compilation ..........................................................................................................................206
Installation de GCC ..............................................................................................................206
Compilation du noyau Linux .........................................................................................................207
Installation des sources de Linux .........................................................................................207
Choix des options de configuration du noyau ......................................................................209
Compilation et installation du noyau....................................................................................210
Compilation et installation des modules...............................................................................212
8. Configuration du matériel et des périphériques .............................................................................213
Généralités sur le support matériel sous Linux ..............................................................................213
Notion de fichiers spéciaux de périphériques.......................................................................213
Modules du noyau ................................................................................................................214
Chargement et déchargement des modules.................................................................214
Options des modules ...................................................................................................215
Chargement automatique des modules .......................................................................216
Configuration des périphériques intégrés au noyau..............................................................219
Périphériques connectables à chaud .....................................................................................220
Agents hotplug ............................................................................................................220
Chargements des modules par hotplug .......................................................................221
Chargement des firmwares..........................................................................................222
Création automatique des fichiers spéciaux de périphériques..............................................223
Avantages d’udev ........................................................................................................223
Principe de fonctionnements de udev .........................................................................224
Persistance des fichiers spéciaux de périphériques.....................................................225
Initialisation du système .............................................................................................227
Configuration des périphériques de masse.....................................................................................228
Configuration des périphériques SCSI .................................................................................228
Configuration des disques durs IDE .....................................................................................229
Installation d’un graveur de CD/DVD..................................................................................231
Notions de base sur le gravage sous Linux .................................................................232
Configuration du noyau...............................................................................................232
Configuration des modules du noyau..........................................................................233

vii
 Installation des logiciels de gravage ...........................................................................234
Utilisation des logiciels de gravage ............................................................................234
Configuration des cartes filles ........................................................................................................238
Généralités sur les cartes ISA, Plug And Play et PCI ..........................................................238
Configuration des cartes son.................................................................................................242
Fonctionnalités du matériel.........................................................................................242
Configuration du noyau...............................................................................................242
Configuration des modules du noyau..........................................................................244
Ajustage des paramètres audio avec ALSA................................................................245
Fichiers MIDI et synthétiseurs logiciels .....................................................................247
Installation d’une carte graphique 3D ..................................................................................249
Installation d’une carte d’acquisition vidéo .........................................................................251
Configuration des cartes réseau ............................................................................................254
Configuration des adaptateurs Wifi ......................................................................................254
Configuration des ports de communication ...................................................................................258
Prise en charge des périphériques ISA standards .................................................................258
Configuration du port parallèle ...................................................................................258
Configuration des ports série ......................................................................................259
Installation des périphériques USB ......................................................................................261
Installation des périphériques IEEE1394 .............................................................................263
Configuration du noyau...............................................................................................263
Installation des bibliothèques complémentaires .........................................................264
9. Configuration du réseau....................................................................................................................266
Notions de réseau TCP/IP ..............................................................................................................266
Généralités sur les réseaux ...................................................................................................266
Le protocole IP .....................................................................................................................267
Le protocole TCP .................................................................................................................274
Les protocoles de haut niveau ..............................................................................................276
Configuration du réseau sous Linux...............................................................................................277
Configuration statique des interfaces réseau ........................................................................277
Définition des règles de routage ...........................................................................................279
Définition du nom de la machine..........................................................................................281
Résolution des noms de domaine .........................................................................................281
Utilisation des protocoles DHCP et BOOTP........................................................................283
Autoconfiguration des clients DHCP et BOOTP........................................................284
Configuration d’un client DHCP au niveau utilisateur ...............................................284
Définition des protocoles de haut niveau..............................................................................286
Les super-démons inetd et xinetd .........................................................................................287
Le super-démon inetd .................................................................................................288
Le super-démon xinetd ...............................................................................................289
Configuration de la connexion à Internet .......................................................................................294
Le protocole PPP ..................................................................................................................294
Création d’une connexion à Internet ....................................................................................295
Connexion à l’ADSL ............................................................................................................300
Les autres outils de connexion..............................................................................................303
Configuration d’un cache de DNS........................................................................................303
Installation d’un proxy HTTP ..............................................................................................306

viii
 Pare-feu et partages de connexion à Internet .................................................................................310
Mécanismes de filtrage du noyau .........................................................................................310
Translations d’adresses et masquerading .............................................................................312
Trajet des paquets dans le code de Netfilter .........................................................................314
Configuration du noyau et installation des outils .................................................................315
Utilisation d’iptables ............................................................................................................317
Manipulation des chaînes............................................................................................317
Manipulation des règles ..............................................................................................317
Exemple de règles.................................................................................................................319
Exemple de règles de filtrage ......................................................................................319
Exemple de partage de connexion à Internet ..............................................................322
Configuration des clients ......................................................................................................324
Configuration de la sécurité du réseau ...........................................................................................325
Limitation des services et des accès .....................................................................................326
Réduction du nombre des services..............................................................................326
Définition de règles de contrôle d’accès .....................................................................327
Restrictions d’accès avec tcpd...........................................................................327
Restrictions d’accès avec xinetd........................................................................328
Contrôle des utilisateurs au niveau des services .........................................................329
Chiffrement des communications.........................................................................................330
Principes de base de cryptographie.............................................................................331
Utilisation de SSH ......................................................................................................334
Principes de base de l’authentification SSH......................................................335
Compilation et installation d’OpentSSH...........................................................336
Configuration d’OpenSSH côté serveur ............................................................337
Utilisation d’OpenSSH côté client ....................................................................339
Création d’un tunnel SSH .................................................................................341
Utilisation d’IPSec ......................................................................................................342
Fonctionnement d’IPSec ...................................................................................342
Configuration manuelle d’IPSec en mode transport .........................................344
Configuration manuelle d’IPSec en mode tunnel..............................................346
Autoconfiguration avec ISAKMP .....................................................................348
Configuration des fonctions serveur...............................................................................................352
Paramétrage des connexions extérieures ..............................................................................352
Configuration des liaisons PPP.............................................................................................354
Liaison de deux ordinateurs par un câble série ....................................................................358
Configuration d’un serveur DHCP .......................................................................................359
Systèmes de fichiers en réseau .......................................................................................................360
Installation d’un serveur de fichiers NFS .............................................................................361
Configuration d’un client NFS .............................................................................................365
Installation d’un serveur de fichiers SMB ............................................................................366
Configuration d’un client SMB ............................................................................................374
10. Installation de XWindow.................................................................................................................378
Généralités sur XWindow ..............................................................................................................379
Configuration de [Link]...................................................................................................................382
Génération automatique du fichier [Link] .......................................................................383
Utilisation de xorgconfig ......................................................................................................383

ix
 Utilisation de xorgcfg ...........................................................................................................386
Configuration en mode graphique...............................................................................386
Configuration en mode texte.......................................................................................389
Description du fichier [Link]...........................................................................................391
Structure générale du fichier [Link].......................................................................391
Section « Files »..........................................................................................................393
Section « ServerFlags » ..............................................................................................394
Section « Module » .....................................................................................................394
Section « InputDevice »..............................................................................................395
Sections « Device ».....................................................................................................397
Sections « Monitor »...................................................................................................398
Sections « Modes » .....................................................................................................407
Sections « Screen » .....................................................................................................408
Sections « ServerLayout » ..........................................................................................409
Informations utilisées lors du démarrage de [Link]...............................................................411
Utilisation de xvidtune .........................................................................................................411
Utilisation du pilote frame buffer du noyau ...................................................................................412
Configuration du noyau et installation du pilote ..................................................................413
Configuration du serveur X ..................................................................................................414
Configuration des terminaux X ......................................................................................................415
Principe de fonctionnement de xdm .....................................................................................416
Configuration de xdm ...........................................................................................................416
Serveurs X locaux .......................................................................................................417
Serveurs X utilisant XDMCP......................................................................................418
Paramétrage du serveur X pour utiliser le protocole XDMCP ...................................421
Fichiers d’initialisation de sessions ............................................................................421
Paramétrage des terminaux X...............................................................................................422
La commande xset ......................................................................................................423
Configuration de la disposition du clavier ..................................................................424
Paramétrage des applications et ressources X................................................................................426
Gestion de la sécurité sous XWindow............................................................................................429
La commande xhost..............................................................................................................430
La commande xauth .............................................................................................................430
Gestion des polices de caractères...................................................................................................431
Gestion des polices de caractères sous XWindow................................................................432
Installation des polices Truetype ..........................................................................................434
Configuration du serveur X.........................................................................................435
Configuration des polices Truetype pour l’impression ...............................................436
Conversion des polices Truetype en polices Adobe de Type 42 .......................437
Installation des polices Truetype pour GhostScript ..........................................438
Configuration d’un serveur de polices..................................................................................438
Problèmes classiques rencontrés ....................................................................................................441
11. Conclusion ........................................................................................................................................443
A. Options de configuration du noyau .................................................................................................444
Menu « Code maturity level options » ...........................................................................................444
Menu « General setup » .................................................................................................................444
Sous-menu « Configure standard kernel features (for small systems) » ..............................446

x
Menu « Loadable module support » ..............................................................................................447
Menu « Processor type and features » ...........................................................................................447
Sous-menu « Firmware Drivers ».........................................................................................450
Menu « Power management options (ACPI, APM) »....................................................................450
Menu « Bus options (PCI, PCMCIA, EISA, MCA, ISA) »...........................................................452
Sous-menu « PCMCIA/CardBus support »..........................................................................453
Sous-menu « PCI Hotplug Support » ...................................................................................453
Menu « Executable file formats » ..................................................................................................453
Menu « Networking » ....................................................................................................................454
Menu « Networking options » ..............................................................................................454
Sous-menu « IP: Virtual Server Configuration » ........................................................459
Sous-menu « Network packet filtering (replace ipchains) » .......................................459
Sous-menu « IP: Netfilter Configuration »........................................................459
Sous-menu « IPv6: Netfilter Configuration »....................................................464
Sous-menu « DECnet: Netfilter Configuration » ..............................................465
Sous-menu « Bridge: Netfilter Configuration » ................................................465
Sous-menu « SCTP Configuration (EXPERIMENTAL) ».........................................465
Sous-menu « QoS and/or fair queueing » ...................................................................466
Sous-menu « Network testing »..................................................................................466
Menu « Amateur Radio support » ........................................................................................466
Sous-menu « AX.25 network device drivers » ...........................................................466
Menu « IrDA subsystem support ».......................................................................................466
Sous-menu « Infrared-port device drivers »................................................................467
Menu « Bluetooth support » .................................................................................................467
Sous-menu « Bluetooth device drivers » ....................................................................467
Device Drivers................................................................................................................................468
Menu « Generic Driver Options » ........................................................................................468
Menu « Memory Technology Devices (MTD) »..................................................................469
Menu « Parallel port support » .............................................................................................469
Menu « Plug and Play support »...........................................................................................470
Menu « Block devices » .......................................................................................................470
Menu « IO Schedulers » .............................................................................................473
Menu « ATA/ATAPI/MFM/RLL support » ..........................................................................473
Menu « SCSI device support » .............................................................................................476
Sous-menu « SCSI Transport Attributes »..................................................................477
Sous-menu « SCSI low-level drivers » .......................................................................477
Sous-menu « PCMCIA SCSI adapter support » .........................................................477
Menu « Old CD-ROM drivers (not SCSI, not IDE) » ..........................................................477
Menu « Multi-device support (RAID and LVM)..................................................................478
Menu « Fusion MPT device support » .................................................................................479
Menu « IEEE 1394 (FireWire) support (EXPERIMENTAL) » ...........................................479
Menu « I2O device support » ...............................................................................................480
Configuration des interfaces réseau......................................................................................481
Sous-menu « ARCnet devices » .................................................................................483
Sous-menu « Ethernet (10 or 100Mbit) » ...................................................................483
Sous-menu « Ethernet (1000 Mbit) »..........................................................................483
Sous-menu « Ethernet (10000 Mbit) »........................................................................484
Sous-menu « Token Ring devices (depends on LLC=y) » .........................................484

xi
 Sous-menu « Wireless LAN (non-hamradio) » ..........................................................484
Sous-menu « PCMCIA network device support »......................................................484
Sous-menu « Wan interfaces »....................................................................................484
Sous-menu « ATM drivers » .......................................................................................485
Menu « ISDN subsystem »...................................................................................................485
Ancienne interface ISDN4Linux ................................................................................486
Gestionnaires de périphériques ISDN4Linux ...................................................486
Interface CAPI ............................................................................................................486
Menu « Telephony Support » ...............................................................................................487
Menu « Input device support » .............................................................................................487
Sous-menu « Hardware I/O ports » ............................................................................488
Menu « Character devices » .................................................................................................489
Sous-menu « Serial drivers » ......................................................................................492
Sous-menu « IPMI » ...................................................................................................493
Sous-menu « Watchdog cards » ..................................................................................493
Sous-menu « Ftape, the floppy tape device driver » ...................................................493
Sous-menu « PCMCIA character device support » ....................................................494
Sous-menu « TPM Hardware support »......................................................................494
Sous-menu « I2C support » ..................................................................................................494
Sous-menu « Dallas’s 1-wire bus » ......................................................................................495
Sous-menu « Hardware Monitoring support » .....................................................................495
Sous-menu « Misc devices » ................................................................................................495
Menu « Multimedia devices » ..............................................................................................495
Sous-menu « Video For Linux » .................................................................................496
Sous-menu « Radio Adapters »...................................................................................496
Sous-menu « Digital Video Broadcasting Devices » ..................................................496
Menu « Graphics support » ..................................................................................................496
Menu « Sound »....................................................................................................................497
Menu « USB support » .........................................................................................................498
Menu « MMC/SD Card support ...........................................................................................501
Menu « InfiniBand support...................................................................................................501
Menu « SN Devices..............................................................................................................501
Menu « File systems » ...................................................................................................................501
Sous-menu « CDROM/DVD Filesystems » .........................................................................502
Sous-menu « DOS/FAT/NT Filesystems »...........................................................................503
Sous-menu « Pseudo filesystems ».......................................................................................503
Sous-menu « Miscelaneous filesystems » ............................................................................504
Sous-menu « Network File Systems »..................................................................................504
Sous-menu « Partition Types » .............................................................................................505
Sous-menu « Native Language Support » ............................................................................505
Menu « Profiling support » ............................................................................................................506
Menu « Kernel hacking » ...............................................................................................................506
Menu « Security options » .............................................................................................................508
Menu « Cryptographic options » ...................................................................................................509
Menu « Library routines » .............................................................................................................509

xii
B. Compilation et mise à jour des principaux composants du système ............................................510
Compilation de make 3.80.0 ..........................................................................................................510
Compilation des binutils 2.16.1 .....................................................................................................510
Compilation de la bibliothèque C 2.3.5 .........................................................................................511
Compilation de OpenSSL ..............................................................................................................515
Compilation de [Link] 6.8.2............................................................................................................515
Compilation de Lesstif 0.93.94 ......................................................................................................518
Compilation de MESA 6.2.1..........................................................................................................518
Compilation de KDE 3.4.2.............................................................................................................519
Compilation de Gnome 2.10.0 .......................................................................................................523
Compilation de Samba 3.0.11 ........................................................................................................528
C. Formulaire pour la création des lignes de mode de [Link] ............................................................530
D. GNU Free Documentation License..................................................................................................534
E. Licence de documentation libre GNU .............................................................................................539

xiii
Liste des tableaux
3-1. Caractéristiques des liens physiques et symboliques .........................................................................17
3-2. Hiérarchie standard du système de fichiers ........................................................................................20
5-1. Groupes de pages de man...................................................................................................................59
5-2. Principaux signaux Unix ....................................................................................................................78
5-3. Variables d’environnements courantes ...............................................................................................90
5-4. Tests sur les fichiers..........................................................................................................................105
9-1. Plages d’adresses IP réservées pour un usage personnel .................................................................270
10-1. Fréquence maximale des moniteurs ...............................................................................................403
10-2. Numéros des modes graphiques VESA..........................................................................................414

Liste des illustrations

3-1. Architecture des systèmes GNU/Linux................................................................................................9
3-2. Le système de fichiers virtuel.............................................................................................................15
4-1. Pistes et secteurs d’un disque dur.......................................................................................................30
4-2. Partitions primaires et partitions logiques ..........................................................................................31
4-3. Master boot record et secteurs de boot...............................................................................................32
6-1. Traitements des entrées clavier.........................................................................................................155
6-2. Traitement des caractères pour l’affichage .......................................................................................158
6-3. Filtres d’impression et imprimantes PostScript................................................................................182
6-4. Filtres d’impression et imprimantes PostScript................................................................................183
7-1. Interprétation d’un programme ........................................................................................................198
7-2. Compilation et exécution d’un programme......................................................................................199
7-3. Processus de génération d’un exécutable .........................................................................................200
8-1. Chargement automatique des modules du noyau .............................................................................217
8-2. Chargement des modules par hotplug ..............................................................................................221
8-3. Chargement des firmwares par hotplug............................................................................................222
8-4. Création des fichiers spéciaux de périphériques par udev................................................................225
9-1. Notion de paquet et d’adresse réseau ...............................................................................................266
9-2. Encapsulation de protocoles.............................................................................................................267
9-3. Addresse IP et adresse de réseau......................................................................................................269
9-4. Notion de passerelle .........................................................................................................................271
9-5. Notion de route.................................................................................................................................273
9-6. Connexions TCP...............................................................................................................................275
9-7. Translation d’adresses avec suivi de port TCP.................................................................................313
9-8. Trajet des paquets dans le code de filtrage .......................................................................................315
9-9. Algorithme de chiffrement symétrique ............................................................................................332
9-10. Algorithmes de chiffrement asymétriques......................................................................................333
10-1. Notion de display............................................................................................................................381
10-2. Structure du fichier [Link].........................................................................................................392
10-3. Paramètres des lignes de mode.......................................................................................................404

xiv
Remarques de l’auteur
Il se peut que certaines informations fournies dans ce document soient spécifiques à ma configuration . À
titre indicatif, j’utilise une Slackware 9.1. Il est connu que la Slackware n’utilise pas, par défaut, la
notion de niveaux d’exécution. En revanche, elle n’utilise que les versions officielles des logiciels, et sa
configuration reste simple et compréhensible. De plus, certaines informations pourront être spécifiques à
la configuration matérielle des machines que j’utilise. Je me suis cependant efforcé de rendre ce
document générique et indépendant de la Slackware et de mon matériel. J’espère donc que la plupart des
informations fournies ici s’appliqueront à toutes les distributions de Linux et à la plupart des
configurations matérielles, bien que je ne puisse pas le garantir. Les informations données dans ce livre
permettront donc sans doute aux personnes qui n’ont jamais vu Linux de débroussailler un peu le terrain,
et à celles qui utilisent déjà Linux de comprendre en profondeur comment leur système fonctionne.
Je remercie d’avance les gens qui pourront m’envoyer des remarques concernant les imprécisions, voire
les horreurs et les âneries que j’aurais pu écrire. Plus je recevrai de critiques constructives et de
propositions, plus ce document a de chances de s’améliorer. Cependant, si vous prenez le temps de
m’envoyer les remarques et les erreurs que vous avez pu détecter, je vous serais gré de vérifier au
préalable qu’elles sont toujours d’actualité dans la dernière version de ce document, que vous pourrez
trouver dans différents formats de fichiers sur mon site Web ([Link]
Vous pouvez contribuer au maintien et au support de mes documents libres sur la page de support de mon
site Web, à l’adresse [Link] Si vous estimez que ce travail
mérite salaire, n’hésitez pas, c’est facile et sécurisé.

i
Chapitre 1. Introduction
Linux est le noyau d’un système d’exploitation libre de type Unix, écrit initialement par Linus Torvalds
en 1991 et auquel un grand nombre de programmeurs ont contribué par Internet depuis. Les origines de
tous les systèmes Unix remontent à la première version d’un système d’exploitation expérimental
développé par Dennis Ritchie et Ken Thompson dans les laboratoires AT&T’s Bell Laboratories en 1969.
Ce système a avant tout été développé par des programmeurs, pour des programmeurs, et reprenait un
certain nombre de concepts qui avaient été développés auparavant pour le système d’exploitation Multics
(abréviation de « Multiplexed Information and Computing Service »), dont le rôle était de fournir des
services informatiques centralisés à un grand nombre de personnes (un peu comme le Minitel a tenté de
le faire par la suite). Multics n’a jamais réellement vu le jour, en revanche, le système Unix initial a
engendré un grand nombre d’autres systèmes plus ou moins compatibles. Récemment, les différents
fournisseurs de systèmes Unix se sont accordés pour définir l’ensemble des fonctionnalités que tous les
systèmes Unix doivent supporter, afin de résoudre les problèmes engendrés par les incompatibilités
existantes entre ces différents systèmes. Le terme Unix est donc un terme générique pour représenter
l’ensemble de tous ces systèmes, dont Linux fait partie. Pour l’anecdote, la dénomination Unix provient
de la contraction de « Unics » (abréviation de « Uniplexed Information and Computing Service »), terme
forgé ironiquement pour bien signaler qu’Unix était une version allégée de ce que Multics devait être.
Bien que compatible avec les dernières spécifications Unix, Linux ne contient pas une ligne du code
source du système Unix original, ce qui en fait ce que l’on appelle un « clone ». Cela dit, il s’agit
réellement d’un système Unix à part entière. En tant que tel, il dispose des fonctionnalités fournies par
les systèmes Unix : il est multitâche, multi-utilisateur et relativement orienté réseau. Vous aurez donc,
avec Linux, un système fiable, fonctionnel et performant.
Linux vous permettra de réaliser les opérations les plus classiques, comme effectuer un travail
bureautique, naviguer sur Internet, réaliser l’acquisition, la capture et le retraitement d’images, réaliser
des animations 3D ou encore programmer. En revanche, autant vous prévenir tout de suite : nombre de
jeux ne sont tout simplement pas disponibles sous Linux, bien que les principaux titres soient
régulièrement portés. De même, il n’existe pas de logiciel complet permettant de réaliser l’acquisition de
séquences vidéo et d’en réaliser le montage de manière aisée. Vous ne pourrez pas non plus réaliser ce
que vous faisiez avec les applications MS Windows dont il n’existe pas encore d’équivalent sous Linux,
comme les applications de gestion et de paie utilisées par nombre de professionnels indépendants ou par
des PME.
Que les choses soient claires : l’installation de Linux est une opération relativement compliquée, et
l’usage d’un système Unix en général n’est pas à la portée de tout le monde. Même si la qualité des
distributions actuellement disponibles s’est grandement accrue ces derniers temps, au point que
n’importe qui peut installer un système Linux viable sans trop de problèmes, la configuration du système
pour obtenir un fonctionnement correct exige un travail assez important. En particulier, les distributions
actuelles éprouvent encore quelques difficultés pour optimiser les périphériques exotiques, et souvent
seules les fonctionnalités de base sont correctement configurées après une installation classique. Par
ailleurs, la plupart des applications sont développées par des groupes de programmeurs indépendants, et
bien que ce soit justement le rôle des distributions de réaliser l’intégration de tous ces composants dans
un environnement homogène, celle-ci n’est pas forcément parfaite. Les outils de configuration des
distributions vous permettront sans doute de configurer votre système de base simplement, mais pour
aller au-delà, il faudra sans doute intervenir manuellement.
Néanmoins, il faut reconnaître que celui qui installe Linux à partir d’une distribution sur un ordinateur
assez vieux (c’est-à-dire un ordinateur qui ne dispose pas des derniers périphériques et cartes graphiques

1
 Chapitre 1. Introduction

à la mode), ou dont les constituants sont de marque courante, obtient rapidement un système fonctionnel
et capable de réaliser la plupart des opérations qu’il désire. En particulier, celui qui utilise son ordinateur
pour travailler (j’entends par là écrire des lettres, les imprimer, naviguer sur Internet pour récupérer des
informations, ou programmer) peut parfaitement se contenter de l’installation par défaut. Ce type de
situation ne convient pas à tout le monde : la plupart des gens disposent de cartes graphiques récentes
(surtout depuis l’avènement des jeux 3D) ou de périphériques spécifiques. Tout le monde ne se place pas
uniquement dans le cadre d’une utilisation professionnelle, et il est absurde de disposer d’une carte son
et de ne pas pouvoir l’utiliser. Et c’est là que le bât blesse ! Si l’on désire que Linux reconnaisse ces
matériels exotiques, il va falloir mettre les mains dans le cambouis et avoir une bonne dose de patience.
Ce problème de configuration apparaît malheureusement principalement pour les particuliers, qui
souvent disposent de machines hétéroclites et absolument non standards. Dans le cadre d’une entreprise,
il existe des personnes qualifiées pour résoudre ce type de problème, mais ce sont des informaticiens et,
de plus, les machines sont souvent homogènes, ce qui permet d’apporter des solutions génériques.
En conclusion, il faut être informaticien ou amateur très éclairé pour installer Linux sur une machine de
particulier et pour le configurer de manière optimale. La situation est d’autant plus grave que la plupart
des gens ne connaissent pas Linux, et qu’il est toujours difficile d’apprendre et de prendre de nouvelles
habitudes. Je veux dire par là que même une tâche très simple à réaliser peut prendre un certain temps,
car tout simplement on ne l’a jamais faite. Celui qui a installé trois fois MS Windows sait parfaitement le
faire à présent, et il pense que c’est relativement facile. Et pourtant, il réalise souvent des tâches d’une
complexité qui dépasse, là aussi, le commun des mortels.
Heureusement, et c’est là la force de Linux, ces opérations ne doivent être effectuées qu’une seule fois.
On n’a absolument pas besoin de changer la configuration à chaque instant, comme c’est le cas sous MS
Windows, parce que le système est globalement beaucoup plus stable. Il ne plante quasiment jamais, les
applications ne peuvent pas le corrompre, et sa qualité supprime le besoin permanent de mettre à jour
une partie du système. En clair, quand on en a un qui fonctionne, on le garde, non pas parce que c’est un
enfer à installer et à configurer, mais tout simplement parce que ce n’est pas nécessaire de le changer.
En résumé, on peut affirmer que :

• Linux est un système simple à installer sur des machines standards ;

• sa configuration sur une machine plus exotique requiert parfois une intervention manuelle ;
• dans la plupart des cas, cette intervention n’est pas très difficile à réaliser ;
• cependant, elle peut dérouter les personnes qui ne l’ont jamais effectuée ;
• mais le jeu en vaut la chandelle, parce que le système est réellement solide.

L’objet de ce document est de donner les connaissances de base nécessaires à l’installation de Linux sur
un ordinateur de particulier ou un petit serveur. Il est supposé que l’utilisateur a déjà utilisé un autre
système d’exploitation, par exemple MS Windows. Cependant, aucune notion avancée d’informatique
n’est nécessaire. Tout sera expliqué au fur et à mesure des besoins et, si nécessité est, des compléments
d’information seront donnés pour permettre la compréhension des opérations à effectuer. Néanmoins, les
notions qui seront abordées ici ne seront pas simples, et il est possible que la plupart des personnes qui
n’ont pas une grande habitude de l’informatique aient quelques difficultés à les assimiler. Cela dit, à
vaincre sans peine, on triomphe sans gloire, et l’installation de Linux vous procurera le plaisir
d’apprendre.

2
 Chapitre 1. Introduction

Ce document est structuré en neuf parties distinctes, qui correspondent essentiellement aux grandes
étapes que vous suivrez pour installer et utiliser Linux. La première partie a pour but de clarifier un peu
les notions ayant trait aux logiciels libres. Elle tente d’expliquer pourquoi ces logiciels existent, et
pourquoi ils font partie des meilleurs logiciels actuels. La deuxième partie décrit les concepts de base de
la plupart des systèmes d’exploitation Unix. Elle ne traite pas de l’installation à proprement parler, mais
sa lecture est recommandée pour tous ceux qui n’ont jamais vu un tel système. La troisième partie décrit
l’installation du système de base de Linux. À l’issue de cette partie, vous devez disposer d’un système
fonctionnel, utilisable mais non optimisé et ne permettant pas forcément d’utiliser tous vos
périphériques. La quatrième partie constitue un petit cours d’Unix pour les nouveaux utilisateurs de ce
type de système, et la cinquième partie traite des opérations d’administration et de maintenance de base
des systèmes Unix. Bien que, comme les deux premières parties, ces deux parties ne traitent pas de
l’installation à proprement parler, leur lecture est vivement recommandée. La sixième partie donne les
notions de base sur les mécanismes de compilation et décrit la manière de faire pour compiler la dernière
version de GCC, le compilateur C/C++ du projet GNU. Elle décrit également la technique à utiliser pour
compiler et installer un nouveau noyau dans le système, opération indispensable pour obtenir un noyau
optimisé qui « colle » à la machine. La configuration des différents types de matériel et leur prise en
charge au niveau du noyau sera décrite ensuite dans la septième partie. La huitième partie traite de la
configuration du réseau sous Linux. Le réseau est réellement l’un des aspects les plus importants de
Linux, et nécessite donc une attention toute particulière. Enfin, la neuvième et dernière partie vous décrit
la procédure d’installation de XWindow, l’environnement graphique de Linux. L’installation des polices
TrueType y est aussi présentée.

3
Chapitre 2. GNU, Linux et les logiciels libres
Vous entendrez souvent parler de la licence « GPL », du projet « GNU » et de la « Free Software
Foundation » dans le monde de Linux. Pour bien comprendre ce qu’est la Free Software Foundation et ce
que signifie la licence GPL, il est nécessaire d’en faire une brève présentation.
La Free Software Foundation est une organisation dont le but est de développer des logiciels libres. Le
terme de « libre » signifie clairement que chacun peut faire ce qu’il veut du logiciel, y compris le
modifier. La vente n’est absolument pas interdite, et il faut donc faire la distinction entre libre et gratuit.
Cela étant dit, les logiciels libres sont souvent de facto gratuits, car ils sont librement redistribuables par
quiconque en possède une copie.
La liberté de modifier les logiciels libres implique naturellement que leur code source, c’est à dire le
texte de leur programme tel qu’il a été saisi par ses auteurs, soit librement accessible et modifiable. Les
logiciels libres sont donc qualifiés de logiciels « Open Source », ce qui signifie en anglais que les sources
du programme sont disponibles. Attention cependant, tous les logiciels Open Source ne sont pas
forcément libres, car il n’est pas toujours possible de modifier ce code source et de le redistribuer
librement (éventuellement gratuitement). Ainsi, nombre d’éditeurs de logiciels propriétaires publient leur
code source sans pour autant donner de droits supplémentaires à ceux qui les lisent. Certains d’entre eux
jouent d’ailleurs explicitement sur cette confusion. De plus, la plupart des journalistes anglo-saxons font
cette confusion et, de ce fait, occultent tous les avantages des logiciels libres. Vous trouverez de plus
amples informations sur la notion de code source dans le Chapitre 7.
Il faut bien comprendre que le fait de diffuser un logiciel sous une licence libre ne prive absolument pas
son auteur de ses droits. Il en reste l’auteur et, en tant que tel, conserve les droits d’auteurs sur son
travail. Il ne fait que concéder la liberté d’exploiter ce travail aux autres. C’est en cela que les logiciels
libres se démarquent du domaine publique, dont les logiciels ne sont plus soumis à aucun droit.
Afin de protéger les logiciels libres et leurs auteurs, la Free Software Foundation a rédigé la licence GPL
(abréviation de l’anglais « General Public License »). Cette licence stipule que le logiciel libre peut être
redistribué, utilisé, modifié librement, pourvu que celui qui en bénéficie accorde les mêmes droits à ceux
à qui il fournit les copies du logiciel, qu’il l’ait modifié ou non. En d’autre termes, elle garantit que la
liberté des uns s’arrête là où commence celle des autres. Cette licence empêche donc l’aliénation du
logiciel et sa transformation en logiciel propriétaire, de quelque manière que ce soit. Cela implique que
tout logiciel libre sous licence GPL modifié par une autre personne que son auteur reste libre, et le
restera à jamais. Ainsi, il est impossible qu’une société commerciale puisse un jour s’approprier un
logiciel libre, même si elle l’améliore. Si vous désirez lire la licence GPL, vous pouvez en trouver une
copie dans le fichier /usr/src/linux/COPYING une fois que vous aurez installé Linux. La FSF a
également rédigé d’autres licences plus adaptées aux bibliothèques de programmes et aux
documentations libres. Ainsi, la licence LGPL (« Lesser General Public License ») permet d’utiliser les
bibliothèques de programmes dans des programmes propriétaires, et la licence FDL (« Free
Documentation License ») permet de diffuser des documentations libres. À titre d’exemple, ce guide est
distribué sous licence FDL, dont vous trouverez une tradution française en annexe.
La licence GPL a été écrite initialement pour le projet GNU de la Free Software Foundation, dont le but
est de réaliser un système Unix libre et indépendant des Unix commerciaux. Précisons ici que le terme
« Unix » caractérise un ensemble de systèmes d’exploitation, qui disposent tous à peu près des mêmes
fonctionnalités et proposent d’y accéder de la même manière. Le projet GNU est toujours en cours,
puisque la Free Software Foundation a déjà écrit la plupart des utilitaires Unix, mais que le cœur du
système (ce que l’on appelle le noyau) est toujours en cours de réalisation. Pour information, ce noyau se

4
 Chapitre 2. GNU, Linux et les logiciels libres

nomme « Hurd ».
Cependant, d’autres noyaux sont disponibles, avec lesquels les commandes GNU peuvent être utilisées.
Parmi ces noyaux, il existe bien entendu Linux, qui a été écrit par le Finlandais Linus Torvalds lorsqu’il
était étudiant, et amélioré par des programmeurs du monde entier sur Internet. Linux est un noyau parmi
tant d’autres, à ceci près qu’il est, lui aussi, distribué sous la licence GPL, bien que n’ayant rien avoir
avec la Free Software Foundation.
Cela signifie qu’il serait en fait plus exact de parler du système « GNU/Linux » que de « Linux » tout
court. Sous cette dénomination, il est clair que ce système est constitué des outils GNU fonctionnant sur
le noyau Linux. C’est donc un ensemble de logiciels libres provenant de plusieurs sources distinctes.
Cependant, il est très courant d’entendre parler de « Linux » tout court, par abus de langage et par souci
de simplicité. Bien entendu, cette dénomination est proscrite sur les sites Internet de la Free Software
Foundation, qui devient très susceptible à ce sujet.
Précisons que la licence GPL n’est pas la seule licence permettant de distribuer des logiciels libres. Il
existe d’autres licences, dont les termes sont à peu près similaires. Par exemple, la licence BSD (un autre
système Unix libre) exige également la distribution des sources, mais permet l’appropriation des sources
par des sociétés commerciales. De même, la licence X, sous laquelle est diffusée l’environnement
graphique X11 qu’utilise Linux, est une licence libre. Quelques outils fournis avec Linux sont distribués
avec d’autres licences plus rares.
Les logiciels libres disposent d’avantages indéniables par rapport aux logiciels « propriétaires » ou
« fermés ». Je vais tenter de donner ici une liste non exhaustive de ces avantages :

• les programmes distribués sous licence libre ont souvent été écrits par des passionnés du domaine
applicatif auquel ils appartiennent. Les logiciels libres disposent donc souvent des dernières
fonctionnalités à la mode et sont donc généralement extrêmement compétitifs sur ce plan ;
• du fait du grand nombre possible d’intervenants sur les sources des logiciels libres, un grand nombre
de possibilités techniques peuvent être explorées, et c’est souvent la meilleure qui est sélectionnée.
C’est une forme de sélection naturelle de la meilleure solution. Ainsi, sur le long terme, les logiciels
libres sont les plus efficaces en terme de performances ;
• toujours du fait du grand nombre d’intervenants, et surtout de par la possibilité de consulter et de
modifier librement le code source, le cycle de détection/identification/correction des bogues est très
court. Les logiciels libres sont donc parmi les plus fiables qui se font. On peut considérer qu’un
logiciel libre utilisé par un grand nombre de personnes est virtuellement « sans bogue » connu,
puisque si tel était le cas il serait immédiatement corrigé ;
• la possibilité de repartir d’une base de source existante permet de réaliser des développements
beaucoup plus rapidement que dans un modèle fermé. Les logiciels libres sont donc également ceux
qui se développent le plus rapidement à coût fixe, et sont certainement les plus rentables en terme de
coût global pour la collectivité ;
• afin de garantir l’interopérabilité entre les différents intervenants du monde du logiciel libre, chacun
s’évertue à respecter les standards. Les logiciels libres sont donc les plus ouverts, non seulement en
terme de code source, mais également au niveau des formats de fichiers et des protocoles de
communication. Cela garantie une interopérabilité optimale et l’absence de mauvaise surprise ;
• professionnellement parlant, la disponibilité du code source fournit une garantie de fonctionnement
que l’on ne peut pas retrouver ailleurs. En cas de problème, il est toujours possible de s’en sortir,
éventuellement en recourant à des compétences externes pour adapter le logiciel à ses propres besoins ;

5
 Chapitre 2. GNU, Linux et les logiciels libres

• enfin, la disponibilité du code source garantit une pérennité absolue du logiciel, ce qu’aucune société
commerciale vendant des logiciels propriétaires ne peut ou ne veut faire.

Mais l’aspect le plus important des logiciels libres est sans doute le fait qu’ils garantissent la liberté des
utilisateurs par rapport aux éditeurs de logiciels. Le respect des standards, l’ouverture des formats de
documents et des protocoles de communication garantissent une interopérabilité absolue, qui permet
ainsi à chacun de rester libre de ses choix pour sa solution informatique. Il n’est que trop courant de voir
les éditeurs de logiciels enfermer leurs clients dans une dépendance vis à vis d’eux, simplement en leur
faisant utiliser des produits fermés et inutilisables sans leur concours. Le pire est sans doute que cette
dépendance est transitive (le fait pour un auteur d’utiliser un produit implique que ses lecteurs le
possèdent également) et durable (on ne peut faire de mise à jour que chez le même éditeur de logiciel).
Bien que cela ne se situe pas au même niveau philosophique, la question du financement se pose
également de manière récurrente. Il n’est en effet pas évident, en première analyse, de déterminer les
raisons qui poussent un auteur ou une entreprise à rendre ainsi public son savoir faire, au risque de se le
faire tout simplement voler. Les particuliers font souvent cela par amusement ou pour faire valoir leur
savoir-faire. Les entreprises quant à elles peuvent financer le développement de certains logiciels libres
soit parce qu’elles l’utilisent en interne, soit parce qu’elles en vivent de manière dérivée (par vente de
produits dérivés ou de services complémentaires par exemple). Certaines sociétés préfèrent également
repartir d’un logiciel libre qui satisfait à 80% de leurs besoins, et de développer les 20% restants. Le coût
total de développement d’une solution complètement propriétaire serait en effet beaucoup plus élevé.
Dans ce cas, les développeurs de logiciels libres sont avant tout leurs propres utilisateurs... Cela dit, il
faut être clair à ce sujet : le logiciel libre rapporte moins que le logiciel propriétaire, tout simplement
parce qu’on ne peut pas pressurer le client de la même manière.
Enfin, pour information, le terme « GNU » est l’abréviation de l’anglais « GNU’s Not Unix ». Cette
curieuse phrase rappelle que le projet GNU est de réaliser un système Unix différent des autres. Vous
remarquerez que cette définition est récursive, c’est-à-dire qu’elle utilise le mot « GNU » elle-même.
Cela doit être attribué au goût des développeurs de la Free Software Foundation pour ce genre de
définition infiniment récursive. Vous ne saurez sans doute jamais les raisons qui les ont poussés à choisir
la lettre ’G’ dans leur définition. Cela étant, « GNU » se prononce « gnou » en anglais, et vous trouverez
donc souvent la représentation d’un gnou sur les sites Internet de GNU.

6
Chapitre 3. Concepts de base
Ce chapitre décrit les principes de base qu’il faut connaître pour bien comprendre Linux. Les
informations qui sont données ici ne sont pas réellement spécifiques à Linux. Elles s’appliquent souvent
aux systèmes Unix en général. Il est donc recommandé de lire ce chapitre, surtout si l’on n’a jamais vu ni
utilisé un système Unix. En particulier, les utilisateurs chevronnés de Windows risquent d’être
légèrement déroutés. L’architecture du système sera présentée, ainsi que la sécurité et la notion
d’utilisateur. Viendront ensuite les descriptions des principales fonctionnalités du système de fichiers et
de sa structure.

Architecture du système
Comme tout logiciel d’une certaine taille, Linux est d’une grande complexité. Tous les systèmes
d’exploitation récents sont constitués d’un grand ensemble de composants qui interagissent et dont la
mise en place peut être soit indispensable au bon fonctionnement du système, soit facultative, soit tout
simplement inutile étant donnés la configuration matérielle et les besoins de l’utilisateur. Cette
complexité implique un grand nombre d’erreurs, d’anomalies et de dysfonctionnements possibles. 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. Cela n’est pas humainement réalisable quand le
système devient trop complexe.
Pour résoudre ce problème, il est courant de subdiviser le système en composants indépendants, dont le
mauvais fonctionnement potentiel ne peut perturber que partiellement les autres parties du système. Des
points de synchronisation à partir desquels le système peut reprendre un fonctionnement normal après
une erreur sont prévus. Ces points de synchronisation permettent simplement d’assurer la viabilité du
système, même en cas d’erreur inopinée. Pour quelques systèmes, le seul point de synchronisation est le
point de départ, à savoir le démarrage de l’ordinateur. De tels systèmes doivent donc souvent être
redémarrés, parfois pour une cause mineure (erreur d’un logiciel, modification de la configuration du
système, ajout d’un composant au système). Ce n’est pas le cas de Linux, qui dans le pire des cas détruit
le composant qui a généré l’erreur sans toucher aux autres parties du système. Le point de
synchronisation de Linux est donc le redémarrage d’une partie du système uniquement, ce qui assure
ainsi une grande stabilité du système complet.
Il va de soi que, lorsqu’un composant se plante, ceux qui l’utilisent risquent fort 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. Or il est un composant à la base de tout dans Linux : le
noyau (« kernel » en anglais). C’est le cœur du système, et en fait c’est précisément le système Linux.
Heureusement, ce composant 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 fiabilité provient du modèle de
développement de Linux, qui est ouvert à tout le monde (chacun peut récupérer, lire, modifier, compléter
ou corriger le noyau à condition de savoir bien programmer). À 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. Ainsi, dès qu’une erreur est détectée, elle est souvent corrigée dans les jours qui
suivent, ce qui assure une grande qualité.
Le noyau gère quasiment tout (mémoire, disques, systèmes de fichiers, réseau, clavier, droits des
utilisateurs, etc.), mais il n’est pas exploitable tel quel. Il n’est par exemple pas capable d’offrir une
interface utilisateur permettant de lui donner les commandes qu’il doit exécuter. Ces opérations sont du

7
 Chapitre 3. Concepts de base

ressort d’autres modules développés par la Free Software Foundation. Parmi ces modules, on trouve 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.).
En fait, les commandes que le shell peut exécuter sont en nombre très réduit. La plupart des commandes
sont tout simplement d’autres programmes. Les programmes que l’on peut utiliser dans le shell sont des
programmes dits « 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 GNU. Toutes ces
commandes sont des commandes compatibles Unix. 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 (mais cependant légèrement moins puissante en termes de fonctionnalités) : 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 (comme tout le reste) : [Link]. À 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 le composant qui se place juste
au-dessus du serveur X. Il est en charge, comme son nom l’indique, de gérer les 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 des environnements graphiques complets qui, en plus d’un gestionnaire de fenêtres souvent
extrêmement puissant, 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édia... 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 à des programmes non graphiques existants. Ce concept permet d’avoir un composant
unique, et plusieurs interfaces différentes pour ce composant, et en plus de rendre indépendante la
fonctionnalité de l’interface utilisateur. Encore une fois, la stabilité en est d’autant plus accrue.

8
 Chapitre 3. Concepts de base

Bon nombre d’applications pour XWindow sont libres, ou utilisables librement à des fins non
commerciales. Cela signifie qu’un particulier a le droit de les utiliser tant qu’il ne s’en sert pas pour un
travail qu’il revendra. Comme c’est le cas de la plupart des particuliers, on peut considérer qu’il est
actuellement possible, avec Linux, d’avoir un environnement logiciel complet, fiable et performant...
pour un prix de revient minime.
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.

Figure 3-1. Architecture des systèmes GNU/Linux

Il n’est pas évident d’établir un parallèle avec MS Windows, puisque ce système est réellement
monolithique. Cependant, on peut considérer que le noyau Linux correspond aux modules KERNEL ou
[Link] de Windows, que le shell correspond aux interpréteurs de commandes [Link] ou
[Link], que les programmes en ligne de commande correspondent aux programmes DOS ou console
classiques (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 le gestionnaire de bureau à
l’explorateur, les fonctionnalités d’OLE et aux programmes fournis avec Windows. La différence
essentielle vient du fait que le shell est à peine programmable sous Windows, que les commandes DOS
ont tendance à accéder aux ressources de la machine directement sans passer par le noyau, 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 conclusion :

9
 Chapitre 3. Concepts de base

• les systèmes Unix, donc Linux, sont très structurés, 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 ;
• et il n’est pas propriétaire, c’est-à-dire que l’on n’est pas dépendant d’une société éditrice de logiciel
pour résoudre un problème donné.
En bref, c’est la voie de la vérité.

Sécurité et utilisateurs
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. Les ressources de la machine sont ainsi partagées équitablement, tant au
niveau de la puissance de calcul qu’au niveau de la mémoire, du disque, des imprimantes...
Évidemment, une question se pose : comment plusieurs utilisateurs peuvent-ils se partager le clavier et
l’écran ? La réponse est simple : ils ne le peuvent pas. Par conséquent, il n’y a que trois solutions
possibles : soit on connecte à l’ordinateur d’autres claviers et d’autres écrans (on appelle un couple
clavier/écran un « terminal »), soit on accède au système par l’intermédiaire d’un autre ordinateur via le
réseau, soit les utilisateurs lancent tour à tour leurs programmes. La dernière solution nécessite que les
programmes ne soient pas interactifs : ils doivent être capable de fonctionner sans intervention de celui
qui les a lancés.
La première hypothèse n’est pas sérieuse pour un particulier, il est d’ailleurs assez difficile de connecter
un terminal supplémentaire sur un PC (c’est réalisable, soit en connectant un terminal dédié à l’un des
ports série, soit en ajoutant une carte graphique PCI et en connectant un deuxième clavier et une
deuxième souris, par exemple sur le port USB, et en utilisant une version modifiée de [Link]. Ce n’est
donc pas une opération à la portée du commun des mortels.). La deuxième solution, en revanche, est
nettement plus envisageable. Il est parfaitement possible qu’un particulier dispose de deux PC connectés
en réseau, et que deux membres de la même famille cherchent à utiliser des ressources de la même
machine (par exemple, une imprimante ou tout autre périphérique, un programme installé sur un seul
ordinateur, des fichiers personnels, etc.). Quant à la troisième solution, elle est du domaine du quotidien,
même pour un ordinateur sans réseau et avec un seul utilisateur. En effet, certains programmes sont
lancés par le système pour effectuer des tâches de maintenance, et fonctionnent au nom de
l’administrateur de la machine.
Il va de soi que pour être multi-utilisateur, le système doit satisfaire certains critères :

• il doit être multitâche, c’est-à-dire qu’il doit être capable de faire fonctionner plusieurs programmes
simultanément sur la même machine, en partageant les ressources de celle-ci ;
• il doit être fiable, car un arrêt du système peut déranger un nombre arbitraire de personnes, y compris
celles qui ne sont pas à proximité de l’ordinateur ;

10
 Chapitre 3. Concepts de base

• il doit être sûr, car il ne faut pas que les erreurs ou les malveillances d’un utilisateur ne puissent
déranger les autres.

Le multitâche est assuré au niveau du noyau. Chaque programme en cours d’exécution (on les appelle
« processus ») fonctionne dans sa propre zone de mémoire, qui est complètement contrôlée par le noyau.
Les ressources du processeur sont partagées entre les processus, et il est impossible à l’un d’entre eux de
monopoliser la mémoire, le disque ou quoi que ce soit. Les processus doivent toujours passer par le
noyau pour effectuer une opération, ce qui permet un contrôle absolu.
La fiabilité est également assurée au niveau du noyau. Les zones de mémoire utilisées par chaque
processus (encore appelées « espaces d’adressage ») sont bien distinctes et bien identifiées par le noyau.
Cela implique qu’il est impossible à un processus de perturber le fonctionnement d’un autre processus.
Ainsi, si un processus fait une faute, il est purement et simplement terminé par le noyau. Cela est sans
appel : le noyau est le seul maître à bord.
Enfin, la sécurité est assurée par le noyau et par le système de fichiers. Au niveau du noyau, chaque
utilisateur est identifié de manière unique par un numéro dans le système. Ce numéro est utilisé pour
vérifier les droits de l’utilisateur, ou, autrement dit, ce qu’il peut faire. Les droits des utilisateurs
comprennent la possibilité de lire ou écrire un fichier, d’accéder ou non à une ressource ou d’exécuter un
programme. Il est également possible de créer un ou plusieurs « groupes » d’utilisateurs, et de donner
des droits particuliers à ces groupes. Tous les utilisateurs qui font partie de ce groupe recevront les droits
du groupe. Ainsi, des classes d’utilisateurs peuvent être facilement définies, et ces classes peuvent se voir
attribuer un peu plus de privilèges que les utilisateurs normaux selon les nécessités. Il existe toutefois un
utilisateur spécial, qui a tous les droits : l’administrateur du système (« root » en anglais). Aucune
restriction ne s’applique à cet utilisateur, car il doit être capable de gérer le système, l’installer, l’arrêter,
le mettre à jour si nécessaire, et de définir les utilisateurs et leurs droits.
Au niveau du système de fichiers, la sécurité est assurée par le stockage d’informations additionnelles
pour chaque fichier ou répertoire. Ces informations permettent de connaître :

• le numéro de l’utilisateur qui possède le fichier ou le répertoire. En général, le propriétaire est

simplement celui qui l’a créé. Cependant, l’administrateur peut changer le propriétaire d’un fichier à
tout moment ;
• le numéro du groupe auquel appartient le fichier ou le répertoire. Tout fichier ou répertoire appartient à
un groupe unique, qui est utilisé pour calculer les droits des utilisateurs faisant partie de ce groupe. Par
défaut, un fichier nouvellement créé par un utilisateur appartient au groupe des utilisateurs « users »,
ce qui convient dans la majorité des cas (attention, ce comportement varie selon les systèmes).
L’utilisateur peut toutefois donner ses fichiers à n’importe quel groupe dont il fait partie ;
• les droits d’accès au fichier ou au répertoire. Ces droits comprennent le droit de lecture (représenté par
la lettre ’r’, pour « Read only »), le droit d’écriture (représenté par la lettre ’w’, pour « Writeable »), le
droit d’exécution (représenté par la lettre ’x’, pour « eXecutable ») et quelques attributs
supplémentaires (qui seront détaillés plus loin). pour

Il n’est sans doute pas inutile de préciser un peu le fonctionnement des droits dans le système de fichiers.
Le droit de lecture correspond à la possibilité d’ouvrir et de consulter un fichier, ou de lister le contenu
d’un répertoire. Le droit d’écriture correspond à la possibilité de modifier un fichier, ou de créer ou
supprimer un fichier d’un répertoire. Enfin, le droit d’exécution correspond à la possibilité d’exécuter un

11
 Chapitre 3. Concepts de base

fichier contenant un programme, ou d’entrer dans un répertoire. On notera par exemple qu’il est possible
d’obtenir la liste des fichiers d’un répertoire sans pouvoir s’y déplacer, ou encore de modifier un fichier
sans pouvoir le lire. On prendra garde également que le fait d’avoir le droit d’écriture sur un fichier ne
donne pas le droit de le supprimer (cependant, on peut le vider !). Pour cela, il faut avoir le droit
d’écriture sur le répertoire contenant ce fichier. Comme on le voit, les droits d’accès aux fichiers et aux
répertoires sont très souples.
Ces droits sont attribués séparément pour le propriétaire, le groupe et les autres utilisateurs (c’est-à-dire
les utilisateurs qui ne font pas partie du groupe auquel appartient le fichier). Il est donc possible de
donner par exemple tous les droits au propriétaire d’un fichier, et seulement le droit de lecture aux autres
utilisateurs. Cette configuration est celle qui est choisie par défaut lors de la création d’un fichier, elle
assure que seul le propriétaire peut modifier ou exécuter ce fichier, tout en laissant la possibilité aux
autres de le lire. Ce choix privilégie la sécurité des données de chacun en laissant le maximum de liberté
aux autres.
Si plusieurs personnes doivent travailler sur les mêmes fichiers, il existe deux techniques
complémentaires. La première, qui est la solution classique sous Unix, est de regrouper ces personnes
dans un groupe, d’affecter les fichiers sur lesquels ils doivent travailler à ce groupe, et de donner les
droits d’écriture aux membres de ce groupe sur ces fichiers. Cette solution elle toutefois relativement
contraignante, car elle nécessite la création d’un groupe par l’administrateur d’une part, et n’est pas très
souple quand des droits différents sur un même fichier doivent être attribués à plusieurs groupes
d’utilisateurs d’autre part. Il existe donc une deuxième possibilité, basée sur la notion d’ACL
(abréviation de l’anglais « Access Control List », liste d’informations décrivant les droits d’accès aux
fichiers). Grâce aux ACLs, il est possible de définir des droits de manière plus fine, fichier par fichier,
pour des utilisateurs et des groupes variés. De plus, les ACLs peuvent être manipulées par le propriétaire
du fichier, sans avoir recours aux droits administrateur. En contrepartie de cette facilité, il n’est pas
toujours évident de contrôler la sécurité de manière globale avec les ACLs, puisqu’on ne peut plus retirer
les droits d’un utilisateur sur tout un jeu de fichiers appartenant à un même groupe simplement en le
supprimant de la liste des utilisateurs de ce groupe.
La sécurité du système est transitive, cela signifie que tout programme lancé par un utilisateur s’exécute
en son nom et reçoit donc les droits de cet utilisateur. Le processus correspondant se voit donc attribuer
les mêmes restrictions que l’utilisateur qui l’a lancé. Il dispose également des droits du groupe auquel le
fichier du programme appartient. Il existe toutefois quelques exceptions à cette règle, pour les
programmes dont le comportement est bien connu et qu’il est impossible de détourner de leur fonction
initiale. C’est notamment le cas de quelques commandes systèmes (comme passwd, qui permet de
changer de mot de passe), qui peuvent être lancées par les utilisateurs et qui s’exécutent toutefois au nom
du système (dans le compte root). Il est donc impossible à un utilisateur de violer les règles de sécurité
du système. Pour parvenir à ce comportement, il faut utiliser des attributs spéciaux sur les fichiers de ces
programmes. Les attributs spéciaux sont décrits ci-dessous.
Le premier attribut spécial est le bit « setuid » (qui est l’abréviation de l’anglais « SET User IDentifier »).
Il ne peut être placé qu’au niveau des droits du propriétaire sur le fichier. Il permet d’indiquer que le
fichier est exécutable, et que lorsque le programme qu’il contient est lancé par un utilisateur, le processus
correspondant s’exécute avec les droits du propriétaire du fichier et non pas avec ceux de l’utilisateur qui
l’a lancé. Cependant, le système conserve tout de même le numéro de l’utilisateur réel qui a lancé le
processus, ce qui fait que le programme peut savoir par qui il a été lancé et au nom de qui il s’exécute.
Un processus dispose donc toujours de deux numéros d’utilisateur :

• le numéro de l’utilisateur réel (« real user id » en anglais), qui est le numéro de l’utilisateur qui a lancé

12
 Chapitre 3. Concepts de base

le programme ;
• le numéro de l’utilisateur effectif (« effective user id » en anglais), qui est le numéro de l’utilisateur
avec les droits duquel le processus fonctionne.

Le bit setuid permet donc simplement d’affecter le numéro du propriétaire du fichier au numéro
d’utilisateur effectif du processus lorsqu’il est lancé. Le fait de conserver le numéro de l’utilisateur réel
permet au programme de réaliser des vérifications de sécurité additionnelles. Par exemple, la commande
passwd, qui permet de changer le mot de passe d’un utilisateur, a besoin des droits de l’utilisateur root
pour enregistrer le nouveau mot de passe. Il dispose donc du bit setuid pour que tous les utilisateurs
puissent l’utiliser. Cependant, même s’il s’exécute au nom de l’utilisateur root, il ne doit pas permettre à
n’importe qui de changer le mot de passe des autres utilisateurs : seul l’utilisateur root a le droit de faire
cette opération. Il utilise donc le numéro de l’utilisateur réel qui a lancé la commande pour savoir si c’est
bien l’utilisateur root qui l’a lancé.
Le bit setuid est l’attribut le plus couramment utilisé, essentiellement pour certaines commandes
systèmes. Il est représenté par la lettre ’s’ (comme « Setuid »), et il remplace le droit d’exécution (’x’)
des fichiers pour le propriétaire des fichiers (rappelons que le bit setuid implique que le fichier est
exécutable). Il n’a aucune signification pour les répertoires.
Le deuxième attribut spécial est le bit « setgid » (qui est l’abréviation de l’anglais « SET Group
IDentifier »). Ce bit fonctionne un peu de la même manière que le bit setuid, à ceci près qu’il fixe le
numéro de groupe effectif du processus lancé à celui de son fichier exécutable. Cet attribut est également
représenté par la lettre ’s’, et remplace le droit d’exécution (’x’) pour les utilisateurs du groupe auquel
appartient le fichier exécutable. De plus, et contrairement au bit setuid, ce bit a une signification pour les
répertoires. Un répertoire disposant du bit setgid permet de faire en sorte que tous les fichiers qui sont
créés dans ce répertoire se voient automatiquement attribués le même groupe que le répertoire. Ce bit est
relativement peu utilisé.
Enfin, le troisième et dernier attribut spécial est le bit « sticky ». Cet attribut remplace l’attribut
exécutable pour les autres utilisateurs que le propriétaire du fichier ou du répertoire et les membres du
groupe auquel il appartient. Contrairement aux bits setuid et setgid, il est représenté par la lettre ’t’ (pour
« sTickky »). Sa signification est assez spéciale : elle permet de faire en sorte que les programmes restent
chargés en mémoire après leur terminaison, ce qui permet de les relancer plus rapidement. Afin de ne pas
consommer la mémoire de manière permanente, le code du programme est placé automatiquement dans
le swap s’il n’est toujours pas relancé après un certain temps, mais même dans ce cas, tous les calculs de
chargement sont déjà effectués. Le lancement des programmes marqués de ce bit sera donc toujours
accéléré. Sachez cependant ne pas abuser du bit sticky car la mémoire (même virtuelle) est encore une
ressource rare. Pour les répertoires, sa signification est totalement différente : elle permet de restreindre
les droits des utilisateurs sur les répertoires ayant ce bit positionné. Ce bit fait en sorte que même si un
utilisateur dispose des droits d’écriture sur le répertoire, il ne peut pas supprimer tous les fichiers de ce
répertoire. Les seuls fichiers qu’il est autorisé à supprimer sont ses propres fichiers. Bien entendu, il est
toujours possible d’ajouter des fichiers dans le répertoire en question.
En pratique, les utilisateurs n’ont pas à se soucier des attributs des fichiers, et en fait même
l’administrateur laisse souvent les attributs par défaut, car ils correspondent à la majorité des besoins de
sécurité. L’administrateur a cependant le contrôle total sur les droits d’accès aux fichiers, sur le
propriétaire et le groupe de chaque fichier. Il est également le seul utilisateur capable de créer un autre
utilisateur ou un groupe, ainsi que de les détruire.

13
 Chapitre 3. Concepts de base

Les questions qui se posent évidemment sont les suivantes. Est-ce qu’un particulier a besoin de tout
cela ? Ces fonctionnalités ne sont-elles pas réservées aux serveurs ? Est-ce qu’on ne risque pas de perdre
beaucoup de temps pour définir les droits pour chaque utilisateur et pour chaque ressource du système ?
La gestion de la sécurité ne consomme-t-elle pas trop de ressources ? Ces questions sont légitimes, mais
en fait, il est très intéressant même pour un particulier de disposer de ces fonctionnalités. En effet, la
sécurité permet tout simplement de protéger le système contre ses propres erreurs. Qui n’a pas effacé un
jour un fichier important ou déplacé le répertoire Windows en bougeant légèrement la souris lors d’un
double clic effectué trop lentement ? Avec Linux, on peut faire n’importe quoi, on est certain que le
système restera intact. D’ailleurs la règle essentielle, même pour un ordinateur utilisé par une seule
personne, est de toujours créer un compte utilisateur normal et de ne jamais travailler sous le compte
root. Cette sécurité est telle que Linux est le système d’exploitation idéal pour apprendre l’informatique à
quelqu’un : savoir que le système protège tout ce qui est important permet aux débutants de prendre des
initiatives sans crainte. Quant aux éventuels revers de médaille, ils sont absents : la gestion de la sécurité
ne consomme quasiment aucune ressource, et sa configuration est élémentaire. Toutes les distributions
s’installent de telle sorte que le système se protège des utilisateurs, et que ceux-ci soient indépendants les
uns des autres.
En résumé :

• le multitâche est un confort indéniable. Il est appréciable de pouvoir utiliser son ordinateur même
lorsqu’il est en train de faire une tâche longue en arrière-plan ;
• la fiabilité est évidemment indispensable. Il est rassurant de se dire que même si un processus très
gourmand en ressources fonctionne en arrière-plan, il ne perturbera pas les autres processus ;
• la sécurité permet de se protéger de ses propres erreurs, pour un coût minimal. Il suffit de conserver les
paramètres par défaut du système et de ne plus s’en soucier !

Fonctionnalités des systèmes de fichiers

Il est sûrement bon de revenir sur les fonctionnalités fournies par les systèmes de fichiers Unix. En effet,
peu d’utilisateurs savent exactement quels sont les services qu’ils peuvent fournir en général, et
beaucoup croient que les systèmes de fichiers savent juste stocker des données dans des fichiers
organisés dans une hiérarchie de répertoires. Heureusement, ils permettent de faire beaucoup mieux que
cela ! En fait, les systèmes de fichiers des systèmes Unix sont très puissants. Ils assurent à la fois
fonctionnalités, performances et fiabilité.
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

14
 Chapitre 3. Concepts de base

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.

Figure 3-2. Le système de fichiers virtuel

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éffectueux 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) ;
• le système de fichiers NTFS (utilisé par Windows NT, Windows 2000 et XP), en lecture seule et en
écriture par écrasement des données de fichiers existants uniquement pour l’instant ;
• 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).

15
 Chapitre 3. Concepts de base

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 un pseudo système de fichiers généré par le noyau. Ce système
de fichiers est complètement fictif : sa structure et ses fichiers sont générés dynamiquement par le noyau
lorsqu’une application y accède. Il est principalement utilisé par les applications pour lire des
informations que le noyau met à leur disposition, ainsi que pour changer dynamiquement certains
paramètres du noyau en les écrivant simplement dans les fichiers.
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 est si
faible que l’on peut l’ignorer en pratique. Cela provient des algorithmes utilisés par ces systèmes de
fichiers pour allouer les blocs du disque dur lors de l’écriture dans un fichier : ils cherchent tout
simplement à donner systématiquement les blocs les plus proches. 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.

Nous allons maintenant voir les quelques fonctionnalités additionnelles que les systèmes de fichiers de
Linux supportent.
La première fonctionnalité intéressante est le support des droits d’accès aux fichiers pour les utilisateurs
et pour les groupes. La gestion de ces droits est un impératif sous Unix. Comme on l’a déjà vu, ces droits
comprennent les droits d’accès en lecture, en écriture et en exécution, plus les attributs spéciaux des
fichiers. Ces droits sont fixés indépendamment pour l’utilisateur propriétaire du fichier, le groupe
d’utilisateur propriétaire du fichier, et tous les autres utilisateurs.

16
 Chapitre 3. Concepts de base

Une autre fonctionnalité intéressante 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 3-1. Caractéristiques des liens physiques et symboliques

17
 Chapitre 3. Concepts de base

Fonctionnalité Liens physiques Liens symboliques

Référence relative Référence
absolue
Peuvent être déplacés Oui Avec la cible Oui
Suivent la cible Oui Si déplacés avec elle Non
Gèrent la suppression de la cible Oui Non Non
Peuvent référencer des cibles sur Non Oui Oui
un autre système de fichiers
Peuvent référencer des Non Oui Oui
répertoires

Les systèmes de fichiers de Linux donne également la possibilité de gérer des fichiers presque vides
(« sparse files » en anglais) et les quotas. Ces deux fonctionnalités sont relativement peu utilisées par les
particuliers, elles ne sont mentionnées ici qu’afin d’être complet. Les fichiers presque vides sont des
fichiers contenant des données séparées par de grands espaces vides. Il est inutile de stocker ces espaces
vides sur le disque, aussi les systèmes de fichiers signalent-ils simplement que ce fichier contient 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. Les quotas quant à eux permettent d’attribuer un espace disque fixe à chaque utilisateur. Ce
n’est réellement utile que pour les serveurs.

Structure du système de fichiers

Il est nécessaire de définir un peu les termes qui vont être utilisés dans cette section, car les systèmes de
fichiers Unix sont très différents des systèmes de fichiers du DOS et de Windows. La connaissance de ce
vocabulaire est nécessaire pour la compréhension de la structure du système de fichiers de Linux.
Comme la plupart des systèmes de fichiers, les systèmes de fichiers Unix sont structurés
hiérarchiquement, et regroupent les fichiers dans des répertoires. Il existe un répertoire racine qui
contient tous les fichiers soit directement, soit indirectement dans ses sous-répertoires. C’est de ce
répertoire que débutent tous les chemins possibles dans le système de fichiers. Chaque fichier ou
répertoire a un nom qui permet aux utilisateurs du système de l’identifier. Le seul répertoire qui n’a pas
de nom est le répertoire racine. Les systèmes de fichiers Unix n’ont pas les mêmes limitations sur les
noms que les systèmes de fichiers FAT et FAT32. Les noms des fichiers et des répertoires peuvent être
très longs (jusqu’à 256 caractères par nom), et ils prennent en compte la casse des lettres.
Les fichiers contiennent des données au sens large, ce peut être des documents (texte, image, film, son),
des programmes, des données utilisées par le système ou tout autre type de donnée imaginable. En fait,
les répertoires sont eux-mêmes des fichiers spéciaux, interprétés par le système différemment des autres
fichiers. Les données stockées dans les répertoires sont simplement les entrées de répertoires, qui
caractérisent et permettent d’avoir accès aux autres fichiers et aux autres répertoires.
Les noms de répertoires et de fichiers sont séparés par un caractère spécial. Ce caractère est
traditionnellement, sous Unix, la barre oblique de division (nommée « slash » en anglais) : ’/’. Les
utilisateurs du DOS et de Windows prendront garde ici au fait que Microsoft a préféré la barre oblique

18
 Chapitre 3. Concepts de base

inverse (nommée « backslash » en anglais) ’\’, rendant ainsi tous ses systèmes incompatibles avec les
systèmes Unix, et générant ainsi beaucoup de problèmes supplémentaires là où il n’était pas nécessaire
d’en avoir (sincèrement, le coût de cette ânerie, ainsi que celle des marqueurs de fin de ligne dans les
fichiers textes, doit atteindre des sommes astronomiques dans tous les projets de portage ou de
développement d’applications portables). Comme le répertoire racine n’a pas de nom, il peut être accédé
directement avec un simple slash :

La qualification complète d’un fichier se fait en précisant le nom du répertoire à chaque niveau et en
séparant par des slashes chacun de ces noms. Cette qualification porte le nom de « chemin » d’accès
(« path » en anglais). L’exemple suivant vous montre l’allure d’un chemin d’accès typique sous Unix :

/home/[Link]/lettres/professionnelles/marketing/[Link]

La longueur maximale d’un chemin d’accès est de 4 ko dans le système de fichiers EXT2.
Les utilisateurs du DOS et de Windows constateront ici que les chemins d’accès Unix ne comportent pas
de spécification de lecteur. Les systèmes de fichiers Unix sont dits mono-têtes, ce qui signifie qu’ils n’ont
qu’un seul point de départ : le répertoire racine (alors que les systèmes Microsoft sont multi-têtes,
puisqu’ils ont un point de départ par lecteur et par partition). Le fait de n’avoir qu’un seul point de départ
est beaucoup plus simple et permet, encore une fois, d’écrire les programmes plus simplement et donc
avec moins de bogues potentiels. Je sens tout de suite venir la question de la part des habitués du DOS :
« Mais alors, comment spécifie-t-on le lecteur que l’on veut utiliser ? ». Cette question a deux réponses.
Premièrement, on n’accède pas aux lecteurs, mais aux systèmes de fichiers. Les utilisateurs du DOS
devront donc réapprendre qu’un lecteur représente un périphérique physique, et qu’il est possible qu’il
contienne plusieurs systèmes de fichiers. Ils devront également se rendre compte qu’un système de
fichiers n’est pas nécessairement stocké sur un lecteur : il peut être stocké dans un fichier (c’est le cas par
exemple pour les images disques de CD-ROM), accessible par le réseau (c’est le cas des systèmes de
fichiers réseau, « Network File System » en anglais), ou encore généré par un composant du système
(c’est le cas des systèmes de fichiers virtuels du noyau). La question n’a donc pas beaucoup de sens telle
quelle. Cependant, le problème de l’accès aux systèmes de fichiers se pose malgré tout. La réponse à ce
problème-ci est cette fois la suivante : pour accéder à un système de fichiers, il faut réaliser une opération
que l’on nomme le « montage ». Cette opération associe le répertoire racine de ce système de fichiers à
l’un des répertoires de l’arborescence existante. Ce répertoire est couramment appelé « point de
montage ». Par exemple, il est courant de monter le lecteur de disquette dans le répertoire /floppy/.
Ainsi, si la disquette contient le fichier [Link], ce fichier sera accessible grâce au chemin
suivant :

/floppy/[Link]

Cette solution permet d’accéder à tous les systèmes de fichiers de la même manière, à partir d’un seul
répertoire racine, que ces systèmes de fichiers soient EXT2, FAT, ISO9660, NTFS ou Amiga... En
pratique, c’est nettement plus simple.
L’opération de montage peut réaliser bien plus d’opérations qu’une simple association d’un système de
fichiers à un point de montage. En effet, elle peut générer les opérations suivantes :

19
 Chapitre 3. Concepts de base

• chargement des pilotes pour ce système de fichiers ;

• allocation des zones de mémoire pour les entrées/sorties en mémoire ;
• masquage des fichiers et des répertoires éventuellement présents avant le montage dans le répertoire
utilisé comme point de montage.

On prendra en particulier garde à toujours démonter les systèmes de fichiers pour les lecteurs amovibles.
Linux utilise en effet des zones de la mémoire que l’on appelle les tampons (« buffers » en anglais), pour
y stocker les données des systèmes de fichiers montés, et il n’écrit ces données que lorsque c’est
nécessaire. Ce mécanisme permet d’accélérer les lectures et les écritures sur les disques, mais a
l’inconvénient de nécessiter une requête de vidange des tampons (opération que l’on appelle « sync »)
avant de retirer le lecteur ou avant d’éteindre le système. Si on ne le fait pas, des données seront
certainement perdues. Le système effectue le sync lorsqu’il s’arrête (par l’une des commandes halt,
shutdown ou reboot), mais il ne le fait pas si on coupe le courant brutalement. C’est pour cela qu’il faut
toujours arrêter le système proprement. De manière similaire, Linux empêche l’éjection des CD-ROM
tant qu’ils sont montés. En revanche, il ne peut rien faire pour les lecteurs de disquettes, c’est à
l’utilisateur de prendre garde à les démonter avant de retirer la disquette.
Deux derniers points auxquels les utilisateurs de DOS et Windows devront faire attention :

• les fichiers ne sont pas identifiés par leur extension. Un nom de fichier peut contenir un ou plusieurs
points, et une extension peut être arbitrairement longue. En particulier, un nom de fichier peut
commencer par un point. Dans ce cas, ce fichier sera considéré comme caché par les programmes, et
on ne les verra que si on le demande explicitement ;
• les systèmes de fichiers Unix font la distinction entre les majuscules et les minuscules. Il faut donc
prendre garde à la manière dont on écrit les noms de fichiers et de répertoires. Cependant, la plupart
des répertoires et des fichiers ont un nom écrit complètement en minuscules.

Nous allons à présent nous intéresser à l’organisation du système de fichiers de Linux. Ce système de
fichiers contient un certain nombre de répertoires et de fichiers standards, qui ont chacun une fonction
bien définie. Cette structure standard permet de gérer tous les systèmes Linux de manière homogène : les
programmes savent où trouver ce dont ils ont besoin. Ils sont donc portables d’un système à un autre, et
les utilisateurs ne sont pas dépaysés lorsqu’ils changent de machine (en fait, cette structure est à peu près
la même pour tous les systèmes Unix, ce qui donne encore plus de poids à l’argument précédent).
Cette organisation standard du système de fichiers a été conçue de telle manière que les données et les
programmes sont placés chacun à leur place, et qu’ils puissent être facilement intégrés dans un réseau.
L’intégration dans un réseau sous-entend que les fichiers des programmes peuvent être partagés par les
différentes machines de ce réseau, ce qui permet d’économiser beaucoup de place. De plus, il est
possible d’accéder à la plupart des ressources du système grâce à une interface uniforme. En particulier,
il est possible d’accéder à tous les périphériques installés sur l’ordinateur par l’intermédiaire de fichiers
spéciaux, et on peut récupérer des informations sur le système mises à disposition par le noyau
simplement en lisant des fichiers générés par un pseudo système de fichiers. Le tableau suivant décrit les
principaux éléments de l’arborescence du système de fichiers de Linux.

Tableau 3-2. Hiérarchie standard du système de fichiers

20
 Chapitre 3. Concepts de base

Répertoire Signification
/ Répertoire racine. Point de départ de toute la hiérarchie du système de
fichiers. Le système de fichiers contenant ce répertoire est monté
automatiquement par le noyau pendant l’amorçage du système. Ce système
de fichiers est appelé système de fichiers racine (« root » en anglais).
/boot/ Répertoire contenant le noyau de Linux et ses informations de symboles. Ce
répertoire est parfois le point de montage d’un système de fichiers de très
petite taille, dédié au noyau. Dans ce cas, il est recommandé que le système
de fichiers correspondant soit monté en lecture seule. On notera que sur
certains systèmes, le noyau reste placé dans le répertoire racine. Cette
technique n’est pas recommandée, car on ne peut pas monter en lecture seule
la partition racine en utilisation normale du système.
/boot/vmlinuz Noyau compressé de Linux. Les noyaux compressés se décompressent
automatiquement lors de l’amorçage du système. Sur certains systèmes, le
noyau est encore placé dans le répertoire racine du système de fichiers.
/boot/[Link] Fichier système contenant la liste des symboles du noyau. Ce fichier est
utilisé par certains programmes donnant des renseignements sur le système.
En particulier, il est utilisé par le programme « top » (programme qui indique
la liste des principaux processus actifs) afin de donner le nom de la fonction
du noyau dans lequel un processus se trouve bloqué lorsqu’il est en attente de
la fin d’une opération que le noyau doit exécuter pour lui.
/dev/ Répertoire contenant tous les fichiers spéciaux permettant d’accéder aux
périphériques. Sous Linux, la plupart des périphériques sont accessibles au
travers de fichiers spéciaux, grâce auxquels l’envoi et la réception des
données vers les périphériques peuvent être réalisés de manière uniforme. Il
existe un tel fichier pour chaque périphérique, et ils sont tous placés dans ce
répertoire. Les distributions installent souvent dans ce répertoire les fichiers
spéciaux pour la plupart des périphériques, même s’ils ne sont pas
physiquement présents dans la machine. Dans ce cas, les opérations sur les
fichiers spéciaux des périphériques non installés seront tout simplement
refusées par le noyau. Une autre possibilité est d’utiliser un système de
fichiers virtuel, géré directement par le noyau. Le répertoire /dev/ ne
contient dans ce cas que les fichiers spéciaux des périphériques pour lesquels
le noyau dispose d’un gestionnaire intégré ou chargé dynamiquement. Quelle
que soit la technique utilisée, ce répertoire doit être impérativement placé
dans le système de fichiers racine.
/sbin/ Répertoire contenant les commandes systèmes nécessaires à l’amorçage et
réservées à l’administrateur. Ce répertoire doit être impérativement placé
dans le système de fichiers racine. En général, seul l’administrateur utilise
ces commandes.
/bin/ Répertoire contenant les commandes systèmes générales nécessaires à
l’amorçage. Ce répertoire doit être impérativement placé dans le système de
fichiers racine. Tous les utilisateurs peuvent utiliser les commandes de ce
répertoire.

21
 Chapitre 3. Concepts de base

Répertoire Signification
/lib/ Répertoire contenant les bibliothèques partagées (« DLL » en anglais, pour
« Dynamic Link Library ») utilisées par les commandes du système des
répertoires /bin/ et /sbin/. Ce répertoire doit être impérativement placé
dans le système de fichiers racine.
/lib/modules/ Ce répertoire contient les modules additionnels du noyau. Les modules sont
des composants logiciels du noyau, mais qui ne sont pas chargés
immédiatement pendant la phase d’amorçage du système. Ils peuvent en
revanche être chargés et déchargés dynamiquement, lorsque le système est en
fonctionnement. Il est fortement recommandé que ce répertoire soit placé
dans le système de fichiers racine.
/etc/ Répertoire contenant tous les fichiers de configuration du système. Ce
répertoire doit être impérativement placé dans le système de fichiers racine.
/etc/X11/ Répertoire contenant les fichiers de configuration de l’environnement
graphique XWindow. Dans certaines distributions, ces fichiers sont placés
directement dans le répertoire /etc/, mais ce n’est pas une technique
recommandable.
/etc/rc.d/ Répertoire contenant les scripts de démarrage du système. Ces scripts sont
exécutés lorsque le système démarre ou s’arrête, ainsi que lorsqu’il change
de mode de mode de fonctionnement. Il est également possible de les
exécuter pour démarrer ou arrêter un service particulier. Dans certaines
distributions, ces fichiers sont placés dans le répertoire /sbin/init.d/.
/etc/opt/ Répertoire contenant les fichiers de configuration des applications.
/tmp/ Répertoire permettant de stocker des données temporaires. En général,
/tmp/ ne contient que des données très éphémères. Il est préférable
d’utiliser le répertoire /var/tmp/. En effet, le répertoire /tmp/ ne dispose
pas nécessairement de beaucoup de place disponible.
/usr/ Répertoire contenant les fichiers du système partageables en réseau et en
lecture seule.
/usr/bin/ Répertoire contenant la plupart des commandes des utilisateurs.
/usr/sbin/ Répertoire contenant les commandes systèmes non nécessaires à l’amorçage.
Ces commandes ne sont normalement utilisées que par l’administrateur
système.
/usr/lib/ Répertoire contenant les bibliothèques partagées de tous les programmes de
/usr/bin/ et /usr/sbin/ et les bibliothèques statiques pour la création de
programmes.
/usr/include/ Répertoire contenant les fichiers d’en-têtes du système pour le compilateur
C/C++. Les fichiers de ce répertoire sont utilisés pour réaliser des
programmes dans les langages de programmation C et C++.
/usr/X11R6/ Répertoire contenant X11R6 et ses applications. Ce répertoire contient des
sous-répertoires bin/, lib/ et include/, où se trouvent les exécutables de
XWindow, les bibliothèques et les fichiers d’en-têtes pour créer des
programmes pour XWindow en C et C++.

22
 Chapitre 3. Concepts de base

Répertoire Signification
/usr/src/ Répertoire contenant les fichiers sources du noyau et des applications de la
distribution. Normalement, ce répertoire ne doit contenir que le code source
des applications dépendantes de la distribution que vous utilisez.
/usr/src/linux/ Sources du noyau de Linux. Il est vivement recommandé de conserver les
sources du noyau de Linux sur son disque, afin de pouvoir changer la
configuration du système à tout moment.
/usr/local/ Répertoire contenant les programmes d’extension du système indépendants
de la distribution. Ce n’est toutefois pas le répertoire d’installation des
applications, que l’on installera en général dans le répertoire /opt/.
« local » ne signifie pas ici que les programmes qui se trouvent dans ce
répertoire ne peuvent pas être partagés sur le réseau, mais plutôt que ce sont
des extensions du système qu’on ne trouve donc que localement sur un site
donné. Ce sont donc les extensions qui ne font pas partie de la distribution de
Linux utilisée, et qui doivent être conservées lors des mises à jour ultérieures
de cette distribution. Ce répertoire contient les sous-répertoires bin/, lib/,
include/ et src/, qui ont la même signification que les répertoires du
même nom de /usr/, à ceci près qu’ils ne concernent que les extensions
locales du système, donc indépendantes de la distribution.
/var/ Répertoire contenant toutes les données variables du système. Ce répertoire
contient les données variables qui ne pouvaient pas être placées dans le
répertoire /usr/, puisque celui-ci est normalement accessible en lecture
seule.
/var/tmp/ Répertoire contenant les fichiers temporaires. Il est préférable d’utiliser ce
répertoire plutôt que le répertoire /tmp/.
/var/opt/ Répertoire contenant les données variables des applications.
/var/log/ Répertoire contenant les traces de tous les messages système. C’est dans ce
répertoire que l’on peut consulter les messages d’erreurs du système et des
applications.
/var/spool/ Répertoire contenant les données en attente de traitement. Les travaux
d’impression en cours, les mails et les fax en attente d’émission, les travaux
programmés en attente d’exécution sont tous stockés dans ce répertoire.
/var/locks/ Répertoire contenant les verrous sur les ressources système. Certaines
ressources ne peuvent être utilisées que par une seule application (par
exemple, un modem). Les applications qui utilisent de telles ressources le
signalent en créant un fichier de verrou dans ce répertoire.
/var/cache/ Répertoire contenant les données de résultats intermédiaires des applications.
Les applications qui doivent stocker des résultats intermédiaires doivent les
placer dans ce répertoire.

23
 Chapitre 3. Concepts de base

Répertoire Signification
/opt/ Répertoire contenant les applications. C’est dans ce répertoire que les
applications qui ne font pas réellement partie du système doivent être
installées. Les applications graphiques devraient être installées dans ce
répertoire. C’est en particulier le cas des gestionnaires de bureau. Les seules
applications graphiques considérées comme faisant partie du système sont
les applications de X11, qui sont donc stockées dans /usr/X11R6/. Il est
recommandé que ce répertoire soit placé sur un système de fichiers en lecture
seule, et que les applications utilisent le répertoire /var/opt/ pour
travailler.
/home/ Répertoire contenant les répertoires personnels des utilisateurs. Il est bon de
placer ce répertoire dans un système de fichiers indépendant de ceux utilisés
par le système. Cela permet de faire des sauvegardes plus facilement, et de
faire les mises à jour du système de manière sûre, sans craindre de perdre les
données des utilisateurs.
/root/ Répertoire contenant le répertoire personnel de l’administrateur. Il est donc
recommandé que le répertoire personnel de l’administrateur soit placé en
dehors de /home/ pour éviter qu’un problème sur le système de fichiers des
utilisateurs ne l’empêche de travailler. Toutefois, il est important que
l’administrateur puisse travailler même si les répertoires /root/ et
/home/root/ ne sont pas présents. Dans ce cas, son répertoire personnel
sera le répertoire racine.
/mnt/ Répertoire réservé au montage des systèmes de fichiers non-permanents
(CD-ROM, disquettes, etc.). Ce répertoire peut contenir plusieurs
sous-répertoires pour chaque périphérique amovible, afin de permettre d’en
monter plusieurs simultanément. Notez qu’il est assez courant de disposer de
liens symboliques dans la racine référençant les principaux systèmes de
fichiers, afin d’en simplifier l’accès. Par exemple, il est courant d’avoir un
répertoire /floppy/ référençant le lecteur de disquette et un répertoire
/cdrom/ référençant le lecteur de CD-ROM.
/lost+found/ Répertoire contenant les données récupérées lors de la réparation d’un
système de fichiers endommagé. Ces données sont écrites par les utilitaires
de vérification et de réparation des systèmes de fichiers lorsqu’ils trouvent
des informations qui ne peuvent être rattachées à aucun fichier existant, ainsi,
il est possible de récupérer ces informations si elles ne sont pas dans un état
de détérioration trop avancé.
/proc/ Répertoire contenant le pseudo système de fichiers du noyau. Ce pseudo
système de fichiers contient des fichiers permettant d’accéder aux
informations sur le matériel, la configuration du noyau et sur les processus en
cours d’exécution.

24
 Chapitre 3. Concepts de base

Répertoire Signification
/sys/ Répertoire contenant le pseudo système de fichiers des gestionnaires de
périphériques. Ce pseudo système de fichiers contient des fichiers permettant
d’obtenir des informations sur l’ensemble des objets du noyau, en en
particulier sur l’ensemble des périphériques de l’ordinateur. Ce système de
fichiers est appelé à recevoir une bonne partie des informations exposées par
le système de fichiers /proc/, dont le rôle se restreindra sans doute à fournir
des informations plus générales sur le système.

Note : Les informations données ici peuvent ne pas être correctes pour votre distribution. En effet,
certaines distributions utilisent une structure légèrement différente. Les informations données ici sont
conformes à la norme de hiérarchie de systèmes de fichiers version 2.0 (« FHS » en anglais). Vous
pouvez consulter ce document pour une description exhaustive du système de fichiers de Linux.

Vous avez pu constater que les répertoires bin/, lib/, include/ et src/ apparaissent régulièrement
dans la hiérarchie du système de fichiers. Cela est normal : les répertoires sont classés par catégorie
d’applications et par importance. Les répertoires bin/ contiennent en général les programmes, et les
répertoires lib/ les bibliothèques partagées par ces binaires. Cependant, les répertoires lib/ peuvent
aussi contenir des bibliothèques statiques, qui sont utilisées lors de la création de programmes. En
général, tous les systèmes Unix fournissent en standard un compilateur pour réaliser ces programmes.
Dans le cas de Linux, ce compilateur est « gcc » (pour « GNU C Compiler »). La création d’un
programme nécessite que l’on dispose des fichiers sources, qui contiennent le programme écrit dans un
langage de programmation, des fichiers d’en-têtes, qui contiennent les déclarations de toutes les
fonctions utilisables, et des fichiers de bibliothèques statiques, contenant ces fonctions. Ces différents
fichiers sont stockés respectivement dans les répertoires src/, include/ et lib/. Les notions de
sources et de compilation seront décrites en détail dans le Chapitre 7.

25
Chapitre 4. Installation du système de base
Maintenant que vous connaissez tout des grands principes de Linux (et de la plupart des systèmes Unix),
vous devez brûler d’impatience de l’installer et de commencer à exploiter toutes ses possibilités.
Cependant, il faut ne pas tomber dans le travers de ceux qui veulent impérativement utiliser une
fonctionnalité sous prétexte qu’elle est disponible. Il se peut que vous ayez envie de les essayer, parce
que vous en avez été privé depuis longtemps. Ce comportement est tout à fait normal, mais vous allez
devoir refréner vos envies, pour deux raisons. La première est qu’il va falloir installer Linux au préalable,
et la deuxième est qu’il ne faut pas faire un sac de nœuds avec vos données. Vous pourrez expérimenter à
loisir, mais il faudra rester sérieux dès que vous toucherez au système. Comprenez bien que l’installation
et la configuration de Linux doivent se faire pas à pas. Griller les étapes peut se révéler être une erreur,
car cela rendrait les choses plus compliquées qu’elles ne le sont.
La configuration minimale supportée par Linux est un 386 avec au minimum 12 Mo de mémoire vive. Il
va de soi qu’avec un tel foudre de guerre, vous ne pourrez pas aller bien loin, et une configuration
minimale plus raisonnable serait plutôt un 486DX2 66MHz avec au moins 32Mo de mémoire. La
quantité de mémoire est de loin le facteur le plus important, et si vous voulez utiliser l’environnement
graphique X11, il faut au minimum compter sur 64 Mo de mémoire vive. Vous pourrez donc
parfaitement transformer un vieux 486 ou pentium en routeur ou en Firewall avec partage de connexion à
Internet par exemple. Vous n’aurez donc certainement aucun problème avec les ordinateurs puissants qui
se vendent actuellement.

Récupération des informations sur le matériel

Avant de commencer quoi que ce soit, vous devriez récupérer le maximum de données concernant votre
matériel. En effet, ces informations peuvent être particulièrement utiles pour diagnostiquer la cause des
éventuels problèmes de configuration du matériel que vous pourriez rencontrer. Vous aurez aussi peut
être à spécifier certains paramètres matériels lors de l’installation et, dans le pire des cas, lors du premier
démarrage de Linux. Les informations dont vous aurez certainement besoin sont les suivantes :

• type de processeur, avec sa marque et éventuellement sa vitesse ;

• type de carte mère, avec sa marque et impérativement son chipset ;
• type de branchement de la souris (série, PS/2, USB, interface bus propriétaire) ;
• nombre de ports série, ainsi que leurs paramètres (ports d’entrée/sortie, lignes d’interruption) ;
• nombre de ports parallèles, ainsi que leurs paramètres (ports d’entrée/sortie, lignes d’interruption) ;
• le type de port USB (vitesse, compatible UHCI ou OHCI) ;
• si vous disposez d’un contrôleur SCSI, marque et modèle de ce contrôleur (modèle du chipset de la
carte SCSI) ;
• sinon, nom du contrôleur de disque IDE (regardez sur le chipset de la carte mère !) ;
• types de disques durs (IDE, IDE UltraDMA 33, 66 ou 100, SCSI), ainsi que leurs taille et leur position
dans le système (contrôleurs auxquel ils sont connectés, numéros d’unités logiques SCSI) ;

26
 Chapitre 4. Installation du système de base

• types de lecteurs ou de graveur de CD-ROM ou de DVD (IDE, ATAPI, SCSI, connecté sur carte son)
et le type de leur branchement s’ils sont externes (port parallèle, SCSI ou USB) ;
• nom, modèle et marque de la carte graphique, type de chipset utilisé par cette carte et taille de sa
mémoire vidéo ;
• nom, modèle et marque de l’écran, avec, surtout, ses fréquences de balayage horizontales et verticales,
sa bande passante et les fréquences recommandées par le constructeur pour les différentes résolutions ;
• type de carte son (ISA, PCI, PnP) ainsi que le nom du chipset utilisé par cette carte ;
• type de carte réseau (ISA, PCI, PnP) ainsi que le nom de son chipset ;
• type de chipset pour les réseaux sans fils Wifi ;
• type de modem (interne, externe) et, si le modem est interne, sa nature (modem complet ou
émulation) ;
• type de chipset pour le contrôleur FireWire (IEEE 1394) si vous en disposez d’un ;
• type de chipset et nom, marque, modèle pour les périphériques annexes (contrôleurs infrarouge,
lecteurs de cartes mémoire intégrés, etc.).

Vous pouvez obtenir ces informations en consultant la documentation fournie avec votre ordinateur, les
sites Web des constructeurs des différents composants, les informations fournies par le programme de
configuration du BIOS ou affichées directement par le BIOS au démarrage de la machine, ou tout
simplement en ouvrant le boîtier de la machine et en regardant ce qu’il y a à l’intérieur. Vous pouvez
également récupérer les informations indiquées dans la configuration de MS Windows si celui-ci est
installé.
Il se peut que vous n’ayez pas besoin de ces informations et que l’installation se passe sans problèmes.
Cependant, si d’aventure Linux exige que vous les connaissiez, mieux vaut pouvoir lui répondre.

Note : Bien que cela soit assez rare, certains composants ou périphériques additionnels peuvent ne
pas être gérés par Linux, faute d’avoir un gestionnaire de périphériques adéquat (cet état de fait est
en général dû à une rétention d’informations de la part des fabricants, qui empêchent ainsi les
développeurs de Linux d’écrire les gestionnaires de périphériques dans de bonnes conditions). C’est
en particulier le cas de nombre de périphériques bas de gamme conçus pour ne fonctionner qu’avec
MS Windows, ou de quelques périphériques exotiques. Les Winmodems ont une triste réputation à
ce sujet (il s’agit de modems incomplets, dont une partie du traitement de signal est reporté dans un
logiciel spécifique à Windows), ainsi que des imprimantes dites « GDI », qui ne comprennent que les
commandes graphiques de Windows. Vous pourrez également avoir des problèmes avec des cartes
de numérisation vidéo analogiques ainsi que certaines cartes de décompression MPEG. Certaines
marques se distinguent par le fait qu’elles refusent obstinément de développer des gestionnaires de
périphériques pour leur matériel ou, pire encore, de fournir les informations nécessaires aux
développeurs de Linux pour écrire ces gestionnaires sous licence libre. Il est donc recommandé,
comme toujours, de bien se renseigner auprès des vendeurs et des groupes de discussion avant
tout achat de matériel... Vous pourrez trouver une liste (non exhaustive) de matériel testé sous Linux
dans la liste de matériel compatible Linux ([Link] La
Liste de compatibilité Linux ([Link] vous permettra également d’effectuer
une recherche sur n’importe quel type de matériel et sur n’importe quel modèle très facilement. Il
existe d’autres sites réalisant périodiquement des tests sur le matériel récent, comme par exemple
LinuxHardware ([Link]

27
 Chapitre 4. Installation du système de base

Sauvegarde des données

L’installation du système de base est l’opération la plus délicate, puisqu’il faut travailler au niveau le plus
bas. La moindre erreur peut provoquer une catastrophe, ce qui peut aller jusqu’à recommencer
complètement l’installation. Si vous installez Linux pour la première fois sur votre ordinateur, ou s’il n’y
a pas d’autre système d’exploitation installé dessus, vous en serez quitte pour quelques heures perdues.
Sinon, ce qui est le plus à craindre, c’est la perte totale de vos données, y compris celles des autres
systèmes installés ! Donc :

IL FAUT DONC FAIRE UNE SAUVEGARDE DE VOS DONNÉES !

La manière de procéder dépend bien entendu des systèmes d’exploitation éventuellement déjà installés.
Généralement, il s’agit de Microsoft Windows. Si vous disposez d’un lecteur de bande, le problème de la
sauvegarde est très simple : vous n’avez qu’à faire une sauvegarde complète. Dans le cas contraire, vous
allez sans doute devoir trier vos fichiers afin d’identifier ceux auxquels vous tenez réellement, et les
recopier sur un support physique fiable (évitez absolument les disquettes, ils sont lents et n’ont jamais été
fiables). Vous pouvez par exemple faire un CD de sauvegarde si vous disposez d’un graveur de CD.
En fait, l’idéal est tout simplement de disposer d’un autre disque dur, que l’on pourra consacrer
complètement à l’installation de Linux. Ainsi, vous pourrez expérimenter tout à loisir, sans craindre de
perdre vos précieuses données. De plus, l’installation de Linux sur un disque vierge est nettement plus
facile que sur un disque où Windows est déjà installé, parce que vous n’avez pas à dégager de la place
pour son installation. Prenez toutefois garde au fait que Linux restera capable d’accéder aux données de
votre premier disque dur, et que toute erreur de manipulation peut détruire les données qui s’y trouvent.
Par exemple, si vous ne spécifiez pas le bon disque dur lors de la création des systèmes de fichiers, vous
perdrez à nouveau toutes vos données. L’achat d’un tiroir peut être la vraie solution, car vous n’aurez
alors qu’un seul disque à un instant donné dans votre ordinateur. Toutefois, cette technique a
l’inconvénient de ne pas vous permettre d’accéder aux données de votre disque Windows à partir de
Linux.

Amorçage
Pour commencer votre installation, vous devez avant tout démarrer votre ordinateur sous Linux. La
méthode la plus simple est certainement de mettre le CD d’amorçage de votre distribution dans le lecteur
de CD et de redémarrer l’ordinateur. Il faut que votre BIOS soit configuré pour amorcer le système sur le
lecteur de CD pour que cette solution fonctionne. Si votre BIOS ne vous permet pas de le faire, il ne vous
reste plus qu’à utiliser l’une des disquettes fournies avec votre distribution. Pensez également à
supprimer la protectiona contre anti-virus de secteurs de boot de votre BIOS avant de faire l’installation
du système. Dans tous les cas, Linux doit se lancer, et le programme d’installation doit démarrer. Suivez
les indications fournies avec votre distribution pour cette étape.
Le noyau de Linux qui est fourni avec votre distribution est un noyau qui a été spécialement conçu pour
démarrer correctement sur le plus grand nombre de machines possibles. Il contient donc les pilotes
(« drivers » en anglais) pour votre disque dur, ainsi que pour d’autres types de disques. Il se peut même
que plusieurs noyaux vous aient été livrés avec votre distribution. Chacun de ces noyaux permet de
démarrer sur un certain type d’ordinateur. Lorsqu’il se lance, Linux tente de détecter le matériel de votre
ordinateur. Seuls les pilotes correspondant à votre matériel s’activent, les autres sont tout simplement

28
 Chapitre 4. Installation du système de base

ignorés. Il se peut cependant que Linux ne détecte pas vos disques durs. Cela peut arriver surtout pour les
disques SCSI. Dans ce cas, soit il faut changer de noyau, soit il faut utiliser des pilotes additionnels, qui
peuvent être chargés à la demande. Ces pilotes sont appelés des « modules » du noyau. Ces modules sont
en général accessibles directement sur le CD-ROM ou la disquette de démarrage, ou sur une disquette
complémentaire. Si Linux ne détecte pas vos disques durs, vous serez obligé d’indiquer les modules à
charger au programme d’installation. Si cela ne fonctionne toujours pas, vous devrez réamorcer votre
système avec un noyau plus adapté à votre matériel. Pour cela, vous aurez sans doute besoin de créer une
disquette d’amorçage pour ce noyau, et de l’utiliser à la place de votre lecteur de CD. En général, les
distributions fournissent un petit utilitaire DOS nommé [Link] qui permet de créer une
disquette d’amorçage à partir d’un noyau très simplement. Il s’utilise avec la ligne de commande
suivante :

rawrite image lecteur:

où image est l’image d’une des disquettes d’amorçage (que vous trouverez sur le CD d’amorçage de
votre distribution), et lecteur est le lecteur de disquette utilisé (en général, « A: »). Vous pouvez aussi
consulter la documentation de votre distribution pour savoir comment indiquer au noyau les modules
qu’il doit charger, ou comment créer une disquette de démarrage pour un autre noyau.
Dans la majorité des distributions, les outils nécessaires à l’installation sont placés sur un disque virtuel
en mémoire après le démarrage de Linux. C’est en particulier le cas du programme d’installation. Cela
est normal, puisque Linux n’est pas encore installé, d’une part, et que ces outils ne tiennent pas
facilement sur une disquette, d’autre part. Ces outils sont donc souvent compressés. Vous devez malgré
tout avoir déjà accès aux périphériques de votre ordinateur, en particulier aux disques, pour poursuivre
votre installation.

Partitionnement du disque
La deuxième opération après le démarrage du système est le partitionnement du disque dur. Cette étape
est de loin la plus dangereuse, mais elle est absolument nécessaire. Elle ne pose pas de problèmes
lorsqu’on installe Linux sur une machine neuve, mais peut être délicate si un autre système
d’exploitation est déjà installé ou doit être installé en parallèle. Cette section décrit les principes de base
du partitionnement, la manière de récupérer de la place sur un disque dur et l’opération de
partitionnement proprement dite.

Notion de partition et d’amorçage du système

Une « partition » est, comme son nom l’indique, une partie d’un disque dur. Les partitions permettent de
diviser l’espace de stockage des disques durs en zones indépendantes de taille restreinte, et dans
lesquelles différents systèmes ou différentes données peuvent être stockées de manière totalement
indépendante. L’opération de « partitionnement » est l’opération de création des différentes partitions
d’un disque dur.
L’installation de plusieurs systèmes d’exploitation nécessite souvent d’allouer une partition à chaque
système, car les systèmes d’exploitation ne comprennent généralement pas le format des systèmes de
fichiers les uns des autres. Il est également parfois nécessaire, pour un même système, de définir
plusieurs partitions, qui seront utilisées à des fins spécifiques. Par exemple, Linux fonctionne nettement

29
 Chapitre 4. Installation du système de base

mieux si on lui attribue une partition de « swap » (dite aussi « partition d’échange ») pour stocker des
données peu utilisées qui se trouve en mémoire, lorsqu’il a besoin de plus de mémoire qu’il n’en est
physiquement installée sur la machine. De même, il est possible de créer plusieurs partitions pour séparer
les données utilisateurs des programmes, ce qui permet de faciliter les mécanismes de sauvegarde d’une
part, et d’assurer une plus grande sécurité des données lors des opérations de maintenance du système
d’autre part.
Sur les machines de type PC, chaque disque dur peut être découpé en quatre partitions dites
« primaires ». La position, la taille et le type de ces partitions sont enregistrées dans le premier secteur du
disque dur, que l’on appelle souvent le « Master Boot Record » (« MBR » en abrégé). Le MBR ne
contient que quatre entrées pour la définition des partitions, d’où la limite de quatre partitions primaires.
Le type des partitions est un code numérique qui indique le système d’exploitation capable de l’utiliser et
sa nature (partition de swap ou système de fichiers par exemple). À titre d’exemple, Linux utilise
principalement deux types de partition : les partitions de swap (numéro 82) et les partitions pour les
systèmes de fichiers (type 83).
La définition des partitions se fait donc en donnant leur adresse de départ, leur taille et leur type.
L’adresse de départ et la longueur des partitions sont exprimées en secteurs. Un « secteur » est l’unité de
base pour les données des disques durs, qui correspond à un bloc de 512 octets utiles (auxquels
s’ajoutent bien entendu d’éventuels octets de contrôle d’erreur, mais qui ne sont manipulés que par le
disque dur lui-même et par son contrôleur, et que l’on ne peut donc pas utiliser pour y stocker des
données). Cela dit, certains systèmes (ceux de Microsoft) ne permettent pas une telle finesse dans la
définition des partitions et nécessitent de travailler au niveau du cylindre.

Note : Pour comprendre ce qu’est un cylindre, il faut savoir que les données des disques durs sont
stockées sur les faces magnétiques de plateaux en rotation, au dessus (et en dessous) desquelles
les têtes de lecture/écriture du disque se déplacent radialement. Les données sont donc écrites en
cercles concentriques sur les différents plateaux en raison de leur rotation sous les têtes de lecture
(contrairement aux microsillons et aux CD, il s’agit bien ici de cercles et non d’une spirale car les
têtes de lecture/écriture restent à une position fixe pendant la rotation des plateaux). On appelle ces
cercles des « pistes » (« track » en anglais). Chaque tête accède donc à une piste et une seule à un
instant donné, sur laquelle les secteurs sont enregistrés. Comme toutes les têtes sont solidaires
(elles se déplacent ensemble lorsque l’une d’entre elles doit changer de piste), les différentes pistes
des différents plateaux sont accédées simultanément. L’ensemble de ces pistes, situés à un rayon
donné pour tous les plateaux, constitue ce que l’on appelle un « cylindre ». Les paramètres des
disques durs sont donc exprimés en termes de nombre de têtes, de cylindres et de secteurs par
piste.

30
 Chapitre 4. Installation du système de base

Figure 4-1. Pistes et secteurs d’un disque dur

Vous remarquerez souvent que le nombre de têtes est impair, alors qu’en général, un plateau a deux
faces... Cela est dû au fait que les fabricants de disques durs conservent toujours une face d’un
plateau pour y écrire des données de contrôle permettant aux têtes de lecture/écriture de se
positionner ou pour y placer des pistes complémentaires en cas de zones défectueuses sur la
surface de l’un des autres plateaux.

Bien entendu, la limitation à quatre partitions seulement est extrêmement contraignante, aussi la notion
de partition étendue a-t-elle été introduite. Une « partition étendue » est une partition primaire spéciale,
dans laquelle il est possible de définir jusqu’à 64 sous-partitions. Ces sous-partitions sont appelées des
« partitions logiques ». Les données ne sont jamais stockées dans la partition étendue elle-même, mais
dans ses partitions logiques. On ne peut définir qu’une seule partition étendue sur un disque donné, mais
cela n’empêche pas d’avoir des partitions primaires normales à côté de celle-ci. Il est donc recommandé,
lorsque l’on crée la quatrième partition, de créer une partition étendue et non une partition primaire, afin
de se réserver la possibilité de créer de nouvelles partitions ultérieurement. Il faut toutefois savoir que
certains systèmes ne peuvent pas être installés sur des partitions logiques (notamment DOS et Windows
9x/Millenium), bien qu’ils soient capables d’y accéder une fois qu’ils ont démarré.

Figure 4-2. Partitions primaires et partitions logiques

Outre la table des partitions primaires, le MBR contient un petit programme appelé le « bootstrap
loader » qui permet de charger le premier secteur d’une des partitions primaires. Ce secteur est
communément appelé le « secteur de boot », parce qu’il contient le programme capable de charger le
système d’exploitation. La partition dont le secteur de boot est chargé par le bootstrap loader est appelée
la « partition active ». Il ne peut y avoir qu’une seule partition active à chaque instant : celle du système
d’exploitation principal.

31
 Chapitre 4. Installation du système de base

Généralement, le programme stocké sur le secteur de boot d’une partition a pour but de charger le
système d’exploitation qui y est installé. Cependant, pour certains systèmes d’exploitation, ce
programme est très évolué et permet de lancer d’autres systèmes d’exploitation, éventuellement installés
sur d’autre partitions ou d’autres disques durs. Ces programmes sont alors appelés des « gestionnaires
d’amorçage ». Linux dispose de deux gestionnaires d’amorçage très puissants : le GRUB et LILO.
Windows NT, 2000 ou XP disposent également d’un gestionnaire d’amorçage capable de lancer d’autres
systèmes d’exploitation : NTLDR.
Pour résumer, lors du démarrage d’un PC, le BIOS charge le MBR du premier disque dur en mémoire et
exécute le bootstrap loader. Celui-ci cherche ensuite à charger le secteur de boot de la partition active, et
exécute le gestionnaire d’amorçage qui s’y trouve. Ce gestionnaire peut donner accès aux différents
systèmes d’exploitation, qu’ils soient situés sur d’autres partitions ou même d’autres disques durs. La
manière dont chaque système est lancé dépend bien sûr du système. Il faut donc, en général, lancer
chaque système d’exploitation avec son propre chargeur. Cependant, on peut toujours utiliser un
gestionnaire d’amorçage d’un autre système en rusant quelque peu : il suffit d’indiquer à ce gestionnaire
de charger le secteur de boot de la partition d’installation du système que l’on désire lancer si celui-ci
n’est pas pris en charge directement. Dans ce cas, le gestionnaire d’amorçage ne fait que passer la main
au chargeur de l’autre système. La manière de procéder pour installer LILO, le GRUB ou NTLDR sera
décrite dans la la section intitulée Amorçage du système et configuration multiboot.

Figure 4-3. Master boot record et secteurs de boot

Plan de partitionnement
Avant de se lancer dans l’opération de partitionnement proprement dite, il faut établir un plan de
partitionnement. Cela consiste tout simplement à déterminer la taille et la nature de chaque partition dans
le système. Il est normal, sur un système où seul Linux sera utilisé, de disposer d’au moins trois
partitions :

• une partition de swap, que Linux utilisera pour y stocker temporairement des données lorsqu’il aura
besoin de récupérer un peu de place en mémoire. Il est recommandé de placer cette partition au début
du disque (c’est à dire au plus près du cylindre 0, là où le taux de transfert est le plus rapide) ;
• une partition pour le système de fichiers racine (point de montage /), dans laquelle doit se trouver
l’ensemble des fichiers du système. Cette partition doit se trouver dans les 1024 premiers cylindres
pour que le BIOS puisse y accéder et charger le gestionnaire d’amorçage du système ;
• une partition devant contenir les données des utilisateurs (point de montage /home/).

32
 Chapitre 4. Installation du système de base

L’avantage d’avoir une partition séparée pour toutes les données des utilisateurs est considérable,
puisque dans ce cas on peut mettre à jour le système ou le réinstaller complètement sans avoir à faire de
sauvegarde de ses données. De plus, les fichiers de configuration importants peuvent être sauvegardés sur
cette partition avant la réinstallation, ce qui est extrêmement pratique. Ce type de partitionnement est à
prendre sérieusement en considération, surtout pour les machines de particuliers, sur lesquelles un grand
nombre de programmes peuvent être installés simplement pour les tester. Il n’est donc pas rare, dans ces
conditions, d’avoir à refaire une installation complète pour « nettoyer » rapidement le système.
Toutefois, si l’on ne dispose pas de beaucoup de place sur le disque, il est possible de regrouper la
partition racine et la partition contenant les données utilisateurs. Un mauvais dimensionnement de ces
partitions aura dans ce cas de moins lourdes conséquences (si une partition est pleine, on ne peut pas
facilement utiliser l’espace restant sur les autres partitions).
Si votre machine est destinée à accueillir plusieurs systèmes d’exploitation, il est vivement recommandé
de créer au moins une partition FAT ou FAT32. Cette partition permettra en effet d’échanger des données
entre Linux et les autres systèmes d’exploitation, car les systèmes de fichiers FAT sont reconnus par tous
les systèmes d’exploitation courants. Notez que si Windows NT4 doit être installé, vous devrez créer une
partition FAT plutôt qu’une partition FAT32, car Windows NT ne reconnaît pas, sans programmes
additionnels, les partitions FAT32. Ce problème ne se pose plus pour Windows 2000 et pour XP. Notez
également que bien que Linux sache parfaitement lire les partitions NTFS (utilisées par Windows NT4,
Windows 2000 et par XP), l’écriture sur ces partitions n’est pas complètement implémentée (il n’est
possible que d’écrire dans un fichier existant). Inversement, aucun système Windows ne sait et ne saura
lire les systèmes de fichiers Linux, quels qu’ils soient. De même, les systèmes Windows ne savent pas
accéder à un système de fichiers stocké dans un autre fichier, sans installer d’outils complémentaires
(pour ceux qui disposent de Windows XP, l’outil filedisk ([Link] sera sans
doute relativement utile). Avoir une partition FAT est donc souvent la solution la plus simple pour
échanger des informations entre les deux systèmes.
Si la machine doit être d’une fiabilité absolue ou si vous êtes soumis à des contraintes d’exploitation
fortes, vous pouvez opter pour des solutions radicales qui consistent à séparer les données d’exploitation
(normalement situées dans le répertoire /var/) des fichiers des programmes, et de les placer dans une
partition dédiée. Vous pourrez alors ne monter que cette partition en lecture/écriture. Ainsi, en cas de
crash système, seule la partition contenant les données d’exploitation devra être réparée, ou à l’extrême
rigueur réinitialisée complètement par les scripts de démarrage.
Rien ne vous empêche de créer d’autres partitions si vous le désirez. Sachez cependant que les systèmes
de fichiers de Linux ne sont pas aussi limités que les systèmes de fichiers FAT et FAT32 en ce qui
concerne les tailles maximales des partitions et que, par conséquent, créer une multitude de partitions
n’est pas nécessaire et n’est certainement pas une bonne idée. La création de partitions supplémentaires
peut malgré tout s’avérer nécessaire, par exemple pour y installer d’autres systèmes d’exploitation. Dans
ce cas, vous aurez certainement à créer une partition étendue et des partitions logiques.
La grande difficulté dans l’établissement du plan de partitionnement est de bien déterminer ses besoins
en place disque, aussi bien pour les programmes que pour les données et le swap. Cependant, d’une
manière générale, on peut considérer que ce qui est le plus important pour un particulier, ce sont ses
données, et que le système ne va pas prendre des dizaines de giga-octets sur le disque ! Si vous décidez
de placer les programmes et les données utilisateurs dans deux partitions séparées, vous pouvez
envisager le plan de partitionnement suivant :

33
 Chapitre 4. Installation du système de base

• une partition de swap : deux fois la mémoire vive de l’ordinateur si vous ne disposez pas de beaucoup
d’espace disque, 256 Mo sinon. Il est inutile de consacrer plus de place que cela, car il est très rare
d’avoir besoin de plus de 384 Mo de mémoire virtuelle (la mémoire virtuelle est la somme de la
mémoire libre et de la taille des partitions ou fichiers d’échange). Notez que la règle du double de la
mémoire vive est tout à fait empirique. Elle se base sur le principe que si le système a besoin de plus
de swap, c’est que de toutes façons il n’est pas dimensionné pour ce qu’on lui demande de faire. Cela
dit, vous pouvez mettre autant de swap que vous le désirez si vous en avez réellement besoin (par
exemple pour manipuler de très grandes photos ou des fichiers de très grande taille). Si vous avez un
gros disque, vous pouvez utiliser une très grande partition de swap : elle ne sera quasiment pas
utilisée, mais le jour où vous en aurez besoin, elle sera là. Après tout, abus de bien ne nuit pas...
Sachez toutefois que de toutes façons, si un jour il fallait plus de mémoire virtuelle, vous pourriez
créer un fichier d’échange temporaire ;
• une partition racine, contenant le système, les programmes et les fichiers de configuration : environ 2
Go. Il est possible de travailler avec 1 Go, mais on n’est vraiment pas à l’aise avec XWindow ou si
l’on désire compiler des programmes récupérés sur Internet (ce qui est assez courant). Il est inutile de
dépasser les 3 Go pour cette partition, si l’on a besoin de plus de place, c’est que le répertoire des
données de travail /var/ devient trop gros et dans ce cas on a intérêt à le placer sur une partition qui
lui est dédiée. Notez que l’on a intérêt à placer cette partition au début du disque pour deux raisons :
premièrement, c’est à cet endroit que le disque dur est le plus rapide, et deuxièmement, certains BIOS
ne sont pas capables d’accéder aux cylindres de numéro supérieur à 1024 et ne peuvent donc pas
accéder au gestionnaire d’amorçage du système s’il est installé sur cette partition ;
• une partition pour les répertoires personnels des utilisateurs : le reste de l’espace disponible sur le
disque moins, bien entendu, l’espace nécessaire aux partitions des autres systèmes d’exploitation et
celui d’une éventuelle partition de sauvegarde ou d’échange de données ;
• enfin, si nécessaire, une partition de sauvegarde ou d’échange de données entre les différents systèmes
d’exploitation si l’on désire réaliser une configuration multiboot. Cette partition devra être en FAT16 si
les autres systèmes ne supportent pas les partitions de type FAT32 (par exemple DOS, Windows 95
première édition ou Windows NT4), mais on préférera tout de même la FAT32 si possible (Windows
95OSR2 ou plus, ou Windows 2000 ou XP). Cette partition pourra faire environ 1 Go, soit la taille
nécessaire pour stocker une image disque de CD-ROM plus quelques fichiers complémentaires. Elle
pourra être de taille supérieure si un autre système d’exploitation y est installé.

Note : La partition du système dont on utilise le gestionnaire d’amorçage doit être placée de
préférence avant le cylindre 1024. En effet, certains BIOS ne peuvent pas accéder aux cylindres
suivants, et le bootstrap loader ne peut donc pas charger le gestionnaire d’amorçage du système
dans ce cas. Cela signifie que la deuxième partition doit être la partition du système d’exploitation
principal (cela a en plus l’avantage de donner les accès disque les plus rapides pour les fichiers de
ce système).
Notez que ce plan de partitionnement utilise les quatre entrées de la table des partitions, et ne
permet donc pas d’en ajouter une complémentaire. Si l’on désire installer un autre système
d’exploitation, on pourra le faire sur la partition FAT (auquel cas on pourra lui consacrer plus d’un
giga-octet), soit sur un deuxième disque dur. Si cela ne s’avère pas possible (par exemple parce que
l’on veut installer Windows NT, Windows 2000 ou XP sur une partition NTFS tout en conservant la
partition FAT), on devra créer une partition étendue. Je préconise dans ce cas de placer les deux
dernières partitions (la partition d’échange et la partition des répertoires personnels des utilisateurs)
dans des partitions logiques de cette partition étendue, ce qui laisse libre la troisième partition

34
 Chapitre 4. Installation du système de base

primaire pour un autre système d’exploitation. Bien entendu, ce plan de partitionnement est une
suggestion et vous êtes absolument libre d’en choisir un autre. Je ne le fournis que pour aider ceux
qui ne savent pas comment effectuer leur partitionnement précisément. Il devrait convenir pour tous
les disques de plus de 4 Go, qui sont monnaie courante à présent.

Trouver de la place pour installer le système

L’un des problèmes les plus courants lors d’une nouvelle installation est l’absence de place disponible
sur le disque dur pour placer une partition Linux. Ce problème n’a hélas pas de solution : il faut
supprimer une autre partition appartenant à un autre système, ou en réduire une. Souvent, réduire une
partition revient à sauvegarder les données, la supprimer, la recréer avec une taille inférieure et à
restaurer les données. Certains outils commerciaux permettent de réduire des partitions directement,
mais ils se vendent souvent pour le prix d’un disque dur neuf (je ne peux donc réellement pas conseiller
de les acheter, sauf si vous avez plusieurs disques durs dont les partitions doivent être redimensionnées
ou déplacées !). De plus, Linux dispose également d’un outil similaire qui, bien qu’il soit encore en
phase de développement, permet déjà de réaliser la plupart des opérations que l’on peut avoir à faire sur
les partitions FAT et les partitions EXT2 de Linux. Il s’agit du programme parted, que nous décrirons
ci-après. De même, il existe un programme DOS permettant de réduire la taille d’une partition FAT,
moyennant quelques précautions complémentaires. Bien entendu, il va de soi que si l’on doit déplacer ou
modifier une partition, il faut faire au préalable des sauvegardes de toutes les données de cette partition...
Lorsqu’on installe Linux sur un ordinateur sur lequel un autre système d’exploitation est déjà présent, ce
système est très souvent un système Microsoft (DOS, Windows 9x ou Windows NT/2000/XP). La
plupart de ces systèmes utilisent le système de fichiers FAT sur leur partition. Or ce système de fichiers
est relativement primaire et il est donc possible de redimensionner et de déplacer facilement les partitions
sur lesquelles il est utilisé. En revanche, si le système de fichiers utilisé est de type NTFS (ce système de
fichiers n’est disponible qu’avec Windows NT, Windows 2000 ou XP), aucune méthode simple ne
permet de le redimensionner.
Il est possible que votre distribution dispose d’un outil graphique permettant de manipuler les partitions
existantes pendant la phase d’installation. Ce type d’outil pourra être utilisé pour dégager de la place
pour Linux, éventuellement en réduisant une partition existante. Nous ne décrirons cependant pas ces
outils ici, car ils sont spécifiques à chaque distribution. En revanche, nous présenterons les deux
principales techniques permettant de redimensionner une partition, la première fonctionnant sous Linux
et la deuxième sous DOS.

Utilisation de parted
L’utilitaire GNU parted est le standard en ce qui concerne les manipulations de partitions sous Linux.
Cet outil s’utilise en ligne de commande, et peut donc être utilisé à partir d’un terminal en mode texte
pendant la phase d’installation, si votre distribution l’inclut avec ses outils d’installation standards. Si ce
n’est pas le cas, vous pourrez récupérer l’image d’une disquette de boot Linux contenant cet outil à
l’adresse [Link] Cette image pourra être copiée sur une
disquette à l’aide de l’utilitaire DOS [Link], de la même manière que les disquettes de boot de
votre distribution peuvent être créées. La manière de procéder a été décrite dans la la section intitulée
Amorçage.

35
 Chapitre 4. Installation du système de base

Une fois que vous aurez démarré Linux et obtenu un terminal fonctionnel, vous pourrez lancer parted
avec la simple commande suivante :

parted disque

où disque est l’identifiant du disque dur sur lequel la partition à modifier se trouve. Comme on l’a vu
précédemment, tous les périphériques sont accessibles par l’intermédiaire de fichiers spéciaux placés
dans le répertoire /dev/. Le nom des fichiers spéciaux correspondants à vos disques peut varier selon
leur nature. Ainsi, les disques et les lecteurs de CD IDE sont accessibles par l’intermédiaire des fichiers
spéciaux /dev/hda, /dev/hdb, /dev/hdc, etc. Ces fichiers permettent d’accéder respectivement au
disque maître du premier contrôleur IDE, au disque esclave de ce même contrôleur, puis au disque maître
du deuxième contrôleur IDE puis au disque esclave du deuxième contrôleur IDE, etc. Ainsi, si vous ne
disposez que d’un disque, il doit normalement être connecté sur le premier contrôleur IDE et être maître.
Dans ce cas, vous y accéderez par le fichier spécial /dev/hda. Pour les disques SCSI, les noms sont
légèrement différents : ils sont nommés /dev/sda, /dev/sdb, etc. La modification des partitions du
premier disque dur IDE se fera donc à l’aide de la commande suivante :

parted /dev/hda

Note : À partir de la version 2.4.0 du noyau de Linux, le répertoire /dev/ peut être généré par le
noyau, dans un système de fichiers virtuel. L’organisation de ce répertoire est dans ce cas différente
de l’organisation classique, et les noms de fichiers spéciaux correspondants aux disques peuvent
être différents de ceux indiqués ci-dessus. Par exemple, le chemin du fichier spécial permettant
d’accéder au premier disque IDE sera /dev/ide/host0/bus0/target0/disc. Comme vous pouvez
le constater, la représentation de la machine dans le système de fichiers virtuels est plus structurée,
mais également plus compliquée. Afin de simplifier ces mécanismes, il est d’usage de placer des
liens symboliques dans le répertoire /dev/ permettant d’accéder aux fichiers spéciaux de
périphériques avec leurs anciens noms. Vous n’aurez donc normalement pas à vous soucier de
savoir si votre noyau utilise ou non le système de fichiers virtuels /dev/, et les chemins utilisés dans
la suite de ce document seront les chemins classiques. Vous devrez faire la traduction vers les
chemins du système de fichiers virtuels vous-même si vous ne voulez pas utiliser ces liens
symboliques.

parted dispose de plusieurs commandes permettant de modifier les partitions. À l’heure actuelle, il ne
permet réellement de travailler que sur les partitions FAT et les partitions contenant un système de
fichiers EXT2, EXT3 ou ReiserFS. Seul les fonctionnalités de manipulation des partitions FAT nous
intéressent ici, car nous devons réduire une partition FAT.
La première commande indispensable est la commande print, qui permet d’afficher la table des partitions
du disque courant. Les informations affichées par cette commande se présentent de la manière suivante :

Disk geometry for /dev/hda: 0.000-32634.492 megabytes

Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 32632.031 primary FAT lba

Comme vous pouvez le constater, les partitions sont décrites à raison d’une ligne par partition. Cette
ligne contient le numéro de la partition (les quatre premiers numéros étant affectés aux partitions

36
 Chapitre 4. Installation du système de base

primaires), les points de départ et de fin de ces partitions, exprimés en mégaoctets, le type de la partition,
le système de fichiers de cette partition, et des indications complémentaires.

Note : Comme il l’a déjà été expliqué ci-dessus, les partitions sont généralement décrites en terme
de cylindres. parted préfère utiliser le mégaoctet comme unité, ce qui est généralement plus clair. Il
prend complètement en charge la traduction des informations de taille en termes plus physiques, en
tenant compte des éventuels problèmes d’alignement aux limites de cylindre. Son utilisation est donc
relativement directe.

La commande qui nous intéresse le plus ensuite est la commande resize, qui permet de redimensionner
une partition. Cette commande utilise la syntaxe suivante :

resize partition début fin

où partition est le numéro de la partition tel qu’il est présenté dans la première colonne des
informations de la commande print, début est la nouvelle position où la partition commencera et fin
est la nouvelle limite de cette partition. Comme vous pouvez le constater, il est possible de réduire une
partition aussi bien par son début que par sa fin ! La seule contrainte est, bien entendu, que cette partition
reste suffisamment grande pour contenir l’ensemble de ses données. Par exemple, pour réduire de 8 Go la
première partition du disque dur de l’exemple précédent afin d’y placer la partition de swap et les
systèmes de fichiers, on utiliserait la commande suivante :

resize 1 8192 32632.031

Note : L’opération de redimensionnement peut prendre un certain temps. En effet, parted doit
déplacer les données qui se trouveraient en dehors de la partition après son redimensionnement si
aucune mesure spéciale n’était prise, et il doit reconstruire complètement la FAT de cette partition
pour qu’elle soit cohérente avec le nouvel emplacement de ces données.
Il est impératif de désactiver la limite utilisateur concernant la taille maximale des fichiers manipulés
avant d’effectuer la moindre opération sur les partitions. En effet, cette limite pourrait empêcher
parted d’accéder aux données situées au-delà d’une certaine position dans la partition. Pour
désactiver cette limite, il faut taper la commande suivante avant de lancer parted :

ulimit -f unlimited

Si vous désirez déplacer une partition plutôt que de la redimensionner, vous pouvez utiliser la commande
move :

move partition début

où partition est le numéro de la partition et début est son nouvel emplacement de départ, exprimé en
mégaoctets. De même, si vous désirez copier une partition, la commande cp devra être utilisée. Cette
commande suit la syntaxe suivante :

37
 Chapitre 4. Installation du système de base

cp [disque] source destination

où disque est le disque dur où se trouve la partition source, source est le numéro de cette partition, et
destination est le numéro de la partition destination. La partition destination est toujours située sur le
disque dur courant (c’est-à-dire celui qui a été indiqué en ligne de commande lors du lancement de
parted ou celui spécifié par la commande select de parted).
Enfin, une fois que toutes les manipulations sur les partitions auront été effectuées, vous pourrez quitter
parted avec la simple commande quit. Vous pourrez obtenir la liste des autres commandes acceptées par
parted en tapant la commande help.

Utilisation de fips
fips (abréviation de l’anglais « First Interactive Partition Splitter ») est un utilitaire similaire à parted, à
ceci près qu’il fonctionne sous DOS et qu’il ne permet que de réduire la limite supérieure d’une partition
FAT. De plus, cet utilitaire est incapable de réorganiser le système de fichiers à l’issue de la réduction de
la taille de la partition. Il est donc nécessaire de défragmenter le système de fichiers avant d’utiliser ce
programme, afin de placer toutes ses données au début de la partition.

Note : Vérifiez bien les options du défragmenteur de système de fichiers que vous utilisez : quelques
outils consolident bien l’espace libre mais placent certains fichiers à la fin de la partition FAT pour
laisser plus de place aux fichiers les plus utilisés au début du disque, afin d’optimiser le débit de
données sur ces fichiers (c’est notamment le cas avec le défragmenteur de Norton). Il faut
impérativement désactiver ce type d’option avant de réduire la partition, faute de quoi vous perdriez
définitivement les fichiers qui se trouvent à la fin de la partition et votre FAT serait dans un état
incohérent.

Une fois la défragmentation réalisée, fips peut être utilisé pour réduire la taille de la partition FAT. La
plupart des distributions de Linux fournissent des utilitaires DOS sur leur CD-ROM d’installation,
généralement dans le répertoire dosutils. C’est là que vous pourrez sans doute trouver fips. Attention,
vous devrez impérativement utiliser la version 2.0 de fips pour manipuler les FAT32 et FAT32X.
La réduction de la taille d’une partition se fait en modifiant la variable qui contient la taille de la partition
dans la table des partitions. Pour cela, vous devrez simplement lancer fips. Celui-ci vous présentera alors
la liste des disques durs installés sur votre système, et vous devrez lui indiquer le disque sur lequel la
partition à réduire se trouve. Il vous demandera ensuite la partition que vous désirez réduire, puis le
cylindre auquel cette partition devra se terminer. Lorsque vous aurez déterminé la nouvelle taille de cette
partition, vous devrez presser la touche ’c’ pour poursuivre. fips vous demandera alors confirmation
avant d’écrire sur disque les nouvelles informations de partition. Si vous êtes sûr de vous, vous pouvez
répondre par l’affirmative en pressant la touche ’y’.

Note : Contrairement à parted, fips ne reconstruit pas la table d’allocation des fichiers (la « FAT »)
après avoir réduit la taille de la partition, ce qui fait que cette dernière est trop grosse pour cette
nouvelle taille après réduction. Cela n’est pas gênant, seuls quelques mégaoctets seront perdus sur
la partition FAT dans la FAT elle-même. Cette technique a en revanche l’avantage d’être
extrêmement rapide.

38
 Chapitre 4. Installation du système de base

Utilisation de fdisk
Le partitionnement en soi peut se faire soit directement à l’aide du fdisk de Linux, soit par
l’intermédiaire du programme d’installation de la distribution correspondante. Il est recommandé
d’utiliser ce programme d’installation, qui vous guidera et vous indiquera comment réaliser cette
opération. Si toutefois vous désirez utiliser fdisk, il vaut mieux faire attention à ce que vous faites. Pour
lancer fdisk, il suffit de taper la commande suivante en ligne de commande :

fdisk disque

où disque est le fichier spécial de périphérique représentant le disque que vous désirez partitionner. Si
vous voulez partitionner le disque maître du premier contrôleur IDE, vous devrez donc taper :

fdisk /dev/hda

Si vous ne spécifiez aucun disque en paramètre à fdisk, il prendra par défaut le disque /dev/sda, ou
/dev/hda si aucun disque SCSI n’est installé.

fdisk est un programme très peu interactif. Il attend que vous lui communiquiez les commandes à
exécuter en tapant sur une lettre. Les différentes commandes possibles peuvent être affichées avec la
commande ’m’.
Lorsque vous créez une partition, vous devez utiliser la commande ’n’, puis indiquer son type avec les
commandes ’p’ (pour « primary ») pour une partition primaire ou ’e’ (pour « extended ») pour une
partition étendue. Vous devrez ensuite donner son numéro dans la table des partitions, puis indiquer le
début et la fin de la partition. Par défaut, l’unité utilisée par fdisk est le cylindre. Il est recommandé de
conserver cette unité, surtout si l’on utilise un système qui ne sait manipuler que les cylindres. Toutefois,
on peut changer cette unité grâce à la commande ’u’ et utiliser le secteur comme unité.
Si vous avez créé une partition étendue, celle-ci sera utilisée pour y stocker des partitions logiques. Pour
pouvoir les créer, il faut encore utiliser la commande ’n’, et choisir le type de partition logique avec la
commande ’l’ (pour « logical »). Les partitions logiques sont numérotées avec les nombres 5 et suivants.
La création des partitions logiques se fait exactement de la même manière que les partitions primaires, en
spécifiant leur début et leur fin, soit en cylindres, soit en secteurs selon l’unité courante.
Une fois les partitions créées, vous pouvez spécifier leur type à l’aide de la commande ’t’ (pour
« type »). Cette commande demande successivement le numéro de la partition à modifier et la valeur de
son identificateur en hexadécimal. Rappelons que les identificateurs à utiliser pour Linux sont 83 pour les
partitions de systèmes de fichiers Linux, et 82 pour les partitions de swap. La liste des valeurs
admissibles peut être obtenue à l’aide de la commande ’l’. Par défaut, le fdisk de Linux crée des
partitions Linux natives, de code 83.
Lorsque vous aurez complètement défini vos partitions, il ne vous restera plus qu’à activer la partition
qui contiendra le gestionnaire d’amorçage. La sélection de la partition active se fait avec la commande
’a’ de fdisk. C’est donc sur cette partition que le chargeur du MBR ira chercher le gestionnaire
d’amorçage du système à lancer.

Note : Théoriquement, il est tout à fait possible d’installer le gestionnaire d’amorçage d’un système
directement sur le MBR, mais procéder de cette manière est très déconseillé. En effet, certains
systèmes d’exploitation (notamment tous les systèmes de Microsoft) écrasent systématiquement le
MBR lorsqu’ils s’installent, détruisant ainsi le chargeur d’un autre système qui y serait

39
 Chapitre 4. Installation du système de base

éventuellement installé. Cela implique que si l’on désire installer un gestionnaire d’amorçage autre
que celui des systèmes Microsoft sur le MBR, il faut le faire après l’installation de ces systèmes. En
pratique, cela veut dire que dans ce cas, on doit installer Linux après Windows ou le DOS.
Notez qu’il n’est toutefois pas toujours faisable d’installer le gestionnaire d’amorçage sur le secteur
de boot de la partition de son système, en particulier si cette partition ne se trouve pas sur le premier
disque dur de la machine. En effet, la plupart des BIOS sont incapables d’utiliser les MBR des autre
disques durs. Dans ce cas, on peut soit créer une partition de démarrage de petite taille (quelques
méga-octets, un cylindre au maximum) au début du disque et sur laquelle on installera le
gestionnaire d’amorçage et éventuellement quelques outils de réparation en cas de coup dur, soit
installer le gestionnaire d’amorçage directement sur le MBR du premier disque dur. Dans ce cas, on
devra faire particulièrement attention à l’ordre d’installation des systèmes d’exploitation. De manière
générale, il faut toujours installer les systèmes Microsoft en premier (respectivement dans l’ordre
suivant si l’on veut éviter les problèmes : DOS, Windows 9x/Millenium et Windows NT4/2000/XP).
Nous verrons plus loin comment installer le gestionnaire d’amorçage de Linux et faire une
configuration multiboot avec les principaux autres systèmes d’exploitation existants.

Création des systèmes de fichiers

Une fois le disque correctement partitionné, il faut créer les systèmes de fichiers. Cette opération n’est
pas nécessaire pour les partitions de swap, cependant il faut le faire pour les autres partitions. Attention !
Dans le monde du DOS et de Windows, la création d’un système de fichiers est l’opération de
« formatage » d’une partition. Le terme de formatage est très mal employé dans ce sens, car il n’y a
strictement rien à voir entre le formatage d’un disque, qui est l’opération consistant à enregistrer des
marques sur le support magnétique pour définir les pistes et les secteurs du disque, et la création du
système de fichiers d’une partition, qui consiste à enregistrer les structures de données permettant de
retrouver les fichiers dans cette partition. Le formatage est normalement effectué par le fabricant du
disque, et a lieu avant le partitionnement. En effet, partitionner un disque suppose qu’il existe déjà des
pistes et des secteurs sur le disque. C’est pour cette raison que l’on ne parlera ici que de création de
systèmes de fichiers.
La création des systèmes de fichiers EXT2 et EXT3 se fait avec la même commande, à savoir la
commande mke2fs. La création des autres systèmes de fichiers se fait généralement de la même manière
que pour ces systèmes, mais avec des outils différents. Par exemple, la création d’un système de fichiers
ReiserFS se fait à l’aide de l’outil mkreiserfs. ReiserFS constitue une alternative possible à EXT3 car,
tout comme EXT3, il prend en charge les mécanismes de journalisation qui assurent la cohérence du
système de fichiers même en cas d’arrêt intempestif de l’ordinateur. Cependant, ce système de fichiers
est encore jeune et n’a certainement pas été débogué autant que EXT3, qui s’appuie sur la base de code
du vieux système de fichiers EXT2. Sachez également que ReiserFS, contrairement à EXT2 et à EXT3,
ne se comporte pas encore très bien si le disque dur a des secteurs physiques défectueux. La suite de
cette section ne traitera que des systèmes de fichiers EXT2 et EXT3, consultez la documentation de votre
distribution et les pages de manuel des outils des autres systèmes de fichiers pour plus de détails sur la
méthode à utiliser pour les créer.
Afin de pouvoir utiliser mke2fs correctement, il est nécessaire de définir quelques termes, et d’expliquer
à quelles notions d’EXT2 et d’EXT3 ils se réfèrent.

40
 Chapitre 4. Installation du système de base

Premièrement, le système de fichiers EXT2 travaille, comme la plupart des systèmes de fichiers, avec des
blocs de taille fixe (« clusters » en anglais). Cela signifie que l’allocation de l’espace disque se fait par
multiples de la taille de ces blocs : il est impossible de demander seulement une partie d’un bloc. Cette
technique présente des avantages et des inconvénients. Essentiellement, l’avantage est la rapidité
engendrée par la simplification des mécanismes d’allocation et de libération d’espace disque.
L’inconvénient majeur est évidemment qu’on perd de la place pour tous les fichiers qui ne tiennent pas
dans un nombre entier de blocs, puisqu’il faut allouer un bloc supplémentaire qui sera partiellement
utilisé. En moyenne, on perd la moitié d’un bloc par fichier, ce qui ne peut être réduit qu’en limitant la
taille des blocs à une valeur relativement faible.

Note : EXT2 et EXT3 gèrent l’allocation et la libération des blocs de manière à toujours trouver le
meilleur bloc à allouer pour créer un fichier. Ainsi, il limite la fragmentation des fichiers à son strict
minimum, ce qui rend inutiles les programmes de défragmentation de systèmes de fichiers.

Deuxièmement, EXT2 et EXT3 utilisent des structures de données appelées « inodes » pour définir les
fichiers. Un inode contient la plupart des informations d’un fichier, à savoir :

• son propriétaire et son groupe ;

• ses droits d’accès ;
• ses dates de création, modification, accès ;
• les blocs qu’il utilise ;
• d’autres informations utilisées par EXT2.

Ces inodes sont stockés dans une table du système de fichiers, ce qui permet d’accéder très rapidement à
toutes ces informations et de retrouver également très simplement le ou les blocs contenant les données
du fichier. Le problème est ici que cette table a un nombre d’entrées limité, ce qui implique un nombre
limité de fichiers dans le système de fichiers. Plus cette table est grande, plus le nombre de fichiers que
l’on pourra créer sera grand, et inversement. Il faut donc trouver un compromis entre la taille de cette
table et le nombre de fichiers que l’on est susceptible de créer. Il va de soi qu’en général, les grandes
partitions contiennent plus de fichiers, mais que la table d’inodes peut également avoir une taille
supérieure sans que cela soit dérangeant. Par conséquent, il est relativement courant de définir le taux
d’inode par bloc ou, autrement dit, la proportion d’inodes dans la partition par rapport à sa taille.
Toutes ces informations (blocs libres et inodes) sont sauvegardées à plusieurs endroits dans la partition,
ce qui permet de disposer en permanence de copies de la structure du système de fichiers. De cette
manière, il est relativement simple de réparer un système de fichiers endommagé, même si les données
sont détruites en raison d’une erreur matérielle (secteurs défectueux sur le disque dur par exemple).
Chacune de ces copies s’appelle un groupe de blocs. Chaque groupe de blocs contient un bloc particulier,
le « super bloc », qui contient la description de son groupe.
Lors de la création du système de fichiers, il est nécessaire d’indiquer la taille d’un bloc en octets. Cette
taille doit impérativement être un multiple de la taille d’un secteur du support physique de données,
parce que les blocs ne peuvent contenir qu’un nombre entier de secteurs. Pour un disque dur, la taille des
secteurs est fixée à 512 octets, ce qui fait que la taille d’un bloc est au moins de 512 octets. De même, il

41
 Chapitre 4. Installation du système de base

faut spécifier le nombre d’inodes de la partition. Il est possible de spécifier ce nombre soit directement,
ou d’indiquer seulement le nombre d’octets de la partition par inode. Le nombre total d’inodes utilisé
sera alors calculé à partir de ce nombre d’octets et de la taille de la partition. Bien entendu, le nombre
maximal d’inodes possibles est le nombre total de blocs, puisque tout fichier non vide requiert au moins
un bloc et que chaque inode caractérise un fichier. Si vous ne savez pas quelles valeurs prendre, vous
pouvez utiliser des blocs de 1024 octets (2 secteurs), et un rapport de 4096 octets par inode (donc de 4
blocs de 1 Ko par inode).
Le système de fichiers EXT3 gère, en plus de tout ce que sait faire le système de fichiers EXT2, un
journal contenant les opérations à réaliser de manière transactionnelle sur le disque dur. Ces opérations
sont exécutées de telle sorte que la structure du système de fichiers reste cohérente en toutes
circonstances. Cela implique que le système de fichiers est toujours valide, même si une panne de
courant se produit pendant une opération disque.
La syntaxe de la commande mke2fs est donnée ci-dessous :

mke2fs [-j] fichier

où fichier est le nom du fichier spécial de périphérique représentant la partition sur laquelle le système
de fichiers doit être créé. Ce nom est le nom du disque dur, suffixé du numéro de la partition. Les
numéros de partitions commencent à 0, si bien que la première partition du premier disque dur IDE sera
référencée par le chemin /dev/hda0. L’option -j quant à elle est facultative. Lorsqu’elle est utilisée, le
système de fichiers créé est un système de fichiers EXT3. Il est recommandé d’utiliser cette option pour
tous les systèmes de fichiers dont on voudra garantir la cohérence, par exemple pour les systèmes de
fichiers devant contenir des documents ou des informations importantes. Sachez cependant que la
journalisation peut dégrader sensiblement les performances de votre ordinateur, aussi pouvez-vous vous
en passer sur les partitions pour lesquelles un débit élevé est nécessaire (par exemple pour les partitions
devant servir à manipuler des fichiers vidéo).

Note : Le système de fichiers EXT3 utilise les mêmes structures de données que le système de
fichiers EXT2. Il est donc parfaitement compatible avec ce dernier, et un système de fichiers EXT3
peut être utilisé comme un système de fichiers EXT2. En réalité, les mécanismes de journalisation
peut être activés ou non lors de l’opération de montage du système de fichiers, en fonction du type
de système de fichiers indiqué à la commande de montage. Nous détaillerons la manière de monter
les systèmes de fichiers dans la la section intitulée Montage des systèmes de fichiers dans Chapitre
6 et dans la la section intitulée Configuration du montage des systèmes de fichiers dans Chapitre 6.
Pour les mêmes raisons, il est possible de convertir un système de fichiers EXT2 en système de
fichiers EXT3 a posteriori, à l’aide de l’option -j de la commande tune2fs. Cette commande permet
d’activer et de désactiver des fonctionnalités complémentaires pour ces systèmes de fichiers, dont la
journalisation fait partie.

Invoquée sans autres options, la commande mke2fs prend des valeurs par défaut pour tous les paramètres
du système de fichiers créé, mais vous pouvez également spécifier d’autres valeurs. La taille des blocs
peut être indiquée en octets avec l’option suivante :

mke2fs [-j] -b taille fichier

où taille représente la taille d’un bloc en octets. De même, le nombre d’octets par inode peut être
précisé avec l’une des options -i :

42
 Chapitre 4. Installation du système de base

mke2fs [-j] -i octets fichier

où octets est le rapport de la taille de la partition en octets par le nombre d’inodes à créer. Il est
possible d’indiquer directement ce nombre avec la commande suivante :

mke2fs [-j] -N nombre fichier

Enfin, sachez que l’option -c permet de demander à mke2fs d’effectuer une vérification des secteurs
défectueux du disque dur avant de créer le système de fichiers. Il est fortement recommandé d’utiliser
cette option lors de la première création d’un système de fichiers.

Création de la partition de swap

En cas de manque de mémoire vive, Linux peut utiliser une partie du disque dur pour y stocker les
données temporairement inutilisées afin de libérer de l’espace mémoire. Cette opération permet de
continuer à travailler, même si la machine ne dispose pas de suffisamment de mémoire vive pour
exécuter tous les processus dont elle a la charge. L’inconvénient de cette méthode est évidemment la
dégradation des performances, mais c’est un bon compromis si l’on considère le prix du méga-octet de
mémoire par rapport à celui des disques durs d’une part, et le fait qu’il vaut mieux parvenir à faire son
travail, même lentement, que de ne pas le faire du tout.
L’espace disque consacré par Linux pour ce stockage temporaire est appelé « swap », du terme anglais
« to swap » qui fait référence à l’échange des données de la mémoire vers le disque dur (et inversement,
lorsqu’elles sont rechargées en mémoire). Linux est capable de gérer plusieurs formes de swap. Il est
capable d’utiliser des fichiers d’échange, qui sont stockés dans un système de fichiers, ou les partitions
de swap. Ces dernières ont l’avantage d’être bien plus rapides, puisque le noyau n’a pas à se préoccuper
de la structure du système de fichiers lors des opérations de swap (qui, rappelons-le, constituent déjà un
ralentissement notable de la machine). En revanche, elles ont l’inconvénient majeur d’être très
contraignantes, puisqu’elles nécessitent de réserver une partition pour le swap de manière permanente.
Cependant, il est tout à fait acceptable de consacrer 128 ou 256 Mo de disque dur pour une partition de
swap de nos jours. Linux est capable de gérer jusqu’à 8 partitions de swap dont la taille peut aller jusqu’à
2 Go chacune, plus les fichiers d’échange que l’on peut rajouter ultérieurement. Nous ne décrirons que la
manière de créer une partition de swap, car les fichiers d’échange ne constituent plus le meilleur
compromis avec les tailles de disques que l’on rencontre de nos jours.
Bien entendu, le programme d’installation de votre distribution prend certainement déjà en charge la
création des partitions de swap. Il est donc recommandé, encore une fois, d’utiliser ce programme, même
si la description qui suit vous permettra de comprendre ce dont il s’agit.
Les partitions de swap peuvent être créées, comme toutes les partitions, à l’aide du programme fdisk. En
fait, la seule distinction entre une partition de swap et une partition réservée à un système de fichiers est
tout simplement son identificateur. Comme on l’a déjà vu lors du partitionnement du disque,
l’identificateur utilisé pour les partitions de systèmes de fichiers Linux est 83, et celui pour les partitions
de swap est 82. Vous devrez donc affecter cet identificateur à votre partition de swap lorsque vous
partitionnerez votre disque dur. Il est recommandé de placer la partition de swap au début du disque dur,
car c’est à cet emplacement que le taux de transfert est le plus élevé (et donc c’est à cet emplacement
qu’on obtiendra les meilleures performances en cas de manque de mémoire vive).

43
 Chapitre 4. Installation du système de base

Une fois créée, la partition de swap peut être préparée pour que le noyau puisse l’utiliser. Cette
préparation revient à peu près à formater un système de fichiers, à ceci près que les structures de données
écrites dans la partition de swap sont beaucoup plus simples car il ne s’agit plus ici de stocker une
arborescence complète de fichiers. La commande mkswap permet de préparer les partitions pour être
utilisées en tant que partition de swap. Elle s’utilise selon la syntaxe suivante :

mkswap -c partition

où partition est la partition à préparer pour le swap. Notez que, en réalité, mkswap peut tout aussi
bien travailler sur un fichier que sur une partition.
Lorsque la partition aura été préparée pour le swap, il est possible de demander à Linux de l’utiliser avec
la commande suivante :

swapon partition

où partition est la partition de swap à utiliser. Cette zone de swap est alors automatiquement prise en
compte par le système. La commande suivante permet d’arrêter le swapping sur une partition :

swapoff partition

Normalement, vous n’aurez jamais à utiliser ces commandes manuellement. Le programme d’installation
de votre distribution configure le swap, et fait en sorte que les partitions de swap sont chargées
automatiquement lors du démarrage de la machine. Notez cependant que cette méthode de configuration
dynamique permet d’ajouter temporairement un fichier d’échange si les besoins s’en font sentir, sans
avoir à redémarrer la machine.

Installation des composants de base

Si vous êtes arrivé jusqu’ici, vous avez fini les opérations les plus risquées et sans doute les plus
difficiles. Dans les premiers jours de Linux, il fallait installer à la main les différents composants du
système, voire les recompiler soi-même. Heureusement, toutes les distributions actuelles disposent
aujourd’hui de programmes d’installation du système de base, qui simplifient beaucoup le travail. Les
opérations que vous allez réaliser à présent sont donc plus simples, et certainement moins dangereuses.
L’ordre logique est évidemment de commencer par les couches les plus basses du système, donc en
particulier le noyau. Cependant, il faut également installer le shell et les outils complémentaires, puisque
sans eux on ne peut strictement rien faire de ce noyau. Cet ensemble de programme constitue ce que l’on
appelle le système de base. Je suggère de configurer correctement le système à ce stade, avant de se
lancer dans l’aventure XWindow. C’est évidemment cette partie qui sera la plus difficile à réaliser.
L’installation de XWindow ne devrait alors pas causer de problème majeur. Une fois ces opérations
réalisées, vous pourrez installer les applications. En général, lorsque le système est bien configuré,
l’installation des applications est une tâche relativement facile et se fait rapidement. Ce document ne
traitera pas en détail de l’installation des applications, car il y en a trop pour que l’on puisse donner des
informations valides pour toutes les applications. Quelques règles générales seront malgré tout données,
car elles peuvent s’appliquer pour certaines applications.

44
 Chapitre 4. Installation du système de base

Toutes les distributions organisent les différents composants logiciels qu’elles fournissent en paquetages
(« package » en anglais). Ainsi, l’installation du système se fait par groupes homogènes de fichiers, et le
regroupement dans un paquetage est généralement une dépendance forte (en pratique, ce sont les fichiers
d’une même application). En installant un paquetage, on installe finalement un logiciel particulier.
Cependant, certains paquetages dépendent d’autres paquetages, par exemple, les paquetages contenant le
système de base sont évidemment utilisés par tous les autres paquetages. Les programmes d’installation
gèrent relativement bien les dépendances et les conflits entre paquetages, si bien que l’installation peut
maintenant se faire sans trop de problèmes.
Afin d’organiser un peu tous ces paquetages, les distributions les trient souvent par « séries ». Une série
n’est rien d’autre qu’un ensemble de paquetages regroupés par domaine fonctionnel. Cela signifie que
l’on peut facilement retrouver un paquetage donné, en allant le chercher dans la série contenant tous les
paquetages fonctionnellement proches. Le regroupement des paquetages en séries ne signifie absolument
pas que tous les paquetages de la série doivent être installés pour obtenir une fonctionnalité donnée, mais
que les logiciels qui s’y trouvent ont plus ou moins trait à cette fonctionnalité. En fait, il peut même y
avoir redondance ou conflit entre deux paquetages d’une même série. Dans ce cas, il faut choisir l’un ou
l’autre, selon ses besoins personnels.
Certains paquetages sont indispensables pour le système, d’autres sont purement optionnels. Mais la
plupart des paquetages sont simplement les paquetages des applications, et vous devrez faire le tri et
choisir ceux qui vous intéressent parce qu’il est impensable d’installer tous les paquetages (une
distribution de Linux peut faire 5 ou 6 CD-ROM, en tenant compte du système, des applications et des
sources). Les seuls paquetages qu’il faut impérativement installer sont les paquetages de la série de base.
En général, cette série porte le nom A, ou AAA, ou quelque chose de similaire, afin qu’elle puisse
toujours être en tête de liste dans les programmes d’installation. Cette série comprend au moins les
paquetages des commandes Unix de base, du shell, du programme d’installation et de tous les fichiers
nécessaires au fonctionnement du système (fichiers de configuration, scripts et bibliothèques partagées).
Tant que les programmes de cette série sont intacts et fonctionnels, le système est utilisable. S’il en
manque, les problèmes peuvent survenir à tout moment : de l’absence ou l’indisponibilité de la
documentation à l’impossibilité complète de démarrer le système.
Le choix des paquetages à installer est crucial mais non définitif. En effet, si vous avez installé un
paquetage dont vous n’avez pas ou plus besoin, rien ne vous empêche de le supprimer par la suite. De
même, si vous vous apercevez que vous avez oublié d’installer un paquetage dont vous avez besoin, vous
pouvez l’installer ultérieurement.
Il n’est pas possible de donner ici la liste des paquetages que vous devez installer, car cette liste dépend
beaucoup trop de la distribution que vous possédez. Il est conseillé de lire le manuel de cette distribution
ou de bien lire les écrans d’aides du programme d’installation. Cependant, les paquetages dont vous
aurez certainement besoin pour poursuivre l’installation sont sans doute les suivants :

• paquetage du système de base ;

• paquetage du compilateur GCC ;
• paquetage du réseau ;
• paquetage de XWindow ;
• paquetage de documentation ;
• paquetages susceptibles de faire fonctionner votre matériel (carte son, serveur XWindow approprié à
votre carte graphique...).

45
 Chapitre 4. Installation du système de base

Gardez à l’esprit que dans le monde du logiciel libre, les programmes sont souvent distribués sous la
forme de fichiers sources et que vous aurez sans doute besoin des outils de développement pour les
compiler et les installer. Veillez donc à inclure d’office tous ces outils, même si vous ne désirez pas
programmer personnellement. Bien entendu, vous pourrez revenir ultérieurement dans le programme
d’installation et réinstaller un paquetage si vous l’avez oublié pendant la phase d’installation.

Amorçage du système et configuration multiboot

Lorsque vous aurez installé votre système de base, vous devrez faire en sorte qu’il puisse démarrer. Pour
cela, il existe plusieurs possibilités, les principales étant les deux suivantes :

• soit vous démarrez à partir d’une disquette ou d’un CD d’amorçage ;

• soit vous utiliser un gestionnaire d’amorçage.
Il va de soi que c’est la deuxième solution qui est recommandée. Cependant, la première solution pourra
être utile si d’aventure votre MBR se trouvait être écrasé ou endommagé. Seule l’utilisation des
gestionnaires d’amorçage de Linux et de Windows NT/2000 et XP sera décrite ici.
Le gestionnaire d’amorçage le plus utilisé sous Linux se nomme « LILO » (pour « LInux LOader »).
LILO permet de démarrer un grand nombre de systèmes, dont DOS, Windows 95/98/Millenium,
Windows NT/2000/XP et OS/2. Linux dispose également d’un autre gestionnaire d’amorçage également
très performant : le « GRUB » (abréviation de l’anglais « GRand Unified Bootloader »). Vous êtes libre
de choisir celui que vous voulez. Le GRUB est quelque peu plus moderne que LILO, mais le choix du
gestionnaire d’amorçage est ici une question de goût. Windows NT, Windows 2000 et Windows XP
disposent également d’un gestionnaire d’amorçage nommé « NTLDR », capable de démarrer d’autres
systèmes d’exploitation. Vous aurez donc également la possibilité d’utiliser ce gestionnaire à la place de
LILO ou du GRUB si un de ces systèmes est installé sur votre machine.
Quel que soit le gestionnaire d’amorçage que vous désirez utiliser, il vous faudra activer la partition sur
laquelle il est installé. Cette opération peut être réalisée à l’aide de l’utilitaire fdisk et a déjà été décrite
dans la la section intitulée Partitionnement du disque. Cela permettra au bootstrap loader de sélectionner
le secteur de boot de cette partition et de lancer le gestionnaire d’amorçage qui y est installé. Bien
entendu, cela suppose que ce gestionnaire soit installé sur cette partition, ce qui est normalement le cas
(rappelons qu’il n’est en général pas conseillé d’installer le gestionnaire d’amorçage directement sur le
MBR du disque dur).

Réalisation d’un multiboot avec LILO

LILO est un gestionnaire d’amorçage extrêmement performant, puisqu’il permet de démarrer Linux
comme tout autre système d’exploitation très simplement, en donnant le nom du système à lancer lors de
l’amorçage. Il est bien entendu possible de lancer un système par défaut, et de donner un temps d’attente
avant de choisir ce système si l’utilisateur n’intervient pas.
LILO est constitué de deux parties. La première partie peut s’installer sur le secteur d’amorçage
principal du disque dur ou sur le secteur de boot de n’importe quelle partition. Comme on l’a déjà
indiqué plus haut, il est fortement recommandé d’installer cette partie de LILO sur le secteur de boot de
la partition racine de Linux, afin d’éviter qu’elle ne soit écrasée par le DOS ou par une quelconque

46
 Chapitre 4. Installation du système de base

version de Windows installée ultérieurement. La deuxième partie de LILO est enregistrée directement
dans la partition Linux. Elle contient les informations nécessaires pour pouvoir charger les différents
systèmes d’exploitation gérés. Bien entendu, la première partie est capable de retrouver directement la
deuxième sur le disque dur de manière autonome car, lors de l’amorçage, les systèmes de fichiers de
Linux ne sont pas encore chargés.
LILO utilise le fichier de configuration /etc/[Link] pour y retrouver tous ses paramètres de
configuration. Ce fichier contient la description des différents systèmes d’exploitation que LILO doit
proposer au démarrage. Vous pourrez consulter ce fichier avec un des nombreux éditeurs de fichiers texte
présents sur toute installation de Linux. Toutefois, si vous installez Linux pour la première fois, il est
possible que vous n’en connaissiez aucun et que vous soyez un peu perdu. Cela est normal, et dans ce cas
je vous recommande de vous familiariser un peu avec le système et l’environnement utilisateur avant de
vous lancer dans l’édition de ce fichier. Il existe bon nombre d’éditeurs graphiques ou en mode texte et il
est hors de question de tous les décrire ici. Toutefois, toutes les distributions Linux installent un éditeur
historique, j’ai nommé l’affreux « vi ». Cet éditeur n’est pas du tout convivial pour les nouveaux
utilisateurs, mais il dépannera toujours quand tous les autres seront inutilisables ou inaccessibles. En fait,
on finit même par l’apprécier à l’usage... La manière d’utiliser vi sera décrite ultérieurement, dans le
chapitre donnant les notions de base d’Unix à la la section intitulée vi, l’éditeur de fichiers de base dans
Chapitre 5. Vous devriez donc jeter un coup d’œil à cette section si vous désirez modifier immédiatement
le fichier /etc/[Link], ou revenir ultérieurement à la présente section une fois que vous vous serez
familiarisé avec un autre éditeur.
Quoi qu’il en soit, les options les plus importantes du fichier /etc/[Link] sont les suivantes :

• l’option boot, qui permet d’indiquer sur quel secteur d’amorçage LILO doit s’installer. Cette option
suit la syntaxe suivante :
boot = destination

où destination est le nom d’un fichier spécial de périphérique sur lequel LILO va s’installer. Ce
nom peut identifier un disque dur (comme par exemple /dev/hda), auquel cas LILO va s’installer sur
le MBR de ce disque (c’est-à-dire sur le MBR du premier disque du premier contrôleur de disques
IDE dans notre exemple), ou une partition (comme /dev/hda2). Dans ce cas, LILO s’installe sur le
secteur de boot de cette partition (la deuxième partition du premier disque dur IDE dans notre
exemple). Rappelons qu’il est recommandé d’installer LILO sur le secteur de boot de la partition
racine de Linux ;
• l’option read-only permet de demander au noyau de monter le système de fichiers racine en lecture
seule lors du démarrage. Cette option est nécessaire pour que les scripts de démarrage du système
puissent effectuer les vérifications du système de fichiers de cette partition si nécessaire. La partition
sera remontée en lecture et en écriture une fois ces vérifications réalisées ;
• l’option prompt, qui permet à LILO de demander le système à lancer à chaque démarrage. Cette
option force donc l’apparition du message d’invite de LILO au démarrage : « LILO boot: » auquel
on pourra répondre en tapant le nom de la configuration à lancer ;
• l’option timeout, qui permet de fixer un délai au delà duquel LILO lancera la première configuration
définie dans le fichier [Link]. La syntaxe de cette option est la suivante :
timeout = dixièmes

où dixièmes est le nombre de dixièmes de seconde à attendre avant le lancement du système ;

47
 Chapitre 4. Installation du système de base

• l’option keytable, qui donne la possibilité de spécifier un fichier de tradution des codes de caractère
envoyés par le BIOS (qui suppose généralement que le clavier utilise la disposition d’un clavier
américain) en les codes de caractère qui seraient envoyés par un BIOS localisé. Cette option permet
donc de redéfinir la disposition des touches du clavier pour prendre en compte les claviers
non-américains. La syntaxe de cette option est la suivante :
keytable = fichier

où fichier est le chemin sur un fichier de traduction de clavier pour LILO. Un tel fichier peut être
généré par le script [Link] à l’aide des fichiers de définition des claviers de Linux
(généralement installés dans le répertoire /usr/lib/kbd/keymaps/). La ligne de commande à
utiliser pour ce script est la suivante :
[Link] us local > fichier

où us est le nom du fichier de définition de clavier Linux pour la disposition utilisée par le BIOS
(donc, effectivement, la disposition d’un clavier américain en général), local est le nom du fichier de
définition de clavier pour la disposition du clavier réellement utilisée, et fichier est le nom du fichier
de traduction des codes à générer. Par exemple, la création de ce fichier pour le clavier français se
ferait avec la commande suivante :

[Link] us fr-latin1 > /boot/[Link]

Remarquez que cette technique de traduction de clavier souffre d’un inconvénient majeur, puisque les
combinaisons de touches qui ne sont pas valides dans la disposition américaine des claviers ne peuvent
pas être converties. Si l’une de ces combinaisons doit être utilisée, il faut abandonner l’idée d’utiliser
l’option keytable.

La suite du fichier [Link] décrit les différentes configurations que LILO peut lancer. Les sections
de configuration permettant de charger Linux ont le format suivant :

image = noyau
root = root_device
label = nom

où noyau est le chemin complet sur le noyau de Linux à charger, root_device est le nom complet du
fichier spécial de périphérique contenant le système de fichier racine et nom est le nom de la
configuration tel qu’il devra être saisi à l’invite de LILO. L’exemple donné ci-dessous permet de charger
le noyau /boot/vmlinuz en utilisant la partition /dev/hda2 comme partition racine :

image = /boot/vmlinuz
root = /dev/hda2
label = linux

Si vous désirez créer une section de configuration permettant de lancer un autre système d’exploitation
que Linux (DOS ou Windows par exemple), vous pouvez utiliser la possibilité de passer le relais au
chargeur de ces systèmes, qu’il s’agisse d’un simple secteur de boot ou d’un gestionnaire d’amorçage
complet. Cela se fait avec la syntaxe suivante :

other = partition

48
 Chapitre 4. Installation du système de base

table = disque
loader = relais
label = nom

où partition est la partition sur laquelle le secteur de boot de l’autre système est installé, disque est
le disque dur contenant la table des partitions utilisée par ce système, relais est le nom d’un chargeur
spécial permettant de simplement passer la main au chargeur du système, et nom est le nom de la
configuration. Le chargeur à utiliser pour demander à LILO de passer le relais au chargeur de l’autre
système d’exploitation est le chargeur contenu dans le fichier chain.b de LILO. Ce fichier se trouve
généralement dans le répertoire /boot/, aussi doit-on spécifier /boot/chain.b pour le champ
relais.

Note : Prenez garde au fait que Windows NT/Windows 2000/XP installent NTLDR dans la première
partition à laquelle il savent accéder en général. Donc, si un DOS ou Windows 95, Windows 98 ou
Millenium est installé en premier, ils installeront NTLDR dans la partition de ces systèmes. Dans ce
cas, la configuration permettant de lancer le DOS ou le Windows 95, Windows 98 ou Millenium qui
se trouve sur cette partition risque fort de lancer NTLDR qui proposera, à son tour, de lancer les
différents systèmes d’exploitation Microsoft installés.
Cela peut être relativement gênant et peut être corrigé en déplaçant NTLDR sur la partition de
Windows NT/Windows 2000/XP et en reconstruisant les secteurs de boot des différentes partition
pour que leur chargeurs s’occupent de leurs systèmes respectifs, mais il s’agit là d’une opération
extrêmement technique d’une part, et qui ne concerne absolument pas Linux d’autre part. Cela ne
sera donc pas décrit dans ce document. Il existe toutefois des documents sur Internet qui décrivent
la manière de procéder et je vous invite à vous y référer (avec une prudence extrême cependant).

L’exemple donné ci-dessous permet de donner la possibilité de charger Linux ou Windows NT, en
lançant Linux par défaut au bout de 10 secondes. Windows NT est installé sur la troisième partition, et
Linux utilise la deuxième et la quatrième partition respectivement pour y stocker sa partition racine et la
partition des répertoires personnels des utilisateurs. LILO est ici installé sur la partition racine de Linux :

# Exemple de fichier de configuration /etc/[Link] :

# Options générales :
boot = /dev/hda2
read-only
prompt
timeout=100
keytable = /boot/[Link]

# Première configuration (Linux) :

image = /boot/vmlinuz
root = /dev/hda2
label = linux

# Deuxième configuration (NT) :

other = /dev/hda3
table = /dev/hda
loader = /boot/chain.b

49
 Chapitre 4. Installation du système de base

label = NT

L’installation de LILO est très simple une fois que l’on a écrit le fichier [Link]. En effet, il suffit
tout simplement de taper la commande suivante :

lilo [-L]

L’option -L permet de demander à LILO d’utiliser le mode d’adressage LBA pour accéder au disque dur
pendant la phase d’amorçage. Cette option est nécessaire si vous disposez d’un grand disque dur et que
certaines partitions disposant de systèmes à lancer sont situées au delà du cylindre 1024. Il est
recommandé de l’utiliser systématiquement étant donné les tailles des disques durs actuels.

Note : Comprenez bien que si votre BIOS est incapable d’utiliser le mode LBA ou le si bootstrap
loader est incapable d’utiliser ce mode, cette option ne vous sera d’aucune utilité. En effet, dans ce
cas, le bootstrap loader ne parviendrait même pas à charger le secteur de boot de la partition Linux.
C’est pour cette raison qu’il a été recommandé de placer la partition du système principal en deçà de
cette limite des 1024 cylindres. Cette limitation est donc bien une limitation du BIOS, mais vous ne
devriez plus rencontrer ce genre de problème que sur de vieilles machines sur lesquelles un
nouveau disque dur de grande capacité a été installé.

Si lilo signale une erreur, il vaut mieux ne pas insister et corriger le fichier [Link].
Lorsque la machine démarre, LILO affiche son invite de démarrage : LILO boot:
Il attend ici que vous indiquiez le nom du système que vous désirez démarrer. Vous devez ici taper le
nom du système à charger et valider : LILO boot:linux
Si vous ne tapez rien, et que vous avez donné un délai d’attente dans le fichier de configuration de LILO,
la première configuration sera lancée automatiquement après ce délai.
LILO permet de spécifier des paramètres de démarrage complémentaires pour Linux à la suite du nom de
la configuration qui permet de le lancer. Ces paramètres servent principalement à renseigner le noyau sur
la configuration matérielle (en particulier les ports d’entrée/sortie et les lignes d’interruption des
périphériques non Plug and Play), pour le cas où il ne parviendrait pas à les déterminer automatiquement.
L’un des paramètres les plus intéressants est sans doute mem, qui permet d’indiquer au noyau la taille de
la mémoire vive dont dispose l’ordinateur. Ce paramètre peut être nécessaire si vous disposez de plus de
64 Mo de mémoire, parce que les fonctions du BIOS ne permettent pas d’indiquer les tailles de mémoire
plus grandes (la plupart des BIOS récents n’ont toutefois plus ce problème). Par exemple, si votre
ordinateur dispose de 256 Mo de mémoire, vous devrez taper la ligne de paramètres suivante au
démarrage : LILO boot:linux mem=256M
Bien entendu, il est possible d’enregistrer ces paramètres dans le fichier de configuration de LILO afin de
ne pas avoir à les saisir à chaque démarrage. Pour cela, il suffit d’indiquer le paramètre de démarrage du
noyau dans une ligne append de la section de configuration de Linux :

append="paramètre"

Ainsi, la section de configuration de Linux du fichier [Link] exemple donné ci-dessus pourrait être
remplacée par celle-ci sur une machine disposant de 256 Mo de mémoire :

50
 Chapitre 4. Installation du système de base

# Première configuration (Linux) :

image = /boot/vmlinuz
root = /dev/hda2
label = linux
append="mem=256M"

La liste des paramètres que l’on peut fournir au noyau est relativement grande et ne sera pas décrite ici.
Les plus utiles seront présentés en temps et en heure, notamment dans le chapitre décrivant la
configuration du système.

Réalisation d’un multiboot avec le GRUB

Le « GRUB » (abréviation de l’anglais « GRand Unified Bootloader ») est le gestionnaire d’amorçage
développé par la Free Software Foundation pour amorcer le noyau Hurd du projet GNU. Il est capable de
faire démarrer tous les systèmes utilisant un protocole de démarrage standard initialement défini pour le
Hurd. Bien entendu, il sait aussi amorcer les systèmes Linux, qui n’utilisent pas ce protocole, ainsi que la
plupart des autres systèmes d’exploitation en passant le relais à leurs propres gestionnaires d’amorçage.
En fait, le GRUB fournit la possibilité de contrôler totalement l’amorçage de son système par
l’intermédiaire d’un interpréteur de commandes simplifié. Il est possible, par l’intermédiaire de cet
interpréteur de commandes, d’effectuer nombre d’opérations dans le but de charger un noyau de système
d’exploitation et de l’amorcer. Bien entendu, ces commandes peuvent être écrites dans un fichier de
configuration afin d’automatiser le processus de chargement.
Le GRUB est normalement installé dans le répertoire /boot/grub/. Ce répertoire contient, outre les
fichiers binaires du GRUB lui-même, son fichier de configuration. Ce fichier se nomme normalement
[Link], en raison du fait qu’il permet de définir les différentes configurations correspondantes aux
systèmes d’exploitation à charger et qui apparaîtront dans le menu de démarrage lors de l’amorçage de la
machine.
Contrairement à LILO, qui enregistre l’emplacement des fichiers des différents noyaux à charger dans
une liste de blocs du disque dur, le GRUB sait interpréter les systèmes de fichiers classiques de Linux.
En particulier, il est capable de retrouver son fichier de configuration et les fichiers images des noyaux
Linux dans les systèmes de fichiers FAT, EXT2/EXT3 et ReiserFS. Cette particularité fait qu’il n’est pas
nécessaire, lorsqu’on modifie le fichier de configuration [Link], de réinstaller le GRUB.
Tout comme le fichier de configuration de LILO, le fichier [Link] se compose d’une partie contenant
les options globales et d’une ou plusieurs parties contenant la description des différents systèmes
d’exploitation à proposer au démarrage. Les options générales les plus utiles sont les suivantes :

• l’option default, qui permet de spécifier la configuration par défaut à charger. Cette option doit être
suivi du numéro de cette configuration. Les configurations sont numérotées à partir de 0, dans leur
ordre d’apparition dans le fichier de configuration ;
• l’option timeout, qui permet de spécifier le délai d’attente avant que la configuration par défaut
spécifiée par l’option default ne soit lancée.

Les configurations spécifiques aux systèmes d’exploitation suivent la syntaxe suivante :

51
 Chapitre 4. Installation du système de base

title titre
root partition
kernel noyau options

où titre est le titre de la configuration tel qu’il doit apparaître dans le menu de démarrage du GRUB,
partition est la partition dans laquelle se trouve le noyau à charger, et noyau est le chemin sur le
fichier image de ce noyau dans cette partition. Attention, ce chemin est défini dans la partition elle-même
et peut donc être différent du chemin utilisé sous Linux. En effet, il faut définir ce chemin par rapport au
point de montage de la partition, faute de quoi le GRUB ne retrouverait pas le fichier image du noyau à
charger.
Comme le GRUB n’est pas un chargeur spécifique à Linux mais a été écrit au contraire avec comme
principal objectif une généricité absolue, la manière de spécifier la partition dans laquelle le noyau se
trouve utilise une syntaxe différente de celle utilisée sous Linux. Cette syntaxe, propre au GRUB donc,
est la suivante :

(hdn,m)

où n est le numéro du disque dans l’ordre énuméré par le BIOS de la machine et m est le numéro de la
partition. Ce dernier numéro est facultatif (ainsi que la virgule qui le précède), ce qui permet de
référencer un disque complet et non une partition. La numérotation des disques et des partitions
commence toujours à 0 dans le GRUB, ce qui fait que la première partition du premier disque est
référencée par (hd0,0), la deuxième partition du premier disque par (hd0,1), la première partition du
deuxième disque par (hd1,0), etc.
Tout comme avec LILO, il est possible de spécifier des options de démarrage qui devront êtres fournies
au noyau. Ces options devront être spécifiées immédiatement après le nom de l’image du noyau. Comme
vous pouvez le constater, la définition d’une configuration de démarrage pour un système Linux est très
simple, puisqu’il suffit quasiment de donner la ligne de commande pour lancer ce noyau ! Par exemple,
pour charger le noyau /boot/vmlinuz d’un système situé sur la deuxième partition du premier disque,
la configuration suivante doit être définie :

title Linux
root (hd0,1)
kernel /boot/vmlinuz mem=256M

Cet exemple présente également comment spécifier la taille de la mémoire disponible dans la machine
(cela n’est normalement pas nécessaire avec les BIOS récents et avec le GRUB). Il suffit simplement de
fournir des options en ligne de commande au noyau pour cela. Beaucoup d’autres options peuvent être
fournies de cette manière au noyau. En particulier, des options peuvent être fournies aux pilotes de
périphériques si nécessaire (par exemple s’il y a des conflits d’interruptions ou de ressources entre
plusieurs périphériques). Ces options seront présentées au fur et à mesure dans la suite de ce document.
Bien entendu, le GRUB est capable de charger le secteur de boot d’une partition afin de passer le relais
au gestionnaire d’amorçage d’un autre système d’exploitation. Pour cela, il faut utiliser la commande
chainloader, plutôt que la commande kernel, dans la description de la configuration de démarrage de ce
système. La forme générale d’une configuration de ce type est donc la suivante :

title titre
root partition

52
 Chapitre 4. Installation du système de base

chainloader +1

Le +1 qui suit la commande chainloader indique au GRUB de charger le premier secteur de la partition
indiquée par la commande root et d’exécuter le gestionnaire d’amorçage normalement stocké dans ce
secteur. Comme pour les configurations Linux, la syntaxe utilisée pour spécifier la partition où ce secteur
est situé est la syntaxe du GRUB et non celle utilisée sous Linux.
Le fichier de configuration d’exemple suivant correspond au fichier de configuration de LILO vu dans la
section précédente. Il permet de démarrer un Linux installé sur la deuxième partition ou un Windows NT
installé sur la troisième partition du premier disque dur de la machine :

# Exemple de fichier de configuration /boot/grub/[Link] :

# Options générales :
default 0
timeout 10

# Première configuration (Linux) :

title Linux
root (hd0,1)
kernel /boot/vmlinuz root=/dev/hda2 mem=256M

# Deuxième configuration (NT) :

title NT
root (hd0,2)
chainloader +1

L’installation du GRUB sur une nouvelle machine ne pose quant à elle pas de problème particulier. Il
suffit de s’assurer que le fichier de configuration [Link] se situe bien dans le répertoire
/boot/grub/, de même que les fichiers binaires du GRUB. Ces fichiers sont respectivement les fichiers
stage1, stage2 et tous les fichiers *_stage1_5. S’ils ne s’y trouvent pas, vous pourrez les copier à
partir du répertoire /usr/share/grub/i386-pc/, dans lequel le programme d’installation du GRUB
les place par défaut.
Lorsque tous les fichiers sont en place, il n’y a plus qu’à lancer le GRUB en mode interactif avec la
commande suivante :

grub

et à définir le secteur où il doit installer son fichier d’amorçage principal stage1 (c’est-à-dire dans le
secteur de boot d’une partition ou directement sur le MBR du premier disque dur). Pour cela, vous
devrez utiliser les deux commandes suivantes :

root source
setup destination

source est ici la partition où est installé le GRUB (il s’agit donc de la partition où se trouvent le
répertoire /boot/grub/), et destination est le disque dur ou la partition dont le premier secteur doit
recevoir le code d’amorçage du GRUB. Ces deux informations doivent suivre la syntaxe utilisée par le
GRUB pour spécifier les disques durs et les partitions. Par exemple, pour installer le GRUB sur le secteur
de boot de la deuxième partition du premier disque dur, on utilisera les deux commandes suivantes :

53
 Chapitre 4. Installation du système de base

root (hd0,1)
setup (hd0,1)

Cet exemple suppose que le GRUB est également installé dans cette partition. Si ce n’est pas le cas pour
vous, vous devrez modifier la partition spécifiée dans la commande root. Vous pourrez quitter le grub
avec la commande quit une fois l’installation terminée.

Réalisation d’un multiboot avec NTLDR

Le gestionnaire d’amorçage de Windows NT, Windows 2000 et XP se nomme « NTLDR ». Ce
gestionnaire d’amorçage permet de démarrer ces systèmes, bien entendu, mais également les autres
systèmes d’exploitation les plus courants, dont Linux. Cette section ne traitera bien entendu que de la
manière d’utiliser NTLDR pour démarrer Linux, pour de plus amples informations sur la manière
d’ajouter les autres systèmes d’exploitation, veuillez consulter la documentation de Microsoft.
Tout comme LILO, NTLDR dispose d’un fichier de configuration qui permet de décrire les différentes
options de son menu de démarrage. Il s’agit du fichier [Link], qui est normalement placé à la racine
du disque où NTLDR est installé. Il s’agit donc généralement du répertoire racine du disque C:\.
Le fichier [Link] contient la définition du système d’exploitation à lancer par défaut et du délai
d’attente à attendre avant de le sélectionner. Ces deux informations sont écrites dans la section [boot
loader] du fichier et sont introduites respectivement par les options default et timeout. La valeur de
l’option default doit être l’une des entrées de la section [operating systems], qui contient la
définition de tous les systèmes d’exploitation que NTLDR devra proposer au démarrage.
La syntaxe des entrées pour les systèmes d’exploitation dans la section [operating systems] est la
suivante :

emplacement = "Nom"

où emplacement est la description de l’emplacement où se trouve le système d’exploitation, et Nom est

le nom avec lequel ce système devra apparaître dans le menu de démarrage de NTLDR. Cette syntaxe est
très simple, mais pour les systèmes NT4, Windows 2000 et XP, la définition de l’emplacement du
système est assez compliquée. En effet, elle nécessite de définir complètement le disque physique et sa
partition, ainsi que le répertoire du système. Pour les autres systèmes d’exploitation, le plus simple est de
spécifier un fichier contenant l’image du secteur de boot de leur partition, et de laisser leur chargeur
prendre en charge leur amorçage.
Pour cela, il faut bien entendu disposer d’un tel fichier. Il faut donc copier le premier secteur de la
partition du système dans un fichier accessible à NTLDR, donc, en pratique, situé dans le répertoire C:\.
Vous pourrez extraire le contenu du secteur de boot de votre partition Linux avec la commande suivante
sous Linux :

dd if=/dev/hda3 of=[Link] bs=512 count=1

Cette commande suppose que LILO ait été installé sur la partition /dev/hda3. Elle permet de lire un
bloc de 512 octets de la troisième partition du premier disque dur et de l’enregistrer dans le fichier
[Link]. Vous pourrez ensuite transférer ce fichier dans le répertoire C:\ de Windows, soit en
passant par une partition FAT, soit tout simplement à l’aide d’une disquette (rappelons que le système de
fichiers NTFS n’est utilisable qu’en lecture seule sous Linux).

54
 Chapitre 4. Installation du système de base

Une fois ce fichier obtenu, vous pourrez simplement ajouter la ligne suivante dans votre fichier
[Link] :

C:\[Link]="Linux"

Le contenu de votre fichier [Link] devrait alors ressembler à ceci :

[boot loader]
timeout=10
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT

[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professionnel" /fastdetect
C:\[Link]="Linux"

Vous devriez alors pouvoir démarrer Linux directement à partir du menu de démarrage de NTLDR.

Note : Prenez soin à utiliser un nom court pour le fichier contenant le secteur de Linux (c’est-à-dire
un nom ne comprenant pas plus de huit caractères et une extension d’au plus trois caractères). En
effet, Windows, même dans ses versions les plus récentes, a toujours du mal à prendre en charge
les noms longs et il se peut que le gestionnaire d’amorçage NTLDR ne puisse pas localiser le fichier
si vous ne respectez pas cette règle.

55
Chapitre 5. Commandes Unix de base
Si vous êtes parvenu à installer les paquetages de la série de base, vous disposez d’un système Linux
fonctionnel. Félicitations ! Maintenant, il va falloir le configurer... Autant vous prévenir tout de suite :
cette opération demande beaucoup de temps et de patience, à moins d’avoir une machine vraiment
standard et une chance phénoménale. Mais pour cela, il va falloir que vous appreniez les commandes
Unix de base et la manière d’utiliser un système Linux en ligne de commande (c’est-à-dire en mode
texte, sans XWindow).

Login et déconnexion
Comme il l’a déjà été dit, Linux est un système multi-utilisateur. Il faut donc que chacun s’identifie pour
que le système puisse fonctionner correctement. Cette opération est réalisée lors de l’opération dite de
login (du verbe anglais « to log in », qui signifie « s’enregistrer » dans le système). Le login consiste
essentiellement à taper son nom d’utilisateur, valider, et répondre éventuellement à la demande de mot de
passe de la part du système.
Le login doit être la première opération à effectuer. Il est impossible d’accéder au système d’une autre
manière, et la vérification du mot de passe fournit l’authenticité de l’utilisateur qui se logue. Ainsi, le
système sait en permanence au nom de quelle personne il effectue les opérations demandées. Cette
opération est à la base des mécanismes de sécurité et de personnalisation du système pour chaque
utilisateur.
Il existe deux types de login. Le plus courant est le login en mode texte, qui peut être fait directement sur
le poste local ou à travers un réseau. Le système vous invite à vous identifier avec la ligne suivante :

login:

D’autres informations peuvent être affichées avant le mot login, qui peuvent vous renseigner sur la
nature du système. Quoi qu’il en soit, vous devez taper votre nom d’utilisateur (que l’on appelle
simplement « login »), ou « root » si vous désirez vous connecter en tant qu’administrateur. Le système
vous demande alors le mot de passe avec la ligne suivante :

password:

Bien entendu, vous ne devrez jamais oublier votre mot de passe administrateur. Si toutefois cela vous
arrive, vous n’aurez plus qu’une seule solution : démarrer l’ordinateur à partir d’une disquette système,
et faire le ménage dans le fichier de mots de passe. Cette opération n’est jamais très agréable à réaliser.
Conclusion : n’oubliez jamais votre mot de passe.

56
 Chapitre 5. Commandes Unix de base

Le deuxième type de login est le login graphique, sous X11. Ce type de login a en général lieu sur un
terminal X (c’est-à-dire un terminal graphique). La procédure peut varier selon l’environnement utilisé,
mais le principe reste toujours le même : il faut fournir son nom d’utilisateur et son mot de passe.
Si, comme la plupart des gens, vous ne cherchez pas à utiliser votre ordinateur à distance à travers un
réseau, vous vous connecterez quasiment toujours en local. Linux fournit, pour l’utilisateur local,
plusieurs terminaux virtuels. Cela signifie qu’il est possible de se connecter plusieurs fois dans le
système dans des terminaux différents. Pour passer d’un terminal virtuel à un autre, il suffit de taper les
combinaisons de touches ALT+DROITE ou ALT+GAUCHE, où DROITE et GAUCHE sont respectivement les
flèches du curseur droite et gauche. Il est également possible d’accéder à un terminal donné à l’aide de la
combinaison de touches ALT+Fn, où Fn est l’une des touches de fonction F1, F2, F3, etc. La plupart des
distributions utilisent au moins quatre terminaux virtuels, plus un terminal X. Le terminal X est le
terminal graphique, qui fonctionne sous XWindow. Vous noterez sans doute que lorsqu’on est sous
XWindow, les combinaisons ALT+Fn ont une autre signification. Elles ne peuvent donc pas être utilisées
pour basculer vers les terminaux en mode texte. Pour remédier à ce problème, une autre combinaison de
touches a été définie, spécialement pour XWindow : CTRL+ALT+Fn. Il suffit donc simplement d’utiliser
la touche CTRL en plus de la touche ALT.
L’utilisation des terminaux virtuels est très pratique, même pour un seul utilisateur. En effet, ceux-ci
permettent de lancer plusieurs programmes simplement, à raison d’un par terminal virtuel, et de s’y
retrouver ainsi plus facilement. Pour ceux qui ne connaissent pas les systèmes Unix, il est recommandé
de jouer un peu avec les terminaux virtuels afin de simuler la présence de plusieurs utilisateurs. Ils auront
ainsi un aperçu de la puissance de ces systèmes.
Lorsqu’on a fini de travailler, il faut se déconnecter. Cette opération est très simple pour les terminaux
non graphiques, puisqu’il suffit de taper la commande suivante :

logout

Si d’aventure cette commande ne fonctionnait pas, vous pourrez utiliser la commande exit ou la
combinaison de touches CTRL+d, qui terminent le shell courant (y compris le shell de login).
Pour les terminaux X, le processus de déconnexion dépend de l’environnement utilisé. Il faut tâtonner un
peu, et normalement on trouve une option de menu du style « logout » ou « déconnexion ». Vous pouvez
par exemple cliquer sur le bouton droit de la souris sur le bureau de l’environnement de travail, afin
d’appeler un menu contextuel. Dans bien des cas, ce menu contient une option de déconnexion.
Il est très important de se déconnecter et de ne jamais laisser une session ouverte. En effet, cette
négligence peut vous coûter cher, car une personne mal intentionnée pourrait très bien utiliser ce terminal
à vos dépends. Il aurait tous vos droits, et effectuerait ses opérations en votre nom. La sécurité du
système garantissant que vous seul pouvez vous connecter sous ce nom, grâce au mot de passe, vous
seriez donc responsable des agissements de l’intrus. Bien entendu, ce genre de considération n’a pas
autant d’importance pour un particulier que dans une entreprise ou une collectivité quelconque.

Arrêt et redémarrage du système

Il faut bien comprendre que Linux, tout comme la plupart des systèmes d’exploitation modernes, ne peut
pas être arrêté en éteignant directement l’ordinateur, comme on le faisait autrefois avec le DOS. En effet,

57
 Chapitre 5. Commandes Unix de base

la plupart des systèmes d’exploitation utilisent une partie de la mémoire de l’ordinateur pour y stocker
temporairement les données qui ont été lues à partir du disque et celles qui doivent y être écrites. Cette
zone de mémoire constitue ce qu’on appelle un tampon (« buffer » en anglais), et elle sert à accélérer les
accès aux périphériques plus lents, que sont les disques durs et lecteurs de CD-ROM. Il va de soi qu’une
requête de lecture sur des données déjà situées en mémoire est infiniment plus rapide que si elles ne s’y
trouvaient pas. Il est en revanche plus difficile de comprendre pourquoi les requêtes d’écriture doivent
être différées. La raison est la suivante : le système préfère différer l’écriture physique sur le disque parce
qu’une autre requête d’écriture dans la même zone du disque peut très bien avoir lieu ultérieurement. Si
les données qui n’ont pas été écrites sont ainsi modifiées par une requête ultérieure, il n’est plus
nécessaire de les écrire, et ainsi le système peut économiser un temps précieux en ne le faisant pas. Si les
données à écrire sont contiguës à celles d’une requête précédente, le système peut les écrire en bloc, ce
qui est toujours plus rapide que de faire plusieurs écritures partielles (notamment parce que les têtes de
lecture du disque n’ont pas à être déplacées). Enfin, si les données qui doivent être écrites font l’objet
d’une requête de lecture, il va de soi qu’elles sont immédiatement accessibles. On voit que cette stratégie
permet de travailler beaucoup plus vite. De facto, Linux utilise toute la mémoire vive libre pour ses
tampons d’entrées / sorties, ce qui en fait un système extrêmement performant. Le gain en performances
peut facilement atteindre un facteur 3 ou 4.
Le problème majeur est évidemment que si l’on éteint l’ordinateur brutalement, les données dont
l’écriture a été différée sont perdues. Pire, parmi ces données, il est probable qu’il y ait des informations
vitales pour le système de fichiers, ce qui fait qu’il risque fort d’être endommagé. Les systèmes de
fichiers journalisés comme EXT3 et ReiserFS sont à l’abri de ce type d’erreur en raison de l’accès
transactionnel aux structures de données du systèmes de fichiers qu’ils utilisent, et le système parvient
généralement à réparer les autres systèmes de fichiers lors de la vérification qui est lancée au redémarrage
suivant de la machine, mais il est inutile de prendre des risques. Tout cela signifie qu’il est impératif de
prévenir le système avant de l’arrêter, pour qu’il puisse écrire les données situées dans ses tampons.
L’arrêt du système est une opération qui est du ressort de l’administrateur. On ne peut donc le réaliser que
sous le compte root. Plusieurs commandes sont disponibles, les plus simples sont données ci-dessous :

• halt, qui permet d’arrêter le système.

• reboot, qui permet de le redémarrer.

Ces commandes sont en fait des scripts permettant d’effectuer les opérations d’arrêt et de redémarrage du
système rapidement. Si elles ne sont pas disponibles sur votre distribution, vous devrez sans doute
utiliser la commande générique suivante :

shutdown [-r] now

où l’option -r permet de demander un redémarrage et non un arrêt simple.

Il est également possible que votre gestionnaire de bureau vous donne le moyen d’arrêter l’ordinateur par
l’intermédiaire de l’interface graphique de X11. La technique à utiliser dépend évidemment de
l’environnement que vous aurez installé, et elle ne sera pas décrite ici. Consultez la documentation de
votre distribution pour plus de détails à ce sujet. De plus, la plupart des distributions provoquent un
redémarrage de la machine lorsqu’on appuie sur les touches CTRL+ALT+SUPPR simultanément dans un
terminal virtuel.

58
 Chapitre 5. Commandes Unix de base

Pages de manuel
Maintenant que vous savez l’essentiel pour conserver votre système en bon état, nous allons traiter des
autres commandes Unix. Parmi elles, il en est qui sont certainement fondamentales : ce sont les
commandes qui permettent d’obtenir de l’aide !
Chaque commande Unix a une page de manuel qui la décrit. Ces pages sont très souvent écrites en
anglais, mais elles sont très précises et fournissent toutes les informations dont on peut avoir besoin.
Pour afficher la page de manuel d’une commande, il suffit d’utiliser la commande suivante :

man page

où page est la page de manuel de la commande sur laquelle on cherche des informations. En général, le
nom de la page de manuel est le même que celui de la commande. Par exemple, pour afficher l’aide sur la
commande cp, il suffit de taper :

man cp

Lorsqu’une page de man est affichée, il est possible de faire défiler son texte à l’aide des touches du
curseur. Pour quitter l’aide, il suffit d’appuyer sur la touche q.
Les pages de man sont classées en groupes de pages thématiques, chaque groupe étant identifié
généralement par un numéro ou une lettre. Si la page de man affichée ne correspond pas à celle désirée,
c’est qu’une page homonyme d’un autre groupe a été utilisée. Dans ce cas, il faut préciser l’identificateur
du groupe de pages de manuel avant le nom de la page à afficher :

man groupe page

où goupe est l’identificateur du groupe auquel la page de manuel appartient. Les principaux groupes
sont les suivants :

Tableau 5-1. Groupes de pages de man

Identificateur Type de pages de manuel

1 Commandes utilisateur
2 Appels systèmes (programmation en C)
3 Fonctions de la bibliothèque C
4 Description des fichiers spéciaux
5 Description des fichiers de configuration
6 Jeux et programmes divers
7 Programmes systèmes divers
8 Administration système

Si vous ne savez pas dans quel groupe se trouve une page de manuel, vous pouvez utiliser l’option -k,
qui permet d’afficher l’ensemble des pages disponibles portant ce nom :

59
 Chapitre 5. Commandes Unix de base

man -k commande

L’identificateur du groupe est en général précisé entre parenthèses, à la suite du nom de la page de
manuel.
Il se peut également que vous recherchiez de l’aide sur un sujet donné, mais que vous ne connaissiez pas
le nom exact de la page de manuel qui en parle. Pour ce genre de recherche, vous pourrez utiliser le
programme apropos, qui recherchera toutes les pages de manuel qui contiennent un mot clé particulier.
Ce programme s’utilise avec la syntaxe suivante :

apropos mot

où mot est le mot clé à rechercher dans toutes les pages de manuel.
La commande man est la commande d’aide standard sur tous les systèmes Unix. Cependant, Linux
utilise un grand nombre de commandes écrites sous la licence GNU, et qui utilisent un format d’aide
spécifique à GNU. L’aide pour ces commandes peut être obtenue par la commande suivante :

info commande

Il se peut que les deux méthodes fonctionnent. Dans ce cas, la page de man sera certainement moins
récente que la page d’info, car la commande que vous utilisez est sans aucun doute une commande GNU,
qui a été fournie avec sa page d’information. Il est donc recommandé de lire plutôt la page d’information
GNU.
Le format d’aide GNU est plus riche que celui de man, puisqu’il permet de naviguer dans le système
d’aide à l’aide de liens hypertextes. Ces liens sont organisés hiérarchiquement, avec des chapitres et des
sous-chapitres. Chaque chapitre dispose d’une forme de table des matières constituée de menus, qui
permettent d’accéder aux sous-chapitres. Les menus se distinguent du texte normal par un astérisque
(« * ») en début de ligne dans la table des matières. Les commandes clavier suivantes pourront vous être
utiles pour naviguer dans la hiérarchie du système d’aide de GNU :

• la touche de tabulation permet de passer au lien hypertexte suivant ;

• la touche n (pour « Next ») permet de passer au chapitre suivant ;
• la touche p (pour « Previous ») permet de revenir au chapitre précédent ;
• la touche u (pour « Up ») permet de remonter d’un niveau dans le système d’aide et d’atteindre la table
des matières référençant le chapitre courant.

Enfin, la commande q permet de quitter le système d’aide.

Opérations de base sur les répertoires

Ce paragraphe va vous décrire les opérations de base qu’il faut savoir faire pour manipuler les répertoires
du système de fichiers.

60
 Chapitre 5. Commandes Unix de base

La première commande est évidemment celle qui permet de lister le contenu d’un répertoire. Elle
dispose d’un grand nombre d’options :

ls [options] [fichier]

où fichier est le nom d’un fichier ou d’un répertoire que l’on désire lister. Si ce paramètre est absent, ls
affichera tous les fichiers du répertoire courant. Les principales options sont -l, qui permet d’afficher des
informations étendues (notamment les propriétaires, les groupes, les droits, la taille et éventuellement les
liens), et -a, qui permet d’afficher tous les fichiers, y compris les fichiers cachés (ceux dont le nom
commence par un point).
La deuxième commande est celle qui permet de changer de répertoire courant. Sa syntaxe est très simple :

cd [chemin]

où chemin est un chemin de répertoire Unix valide. Ce chemin est constitué des noms des répertoires et
sous-répertoires successifs, séparés par des barres obliques « / ». Si aucun chemin n’est spécifié, cette
commande change le répertoire courant pour le répertoire personnel de l’utilisateur. Par exemple, pour
aller dans le répertoire d’installation de XWindow, il faut taper la commande suivante :

cd /usr/X11

La notion de chemin sera détaillée dans le paragraphe suivant. « cd » est l’abréviation de l’anglais
« Change Directory ».
La troisième commande permet de créer un répertoire :

mkdir chemin

où chemin est le chemin spécifiant le répertoire à créer. Si le chemin ne contient que le nom du
répertoire à créer, celui-ci est créé dans le répertoire courant et devient donc un sous-répertoire.
« mkdir » est l’abréviation de l’anglais « MaKe DIRectory »).
La commande pour supprimer un répertoire est la suivante :

rmdir chemin

Pour supprimer un répertoire, il faut qu’il soit vide (c’est-à-dire qu’il ne contienne ni fichier, ni
répertoire). « rmdir » est l’abréviation de l’anglais « ReMove DIRectory ».
Enfin, voici une commande dont vous ne vous servirez normalement que très peu, voire pas du tout. Elle
permet d’afficher le répertoire courant :

pwd

Cette commande n’est a priori pas très utile, car le shell affiche toujours le répertoire courant sur la
plupart des distributions. Cependant, le chemin affiché par le shell étant relatif au répertoire personnel de
l’utilisateur lorsqu’on se trouve dans un sous-répertoire de celui-ci, la commande pwd peut être utile
lorsqu’on désire obtenir un chemin absolu sur le répertoire courant. « pwd » est l’abréviation de l’anglais

61
 Chapitre 5. Commandes Unix de base

« Print Working Directory ». Cette commande est également utilisée par les scripts pour déterminer le
répertoire à partir duquel ils sont exécutés.

Notions sur les chemins Unix

Les chemins Unix permettent de qualifier complètement un répertoire ou un fichier sur le disque. Pour
cela, ils utilisent les noms de ces répertoires et de ces fichiers, et ils les combinent pour indiquer comment
atteindre la cible dans le système de fichiers. Classiquement, les chemins sont spécifiés par la séquence
des répertoires dans lesquels il faut aller pour trouver cette cible. Cette séquence est donnée par la suite
des noms des répertoires, séparés par un caractère spécial. Sous Unix, ce caractère est la barre oblique
(« / »). Le répertoire racine n’a pas de nom, et peut donc être référencé par une barre oblique seule.
Les chemins peuvent être absolus (c’est-à-dire qu’ils peuvent partir du répertoire racine) ou relatifs
(c’est-à-dire qu’il peuvent partir du répertoire courant). Si l’on utilise un chemin relatif, il faut savoir que
le répertoire courant est désigné par un point (« . »), et que le répertoire parent du répertoire courant est
désigné par deux points successifs (« .. »). Ainsi, si l’on est dans le répertoire /usr/local/bin, on
peut accéder au répertoire /usr/X11/bin avec les deux chemins suivants :

/usr/X11/bin

ou :

../../X11/bin

Le premier chemin est absolu, parce qu’il part directement du répertoire racine. Le deuxième chemin est
relatif, car il part du répertoire courant.

Note : Il va de soi que les chemins relatifs ne sont valides, sauf coup de chance, que dans le
répertoire dans lequel ils sont écrits, alors que les chemins absolus sont toujours valables. En
revanche, si des répertoires sont déplacés ensemble, les chemins relatifs entre ces répertoires
restent valides, mais les chemins absolus deviennent faux. Toutefois, ces considérations ne
concernent pas un utilisateur de base.

La plupart des shells sont capables d’effectuer ce que l’on appelle la complétion automatique des
commandes. La complétion automatique permet de n’écrire qu’une partie des noms de fichiers ou de
répertoires et de demander au shell de compléter ces noms. Cela peut se faire de deux manières. La
première solution, qui est aussi la plus simple, consiste à taper le début du nom, puis d’utiliser une touche
spéciale qui permet de demander au shell de le compléter. Si vous utilisez le shell bash (bash est le shell
de prédilection sur les systèmes Linux), cette touche est la touche de tabulation. Ainsi, si vous tapez :

cd /ho

et que vous appuyez sur la touche de tabulation, bash complétera cette ligne de la manière suivante :

62
 Chapitre 5. Commandes Unix de base

cd /home/

Pour cela, il regarde la liste des fichiers et des répertoires qui commencent par « ho » dans le répertoire
racine. Normalement, il ne s’y trouve que le répertoire /home/, et c’est ce nom que bash utilise. Il va de
soi qu’il ne faut pas qu’il y ait ambiguïté sur un nom partiel. Par exemple, si vous tapez la commande
suivante :

cd /usr/l

et que vous demandiez au shell de compléter le nom, il ne pourra pas choisir quel répertoire utiliser entre
/usr/lib/ et /usr/local/. Dans ce cas, il émettra un petit bip signalant l’erreur. En appuyant une
fois de plus sur la touche de tabulation, bash affiche la liste des choix possibles et vous propose de
terminer la ligne de commande en saisissant des caractères supplémentaires afin de résoudre l’ambiguïté.
La deuxième solution est d’utiliser les caractères génériques du shell. Ces caractères permettent de
désigner n’importe quel caractère, ou n’importe quelle séquence de caractères. Ils sont désignés
respectivement par un point d’interrogation (« ? ») et par un astérisque (« * »). Ainsi, si l’on tape la
commande suivante :

cd /ho*

le shell ira directement dans le répertoire /home/, car le caractère générique « * » peut être remplacé par
la séquence de caractères « me ». Il est également possible d’écrire :

cd /?ome

et dans ce cas le caractère générique « ? » sera remplacé par « h ». Encore une fois, il ne faut pas qu’il y
ait ambiguïté. Dans le cas contraire, le comportement varie selon le shell. En général, il essaie de
résoudre l’ambiguïté au mieux en analysant la suite du chemin, et s’il ne peut pas, il affiche un message
d’erreur.

Note : Ces caractères génériques sont interprétés directement par le shell et non par la commande
qui les reçoit en paramètres. Tout nom de fichier contenant un caractère générique est remplacé par
la liste des fichiers qui correspondent au motif donné. S’il n’existe qu’un seul fichier dans cette liste, il
est possible d’utiliser les commandes comme cd, qui ne prennent qu’un seul paramètre. Mais il est
possible d’utiliser les commandes acceptant plusieurs paramètres, même s’il y a plusieurs fichiers
dans cette liste. Ainsi, la commande suivante :

ls *txt

permet de lister tous les fichiers dont le nom se termine par « txt ». Il ne peut évidement pas y avoir
d’ambiguïté dans ce cas.
Si on doit passer un paramètre comprenant l’un des caractères génériques interprétés par le shell à
une commande particulière, on devra préfixer les caractères génériques d’un caractère
d’échappement pour signaler au shell qu’il ne doit pas l’interpréter. Ce caractère d’échappement est
la barre oblique inverse (« \ »). Il est également possible de passer les paramètres entre guillements
« " », car le shell n’interprète pas les caractères génériques dans les chaînes de caractères. Par
exemple, pour créer un répertoire ?, on utilisera la commande suivante :

63
 Chapitre 5. Commandes Unix de base

mkdir \?

Les noms de fichiers commençant par un tiret (caractère ’-’) posent également des problèmes avec
la plupart des commandes, car ce caractère est utilisé pour spécifier des options. Ce n’est pas le
shell qui interprète ce caractère dans ce cas, mais le problème est le même. La plupart des
commandes utilisent l’option - (elle-même introduite par un tiret, ce qui fait donc deux tirets accolés)
pour signaler que ce qui suit dans leur ligne de commande ne contient plus d’options, et ne doit donc
plus être interprété. Il suffit donc de faire précéder le nom du fichier par deux tirets pour arrêter
l’interprétation des options. Par exemple, pour afficher les informations relatives à un fichier nommé
« -l », il faudrait utiliser la commande suivante :

ls -l -- -l

Opérations de base sur les fichiers

Vous aurez sans doute à afficher le contenu d’un fichier. Pour cela, la commande la plus appropriée est
certainement la commande less :

less fichier

Cette commande affiche le contenu du fichier et vous permet de le faire défiler avec les flèches du
curseur. Lorsque vous désirez terminer la visualisation, il suffit de taper la touche q (pour « quitter »
less). Pour information, le nom de la commande less provient d’un trait d’humour sur une commande
Unix plus classique, la commande more. Cette commande effectue à peu près le même travail que less,
mais elle n’affiche le texte que page par page. Pour passer à la page suivante, il faut appuyer sur la barre
d’espace. Quant à l’origine du nom de la commande more, c’est qu’elle affiche le mot « more » au bas
de l’écran pour indiquer qu’il y a encore du texte à visualiser, et qu’il faut appuyer sur la barre d’espace
pour lire la suite.
La commande less permet également d’effectuer une recherche dans le fichier en cours d’édition. Pour
cela, il suffit de taper une commande de recherche de less. Cette commande commence par une barre
oblique, suivie du texte à chercher. Par exemple, pour rechercher la chaîne de caractères « local » dans
un fichier en cours de visualisation avec less, il suffit de taper :

/local

Lorsque vous voudrez rechercher l’occurrence suivante du motif de recherche, vous pourrez appuyer sur
la touche n (pour « Next » en anglais). Pour rechercher l’occurrence précédente, il suffit de taper la
touche N (en majuscule, cette fois).
Il est encore plus probable que vous aurez à éditer un fichier. Cette opération peut se faire relativement
facilement grâce à un éditeur simplifié, vi. Cet éditeur n’est pas franchement ce qui se fait de plus

64
 Chapitre 5. Commandes Unix de base

convivial, cependant, il existe sur toutes les plates-formes Unix d’une part, et il est suffisamment léger
pour pouvoir fonctionner sur un système minimal. Il est donc recommandé de savoir se servir de vi, ne
serait-ce que dans le cas où votre système ne serait pas complètement fonctionnel. En clair, quand tout va
mal, on peut compter sur vi ! vi sera décrit plus loin dans la la section intitulée vi, l’éditeur de fichiers de
base, car il dispose d’un grand nombre de commandes et il ne serait pas opportun de les décrire ici.
En général, la création d’un fichier se fait avec vi, bien que d’autres commandes puissent créer des
fichiers. En revanche, pour supprimer un fichier, il n’existe qu’une seule commande :

rm chemin

où chemin est le chemin complet permettant d’accéder au fichier à supprimer. Il est possible de spécifier
plusieurs fichiers à la commande rm. Dans ce cas, ils seront tous supprimés. rm est également capable
de supprimer tous les fichiers d’un répertoire, ainsi que ses sous-répertoires. Dans ce cas, elle détruit
toute une branche de l’arborescence du système de fichiers. Pour cela, il suffit d’utiliser l’option -r (pour
« récursif ») avant le chemin du répertoire à supprimer.

Attention ! : La commande rm ne demande aucune confirmation avant de supprimer les fichiers !

D’autre part, les fichiers supprimés sont irrémédiablement perdus (il n’y a pas de commande
« undelete » ou autre commande similaire). Vérifiez donc bien ce que vous avez tapé avant de
valider une commande rm (surtout si vous êtes sous le compte root). Il peut être judicieux de forcer
la commande rm à demander confirmation avant la suppression des fichiers, à l’aide de son option
-i. On pourra pour cela définir un alias « rm -i » pour la commande rm dans le fichier
d’initialisation du shell (c’est-à-dire le fichier .bashrc pour le shell bash). La notion d’alias sera
décrite dans la la section intitulée Les alias.

La copie d’un fichier se fait avec la commande cp, dont la syntaxe est donnée ci-dessous :

cp fichiers répertoire

où fichiers est la liste des fichiers à copier, et répertoire est le répertoire destination dans lequel
ces fichiers doivent être copiés.
Enfin, le déplacement des fichiers se fait avec la commande mv, comme indiqué ci-dessous :

mv source destination

où source est le nom du fichier source et destination est le nom du répertoire destination. Notez que
mv est une commande très puissante, puisqu’elle permet également de déplacer des répertoires et de
renommer des fichiers et des répertoires. Pour renommer un fichier ou un répertoire, il suffit d’indiquer le
nouveau nom de ce fichier ou de ce répertoire à la place de destination.

Autres commandes utiles

Pour terminer ce petit cours d’Unix, nous allons décrire quelques-unes des autres commandes d’Unix
parmi les plus utiles. Elles sont utilisées moins souvent que les commandes vues précédemment, mais
vous apprendrez certainement très vite à vous en servir, car elles sont très pratiques.

65
 Chapitre 5. Commandes Unix de base

Gestion des liens

La commande pour créer un lien est ln. Cette commande utilise la syntaxe suivante :

ln [-s] source lien

où source est le nom du fichier ou du répertoire source auquel le lien doit se référer, et lien est le nom
du lien. L’option -s permet de créer un lien symbolique. Par défaut, ce sont des liens physiques qui sont
créés. Rappelons qu’il est impossible de créer des liens physiques sur des répertoires.
Lorsqu’on liste des fichiers, on peut demander l’affichage d’informations complémentaires sur les liens.
Pour cela, il suffit d’utiliser l’option -l de la commande ls. Ainsi, la commande suivante :

ls -l lien

permet d’afficher les informations sur le lien lien, et en particulier le fichier ou le répertoire cible de ce
lien.
La suppression des liens se fait exactement comme celle d’un fichier. La destination n’est pas affectée en
général, sauf si le lien est un lien physique et constitue la dernière référence au fichier pointé par le lien.
Les liens symboliques n’ont pas de droits d’accès ni de propriétaires, les informations de sécurité de la
cible sont utilisées lorsqu’on accède au lien.

Recherche de fichiers
Il vous sera sans doute nécessaire de rechercher des fichiers selon un critère donné dans toute une
arborescence de répertoires. Pour cela, vous utiliserez la commande find. Cette commande est très
puissante, mais dispose d’une syntaxe assez compliquée :

find répertoire -name nom -print

où répertoire est le répertoire à partir duquel la recherche doit commencer et nom est le nom du
fichier à rechercher. Ce nom peut contenir des caractères génériques du shell, mais dans ce cas doit être
placé entre guillemets afin d’éviter que ce dernier ne les interprète.
find accepte d’autres options de recherche que le nom (partie « -name » de la ligne de commande), et
peut effectuer d’autres actions que l’affichage du chemin des fichiers trouvés (partie « -print »).
Consultez les pages de manuel pour plus d’informations à ce sujet.

Recherche d’un texte dans un fichier

La recherche d’une chaîne de caractères dans un ou plusieurs fichiers peut se faire à l’aide de la
commande grep. Cette commande prend en premier paramètre le texte à rechercher, puis la liste des
fichiers dans lequel ce texte doit être trouvé :

grep texte fichiers

66
 Chapitre 5. Commandes Unix de base

Le texte peut être placé entre guillemets si nécessaire (en particulier, s’il contient des espaces ou des
caractères interprétés par le shell, comme * et ?). grep accepte un grand nombre d’options, qui ne seront
pas décrites ici. Consulter les pages de manuel pour plus d’information à ce sujet.

Remplacement de texte dans les fichiers

Le remplacement de texte dans un fichier peut être effectué de manière automatique, c’est-à-dire sans
avoir à ouvrir le fichier dans un éditeur, grâce à la commande sed (abréviation de l’anglais « Stream
Editor »). Cette commande est en fait un utilitaire de manipulation de flux de données, qui permet
d’effectuer des traitements plus généraux que le simple remplacement de texte, mais c’est malgré tout
pour cette opération qu’elle reste la plus utilisée.
sed peut travailler à la volée sur un flux de données textuelles, que ce flux provienne de l’entrée standard
ou d’un fichier. Par défaut, il écrit le résultat de son travail sur le flux de sortie standard. Les opérations
qu’il doit effectuer sur le flux de données peuvent être spécifiées de différentes manières, soit en
fournissant un fichier script à l’aide de l’option -f, soit directement sur la ligne de commande, avec
l’option -e. La syntaxe utilisée pour appeler sed est donc typiquement la suivante :

sed -e "commandes" fichier > résultat

ou :

sed -f script fichier > résultat

où fichier est le fichier sur lequel sed doit travailler, et résultat est le fichier devant recevoir le flux
de données modifiées. Notez que cette commande utilise une redirection du flux de sortie standard dans
un fichier. Ce type de redirection sera décrit en détail dans la la section intitulée Redirections.
sed peut effectuer un grand nombre de commandes différentes et est réellement un outil très puissant.
Cependant, nous ne verrons ici que la commande qui permet d’effectuer un remplacement de texte. Cette
commande utilise la syntaxe suivante :

s/texte/remplacement/options

où texte est le texte à rechercher, remplacement est le texte de remplacement, et options est un jeu
d’options exprimant la manière dont le remplacement doit être fait. Les options sont spécifiées à l’aide de
simple caractères, les plus utiles étant sans doute g, qui permet d’effectuer un remplacement global (au
lieu de ne remplacer que la première occurrence du texte rencontrée dans chaque ligne), et I, qui permet
d’effectuer une recherche sans tenir compte de la casse des caractères.
Par exemple, la ligne de commande suivante :

sed -e "s/bonjour/bonsoir/g" [Link] > [Link]

permet de remplacer toutes les occurrences de la chaîne de caractères « bonjour » par la chaîne de
caractères « bonsoir » dans le texte du fichier [Link], et d’enregistrer le résultat dans le fichier
[Link].

Note : Il ne faut pas utiliser le même nom de fichier pour le fichier source et le fichier de résultat. En
effet, sed lit le fichier source à la volée, et effectuer une redirection sur ce fichier pendant son
traitement provoquerait la perte irrémédiable de son contenu. Pour résoudre ce problème, on pourra

67
 Chapitre 5. Commandes Unix de base

utiliser un nom de fichier temporaire, et écraser le fichier original par ce fichier une fois la commande
sed exécutée.

Compression et décompression des fichiers

Linux fournit un grand nombre de programmes de compression de fichiers. Le meilleur est sans doute
bzip2, et le plus compatible sans doute compress. Cependant, le plus utilisé et le plus courant, surtout
pour la distribution des sources, reste incontestablement gzip. Nous allons décrire brièvement comment
compresser et décompresser des fichiers avec gzip et bzip2 dans ce paragraphe.
La compression d’un fichier se fait de manière élémentaire :

gzip fichier

où fichier est le fichier à compresser. Après avoir effectué son travail, gzip renomme le fichier
compressé en « [Link] ». La compression d’un fichier avec bzip2 utilise exactement la même
syntaxe, à ceci près qu’il faut remplacer gzip par bzip2. De plus, le nom du fichier compressé porte
l’extension .bz2 au lieu de .gz. Le fichier obtenu est donc nommé « fichier.bz2 ».
La décompression d’un fichier se fait à l’aide de la commande suivante :

gunzip [Link]

ou

bunzip2 fichier.bz2

selon qu’il a été compressé avec gzip ou bzip2. Après décompression, l’extension complémentaire .gz
ou .bz2 est supprimée du nom de fichier.

Archivage de fichiers
L’archivage de fichiers se fait classiquement sous Unix avec le programme tar (abréviation de l’anglais
« Tape ARchiver »). Ce programme permet simplement de regrouper tous les fichiers qu’il doit archiver
dans un seul fichier structuré en blocs. Il a été initialement écrit pour permettre des archivages sur bandes
ou sur tout autre périphérique de stockage de masse, mais il est également utilisé pour créer des fichiers
archives contenant toute une arborescence.
La syntaxe de tar est très simple :

tar options archive [fichiers]

où options sont les options qui indiquent l’opération à effectuer et comment elle doit être réalisée,
archive est le nom de l’archive qui doit être créée ou le nom du fichier de périphérique du périphérique
d’archivage, et fichiers est la liste des fichiers à archiver.
Les options de tar que vous utiliserez le plus souvent sont les suivantes :

• cvf pour créer une archive ;

68
 Chapitre 5. Commandes Unix de base

• tvf pour lister le contenu d’une archive ;

• xvf pour restaurer le contenu d’une archive.

Par exemple, pour archiver le contenu du répertoire courant dans le fichier [Link], vous utiliserez
la ligne de commande suivante :

tar cvf [Link] *

De plus, pour extraire le contenu de l’archive [Link], vous utiliserez la commande suivante :

tar xvf [Link]

Note : L’option z permet d’effectuer une compression des données archivées ou une décompression
des données restaurées à la volée. tar utilise gzip et gunzip pour la compression et la
décompression. De même, l’option j permet de compresser l’archive à la volée avec bzip2.
Si l’on utilise un signe négatif (’-’) à la place du nom de l’archive, tar enverra le résultat de la
compression vers la sortie standard. Cela peut être utilisé pour des opérations avancées. Un
exemple sera donné dans la la section intitulée Redirections.

Passage en mode superviseur

Si vous êtes prudent, vous avez sans doute créé un compte utilisateur juste après avoir installé votre
système de base, et vous ne travaillez plus que dans ce compte. Cette technique est prudente, cependant,
elle pose un problème évident : vous ne pouvez pas y faire votre travail d’administrateur. C’est pour cela
que la commande su a été créée. Cette commande permet de changer son identité dans le système :

su [utilisateur]

où utilisateur est l’utilisateur dont on veut prendre l’identité. Par défaut, si aucun utilisateur n’est
spécifié, le changement d’identité se fait vers l’utilisateur root. Bien entendu, il va de soi que la
commande su demande le mot de passe avant d’obtempérer...

Changement des droits des fichiers, du propriétaire et du

groupe
Les mécanismes de droits d’accès ont déjà été décrits en détail ci-dessus dans le chapitre concernant les
notions générales sur Unix. Il peut être judicieux de relire ce chapitre afin de comprendre les effets des
commandes présentées dans cette section.

69
 Chapitre 5. Commandes Unix de base

Changement de propriétaire et de groupe

Le changement de propriétaire d’un fichier ne peut être réalisé que par l’administrateur du système. Cette
opération se fait à l’aide de la commande suivante :

chown utilisateur fichier

où utilisateur est le nom de l’utilisateur qui doit devenir propriétaire du fichier, et fichier est le
fichier devant changer de propriétaire.
Le changement de groupe peut être réalisé par n’importe quel utilisateur, mais on ne peut donner un
fichier qu’à l’un des groupes dont on est membre. Cette opération se fait à l’aide de la commande
suivante :

chgrp groupe fichier

où groupe est le nom du groupe qui doit être affecté au fichier, et fichier est le fichier devant changer
de groupe. Bien entendu, l’administrateur peut affecter un fichier à n’importe quel groupe d’utilisateur.

Modification des droits Unix sur les fichiers

La commande permettant de changer les droits d’un fichier ou d’un répertoire est la suivante :

chmod droits fichier

où fichier est le fichier ou le répertoire dont on désire changer les droits, et droits est une chaîne de
caractères permettant de spécifier les nouveaux droits. Cette chaîne commence par une lettre indiquant le
groupe d’utilisateurs auquel le droit doit être appliqué, d’un caractère + ou - indiquant si le droit doit être
ajouté ou supprimé, et d’une lettre indiquant le droit que l’on est en train de manipuler. La première lettre
peut prendre les valeurs suivantes :

• u pour le champ « utilisateur », c’est-à-dire le propriétaire du fichier ;

• g pour le champ « groupe », c’est-à-dire tous les utilisateurs faisant partie du groupe du fichier ;
• opour le champ « other », c’est-à-dire pour tous les utilisateurs qui ne sont ni propriétaires, ni
membres du groupe du fichier ;
• a pour tous les champs sans distinction, donc pour tous les utilisateurs.

Les droits sont identifiés par l’un des caractères suivants :

• r pour le droit de lecture ;

• w pour le droit d’écriture ;
• x pour le droit d’exécution ;
• s pour les bits setuid et setguid ;
• t pour le bit sticky.

70
 Chapitre 5. Commandes Unix de base

Ainsi, la commande suivante :

chmod g+w exemple

permet de donner le droit d’écriture sur le fichier exemple à tous les membres du groupe auquel ce
fichier appartient.

Utilisation des ACLs

Si l’on veut donner des droits à un utilisateur ou un groupe particulier, on pourra définir une ACL
(« Access Control List ») sur le fichier ou le répertoire, et affecter les droits unitairement. Ceci se fait
simplement avec la commande setfacl, de la manière suivante :

setfacl -m ACL fichier

où ACL est l’ACL à affecter au fichier ou au répertoire fichier. Les ACLs sont constitués d’une liste
d’entrées nommées des ACE (« Access Control Entries »). Les ACEs sont séparées par des virgules et
définissent chacune un droit. Chacun de ces droits doit être spécifié de manière complète, en précisant la
classe d’utilisateur sur lequel il porte avec un mot-clé (user pour l’utilisateur propriétaire, group pour
les utilisateurs du groupe propriétaire, ou other pour les autres utilisateurs), le nom de l’utilisateur ou
du groupe si nécessaire, et les droits affectés à cet utilisateur ou à ce groupe. Tous ces paramètres doivent
être séparés par deux points (caractère ’:’). Par exemple, pour ajouter les droits d’écriture à l’utilisateur
alfred sur le fichier exemple, vous pourrez utiliser la commande suivante :

setfacl -m user:alfred:w exemple

Si l’on ne spécifie aucun utilisateur avec la classe d’utilisateurs user dans une entrée, cette entrée se
réfère automatiquement à l’utilisateur propriétaire du fichier ou du répertoire. De même, si l’on ne
spécifie aucun groupe avec la classe d’utilisateurs group, l’entrée se réfère au groupe auquel le fichier
appartient. Fixer ces entrées d’ACL sur un fichier avec ces deux syntaxes revient donc exactement à
utiliser chmod avec les droits Unix classiques (à un détail près que l’on verra ci-dessous pour le groupe).
Les droits complets d’un fichier ou d’un répertoire peuvent être consultés avec la commande getfacl.
Cette commande affiche en commentaire les informations sur l’objet auquel elle s’applique, à savoir son
nom, son propriétaire et son groupe, à la suite d’un dièze (caractère ’#’). Suivent toutes les ACEs
affectées à cet objet. Les droits Unix classiques sont lisibles directement avec les entrées user::,
group:: et other:: respectivement pour l’utilisateur, les utilisateurs du groupe et les autres
utilisateurs. Par exemple, si l’on affiche les ACLs associées au fichier exemple après la commande
précédente, on obtient ceci :

# file: exemple
# owner: batman
# group: users
user::rw-
user:alfred:-w-
group::r--
mask::rw-
other::r--

71
 Chapitre 5. Commandes Unix de base

Dès qu’une ACL nominative a été attribuée à un fichier, une ACL spéciale est créée automatiquement. Il
s’agit de l’ACL mask, qui, comme son nom l’indique, définit un masque de droits complémentaires pour
tous les utilisateurs et les groupes ajoutés nominativement à l’ACL. Pour ces utilisateurs, les droits
effectivement accordés sont leurs droits respectifs, restreints aux droits présent dans le masque. Le
masque permet donc de restreindre les droits de tous les utilisateurs de la classe group, au sens large.
Par exemple, si le masque contient les droits de lecture et d’écriture, et que l’utilisateur alfred dispose
des droits de lecture et d’exécution sur le fichier, ses droits effectifs seront uniquement la lecture. Les
droits effectifs sont indiqués en commentaire par getfacl pour les utilisateurs et les groupes s’ils ne sont
pas égaux aux droits indiqués dans leurs entrées respectives.
Dès qu’il est défini, le masque remplace l’entrée du groupe du fichier pour les commandes classiques.
Ainsi, dès qu’un masque est défini dans l’ACL d’un fichier, les changements de droits sur le groupe
effectués avec la commande chmod ne modifient plus que le champ de masque. Cela peut surprendre
dans certains situation. Par exemple, si l’entrée de l’ACL décrivant les droits du groupe du fichier ne
donne aucun droit, les utilisateurs de ce groupe n’auront toujours aucun droit même après un chmod
g+rwx sur le fichier. En effet, cette dernière commande ne modifie que le masque. Il est donc nécessaire
d’ajouter les droits sur le groupe du fichier explicitement avec setfacl, de la manière suivante :

chmod g+rwx exemple

setfacl -m group::rwx exemple

La première commande modifie les droits sur le masque, et la deuxième ajoute les droits pour tous les
utilisateurs du groupe.
Notez bien que le masque ne s’applique pas pour la détermination des droits du propriétaire et des
utilisateurs de la classe other. Par ailleurs, lorsque l’on affiche les droits étendus d’un fichier avec
l’option -l de la commande ls, les droits affichés pour le groupe du fichier sont les droits définis dans le
masque lui-même (même si aucune entrée d’ACL ne donne complètement ces droits à un utilisateur ou à
un groupe). Cela permet donc de voir directement les droits les plus forts qui pourraient être attribués sur
ce fichier, ce qui est cohérent avec ce qu’attendent les outils Unix classiques.
Il est possible de supprimer toutes les entrées de l’ACL d’un fichier avec l’option -b de setfacl. Pour
supprimer une entrée spécifique de l’ACL, vous devrez utiliser l’option -x. Cette dernière option ne
permet pas de supprimer les entrées génériques pour le propriétaire et le groupe du fichier, ni celles des
autres utilisateurs. Par exemple, pour retirer toutes les entrées définies précédemment sur le fichier
exemple, on utilisera la commande suivante :

setfacl -b exemple

Vous pourrez toutefois constater que getfacl continue d’afficher les entrées génériques « user:: »,
« group:: » et « other:: ».
Les répertoires disposent, en plus de leur ACL normale, d’une ACL par défaut. L’ACL par défaut d’un
répertoire est celle qui est appliquée à tout nouveau fichier ou répertoire créés dans ce répertoire. De
plus, les sous-répertoires héritent de l’ACL par défaut de leur parent. Les ACLs par défaut sont
modifiables avec l’option -d de setfacl et sont affichées avec le préfixe default: par getfacl.

Note : Notez bien que de nombreux outils Unix classiques ne gèrent pas correctement la notion
d’ACL (en particulier les gestionnaires de fichiers graphiques). La copie ou la modification d’un fichier

72
 Chapitre 5. Commandes Unix de base

peut donc provoquer la perte de son ACL, modifiant ainsi les droits des utilisateurs sur ce fichier. Les
ACLs doivent donc être utilisées avec parcimonie et leur manipulation entourée du plus grand soin.

vi, l’éditeur de fichiers de base

Vous serez obligé, lorsque vous effectuerez la configuration de votre système, d’éditer les fichiers de
configuration (classiquement, ces fichiers sont placés dans le répertoire /etc/). Ces modifications
peuvent être réalisées avec n’importe quel éditeur a priori, et il est même conseillé d’utiliser votre éditeur
favori. Cependant, il faut savoir se servir de vi, parce que c’est le seul éditeur qui sera toujours installé, et
qui fonctionnera en toutes circonstances. Le prix à payer pour cette fiabilité est un nombre restreint de
fonctionnalités. En fait, vi est très puissant, mais il ne s’embarrasse pas de superflu, ce qui en fait
certainement l’éditeur le moins convivial du monde. Ce paragraphe vous donnera la liste des principales
commandes de vi. Cette liste ne sera toutefois pas exhaustive, car vous n’utiliserez certainement pas vi
dans la vie courante.
Pour éditer un fichier avec vi, il suffit de passer le nom de ce fichier en ligne de commande :

vi fichier

Il est possible de passer plusieurs fichiers dans la ligne de commande, et vi les éditera les uns après les
autres. Cependant, il faut savoir que vi ne permet de travailler que sur deux fichiers à la fois, et qu’il n’est
pas facile de passer de l’un à l’autre. Par conséquent, il est conseillé de n’éditer qu’un seul fichier à la
fois.
vi est un éditeur qui fonctionne dans plusieurs modes différents : le mode d’édition, dans lequel le texte
peut être modifié, le mode de commande, dans lequel des commandes particulières peuvent être données,
et le mode de visualisation, dans lequel le fichier ne peut être que visualisé. Par défaut, vi est en mode de
visualisation, et il faut utiliser une commande d’édition pour passer en mode d’édition. Quand on est en
mode d’édition, on peut revenir au mode de visualisation en appuyant sur la touche Echap (ou Esc,
selon votre clavier). Cette touche a aussi une signification dans le mode de commande : elle annule la
saisie de la commande en cours. Par conséquent, lorsqu’on est perdu et que l’on ne sait plus dans quel
mode on se trouve (ce qui arrive fatalement à un moment donné), il suffit d’appuyer sur cette touche. On
sait alors qu’on se trouve en mode de visualisation.
Le déplacement du curseur en mode de visualisation se fait avec les touches du curseur. Cependant, si
votre clavier n’est pas bien configuré, ces touches peuvent ne pas fonctionner. C’est pour cette raison que
vi fournit un jeu de touches alternatif :

• la touche h permet de déplacer le curseur vers la gauche ;

• la touche l permet de déplacer le curseur vers la droite ;
• la touche j permet de déplacer le curseur vers le bas ;
• la touche k permet de déplacer le curseur vers le haut.

73
 Chapitre 5. Commandes Unix de base

Le curseur est bien entendu déplacé automatiquement lors de la saisie du texte en mode d’édition.
Le passage en mode d’édition peut se faire avec l’une des commandes suivantes :

• la touche i permet de passer en mode d’insertion (le texte saisi s’insère avant le caractère sur lequel le
curseur est positionné) ;
• la touche a permet de passer en mode d’ajout de caractères (le texte saisi s’insère après le caractère sur
lequel le curseur est positionné) ;
• la touche A permet de placer le curseur en fin de ligne et de passer en mode d’ajout de caractères ;
• la touche o permet de créer une nouvelle ligne après la ligne où se trouve le curseur et de passer en
mode d’édition sur cette nouvelle ligne ;
• la touche O permet de créer une nouvelle ligne avant la ligne où se trouve le curseur et de passer en
mode d’édition sur cette nouvelle ligne.

La création d’une nouvelle ligne peut donc être faite avec les commandes o et O, mais il est possible de
couper une ligne en deux, ou de passer à la ligne simplement en tapant sur la touche Entrée en mode
d’édition. Inversement, la commande J permet de supprimer un saut de ligne en fin de ligne et de placer
ainsi le texte de la ligne suivante à la suite du texte de la ligne courante.
La suppression d’un caractère se fait avec la touche Suppr (ou Del, selon le clavier) ou la touche de
retour arrière (dite touche Backspace). Cependant, encore une fois, vi fournit un jeu de touches
alternatif permettant de travailler avec un clavier mal configuré :

• la commande x permet d’effacer le caractère situé sous le curseur ;

• la commande dd permet d’effacer la ligne où se trouve le curseur ;
• la commande dw permet d’effacer le mot où se trouve le curseur.
Le texte qui a été supprimé est placé dans ce que l’on appelle un buffer. Le contenu du buffer peut être
inséré à n’importe quel endroit du fichier grâce à la commande p. Ainsi, il est possible de faire un
couper/coller en effaçant la ligne désirée et en appuyant sur la touche p à l’emplacement destination.
La commande u permet d’annuler la dernière opération effectuée, et la commande U permet de la
ré-exécuter.
La commande yy permet de copier la ligne courante dans le buffer. Cette commande est donc utilisée
pour effectuer des copier/coller, en combinaison avec la commande p.
Les commandes de vi peuvent être répétées un certain nombre de fois, en spécifiant ce nombre avant de
les écrire. Ainsi, pour supprimer 3 lignes, il suffira de taper la commande suivante :

3dd

Dans ce cas, ces trois lignes sont également placées dans le buffer. La même technique peut être utilisée
pour copier/coller plusieurs lignes en une seule opération.

74
 Chapitre 5. Commandes Unix de base

Enfin, vi accepte un certain nombre de commandes générales lorsqu’il est en mode de commande. Ce
mode est activé dès que l’on appuie sur la touche deux points (’:’) dans le mode de visualisation. Les
commandes générales les plus utiles sont décrites ci-dessous :

• la commande :q permet de quitter vi. Si le fichier en cours d’édition a été modifié, vi refusera de se
terminer sans l’enregistrer. Si l’on veut malgré tout sortir sans l’enregistrer, il faudra utiliser la
commande :q! ;
• la commande :w permet d’enregistrer le fichier courant. Pour enregistrer ce fichier et quitter vi, la
commande :wq peut être utilisée ;
• la commande :help sujet permet d’obtenir de l’aide sur le sujet « sujet » ;
• la commande :!commande permet d’exécuter la commande du shell « commande ». Cela peut être
pratique pour effectuer une opération dans le shell sans avoir à quitter vi. Cela dit, il sera sans doute
plus efficace d’utiliser un autre terminal virtuel.

Comme vous l’avez constaté, vi est réellement une horreur à utiliser. Malgré tout, il permet de faire tout
ce dont on a besoin pour éditer un fichier. Il dispose même de puissantes fonctionnalités que même les
traitements de texte évolués ne sont pas capables de faire. Elles ne seront cependant pas décrites ici, car
cela dépasserait le cadre de la simple installation de Linux. Vous pourrez toujours consulter l’aide de vi
pour de plus amples informations.

Utilisation du shell bash

Le shell est l’environnement utilisateur en mode texte sous Linux. C’est le programme qui se charge de
lire et d’exécuter les commandes que l’utilisateur saisit. Classiquement, le shell est utilisé de manière
interactive, c’est-à-dire que l’utilisateur dialogue avec le système par l’intermédiaire du shell. Il saisit les
commandes, et le shell les exécute et affiche les résultats. Le shell le plus couramment utilisé sous Linux
est sans aucun doute bash. En tout cas, c’est le shell par défaut que la plupart des distributions utilisent. Il
est donc conseillé de connaître un petit peu ce que ce shell est capable de réaliser, et comment. Le shell
bash est une évolution du shell sh, utilisé par quasiment tous les systèmes Unix. Son nom provient de
l’abréviation de l’anglais « Bourne Again SHell », ce qui signifie qu’il s’agit effectivement d’une
nouvelle variante du shell sh.
Au temps des interfaces graphiques complexes et sophistiquées, il peut paraître archaïque de vouloir
encore utiliser des lignes de commandes pour utiliser un ordinateur. C’est en partie vrai, mais il faut
savoir que les shells Unix sont extrêmement puissants et que les interfaces graphiques ne permettent
toujours pas, même à l’heure actuelle, de réaliser toutes les tâches faisables avec un shell. D’autre part, il
est souvent plus efficace de taper une simple commande dans un shell que de rechercher un outil
graphique et de parcourir les divers menus, puis de choisir les options de la commande désirée avant de
valider. Des ergonomes ont démontré, et des graphistes du monde entier le confirmeront, que la souris
n’est pas le périphérique d’entrée le plus précis et le plus facile à utiliser pour manipuler les objets de
l’environnement utilisateur. La plupart des programmeurs utilisent encore bon nombre de ce qu’on
appelle des « raccourcis clavier » pour exécuter des commandes, même dans les environnements
utilisateurs graphiques.

75
 Chapitre 5. Commandes Unix de base

Quoi qu’il en soit, le shell est bien plus qu’un interpréteur de commande. Il s’agit réellement d’un
environnement de programmation, permettant de définir des variables, des fonctions, des instructions
complexes et des programmes complets, que l’on appelle des scripts shell. Les sections suivantes ont
pour objectif de vous montrer les principales caractéristiques du shell, sans pour autant prétendre vous
apprendre la programmation des scripts shell. La lecture de cette section pourra donc être différée dans
un premier temps. Toutefois, elle pourra être bénéfique à ceux qui désirent comprendre les scripts de
configuration utilisés par leur distribution, ou tout simplement à ceux qui sont curieux de nature.

Contrôle des processus

Un des avantages des lignes de commandes par rapport aux environnements graphiques est la facilité
avec laquelle elles permettent de contrôler les processus. Ce paragraphe décrit les principales méthodes
pour lancer et arrêter un processus, ainsi que pour lui fournir les données sur lesquelles il doit travailler
et récupérer ses résultats.

Lancement d’un programme en arrière-plan

Le lancement normal d’un programme se fait en tapant sa ligne de commande et en appuyant sur la
touche de validation. Le shell ne rendra pas la main et ne permettra pas de lancer un autre programme
tant que le processus en cours ne sera pas terminé. Cependant, vous pouvez fort bien désirer lancer en
arrière-plan une commande dont la durée d’exécution peut être très longue et continuer à travailler. Après
tout, Linux est multitâche... Eh bien, rien de plus facile !
Pour lancer une commande en arrière-plan, il faut :

• s’assurer que la commande aura toutes les informations nécessaires pour travailler sans intervention de
l’utilisateur (ou, autrement dit, que la commande n’est pas interactive) ;
• ajouter une esperluette (caractère « & ») à la fin de la ligne de commande.

Par exemple, la commande suivante :

cp /cdrom/kernel/[Link] . &

copiera l’archive du noyau 2.6.6 du CD-ROM vers le répertoire courant, et s’exécutera en arrière-plan.
Lorsqu’une commande est lancée en arrière-plan, le shell affiche deux nombres qui permettront de
l’identifier par la suite. Le premier nombre, indiqué entre crochets, est le numéro de « job » du shell. Ce
numéro sert à identifier les commandes du shell de manière unique. Un job est donc en réalité une
commande du shell, simple ou complexe. Le deuxième numéro est le numéro de processus (« PID »,
pour « Process IDentifier ») dans le système du processus maître du job. Le PID est un numéro unique
dans le système, qui permet d’identifier de manière unique les processus en cours. Ces deux nombres
permettront de manipuler les processus, avec les commandes que l’on verra plus tard.
Il ne faut pas confondre les numéros de job avec les numéros de processus. Premièrement, un numéro de
job n’est unique que dans un shell donné, et n’a aucune signification au niveau du système complet, alors
que le numéro de processus est attribué par le système à chaque programme en cours d’exécution.
Ensuite, une même commande du shell peut lancer plusieurs processus conjointement. Dans ce cas, il y a
bien évidemment plusieurs numéros de processus, mais un seul et unique job. Ce genre de situation se

76
 Chapitre 5. Commandes Unix de base

produit par exemple lors de l’utilisation d’une redirection du flux de sortie standard d’un processus vers
le flux d’entrée standard d’un autre processus.
Le numéro de processus affiché par le shell lors du lancement d’une ligne de commande complexe
représente le PID du processus maître de la commande, c’est-à-dire, en pratique, le dernier processus
d’une série de redirections ou le processus du shell exécutant les commandes complexes. Cela signifie
que dans tous les cas de configuration, ce PID est celui du processus qui contrôle l’ensemble des
opérations effectuées par la ligne de commande. C’est donc par ce processus que l’on peut manipuler la
commande complète, par exemple pour l’interrompre.
Il est possible de retrouver le PID du processus maître d’une commande à partir du numéro de job
correspondant du shell. Cela se fait simplement, en utilisant l’expressions suivante :

%job

où job est le numéro du job dont on cherche le PID. Ainsi, dans toutes les commandes décrites
ci-dessous, le PID peut être utilisé directement, ou être remplacé par le numéro du job préfixé du
caractère de pourcentage.

Listing des processus

Il n’est pas nécessaire de retenir tous les numéros de jobs et tous les PID des processus en cours
d’exécution. Il existe en effet des commandes permettant d’obtenir la liste des processus et des jobs. La
plus simple à utiliser est bien évidemment la commande du shell pour obtenir la liste des jobs avec leurs
lignes de commandes. Pour obtenir cette liste, il suffit de taper la commande suivante :

jobs

qui affiche, dans l’ordre, le numéro de job, l’état du processus correspondant, et la ligne de commande.
Une autre commande, plus bas niveau, permet d’obtenir des informations plus complètes directement à
partir du système. Il s’agit de la commande ps, dont la syntaxe est donnée ci-dessous :

ps [options]

Les options les plus utiles sont sans doute x, qui permet de demander l’affichage de toutes les
commandes en cours d’exécution et non pas seulement les processus en cours d’exécution dans le shell
où la commande ps est exécutée, et a, qui permet d’obtenir l’affichage de toutes les commandes, pour
tous les utilisateurs connectés. Ces deux options peuvent être cumulées, et la commande suivante :

ps ax

affiche donc toutes les commandes en cours d’exécution sur le système.

Les informations les plus intéressantes affichées par ps sont le PID du processus, qui est donné par le
premier nombre affiché, et la ligne de commande, qui est la dernière information affichée. Pour plus de
détails sur la commande ps, veuillez consulter la page de manuel correspondante.

77
 Chapitre 5. Commandes Unix de base

Notion de signal
Dans un système Unix, tous les processus peuvent recevoir des messages, envoyés soit par l’utilisateur,
soit par un autre processus, soit par le système. Ces messages sont appelés signaux. La plupart des
signaux sont envoyés par le système pour indiquer au processus qu’il a fait une faute et qu’il va être
terminé. Cependant, ce n’est pas toujours le cas : certains signaux sont envoyés uniquement dans le cadre
de la communication entre les processus, et certains autres ne peuvent même pas être captés par le
processus et sont traités directement par le système. Nous n’entrerons pas en détail dans la gestion des
signaux ici, car cela nous emmènerait trop loin. Cependant, la manière d’envoyer un signal à un
processus à partir du shell sera décrite.
L’envoi d’un signal se fait avec la commande kill, avec la syntaxe suivante :

kill [-signal] PID

où signal est une option qui permet de préciser le signal qui doit être envoyé, et PID est le numéro du
processus qui doit le recevoir. Les numéros de signaux les plus importants sont décrits dans le tableau
ci-dessous :

Tableau 5-2. Principaux signaux Unix

Numéro de Signification
signal
15 Signal de terminaison de processus.
9 Signal de destruction inconditionnelle de processus.
19 Signal de suspension de processus.
18 Signal de reprise d’exécution d’un processus suspendu.

Lorsqu’aucun signal n’est spécifié, le signal 15 de terminaison est utilisé par défaut. Ce signal demande
au processus en cours d’exécution de se terminer immédiatement. Il peut être capté par le processus,
pour lui donner une chance d’enregistrer les données sur lesquelles il travaillait et de libérer les
ressources qu’il utilisait. Pour certains processus, cela ne fonctionne pas, et il faut utiliser le signal de
destruction du processus à l’aide de la commande suivante :

kill -9 PID

Attention cependant à cette commande : le processus est immédiatement détruit, sans autre forme de
procès. Il peut donc s’ensuivre une perte de données, n’en abusez donc pas trop.

Arrêt d’un processus

Tout processus lancé en ligne de commande peut être arrêté immédiatement sous Linux. Pour cela, deux
méthodes sont disponibles. La première consiste à taper la combinaison de touches CTRL+C lorsque le
processus est en cours d’exécution interactive (c’est-à-dire lorsqu’il n’a pas été lancé en arrière-plan).
S’il a été lancé en arrière-plan, on peut soit le ramener en avant-plan (avec la commande fg, que l’on
verra plus loin) avant d’utiliser CTRL+C, soit lui envoyer le signal de terminaison à l’aide de la

78
 Chapitre 5. Commandes Unix de base

commande kill vue précédemment. Dans le cas d’une ligne de commande, le signal de terminaison est
transmis au processus maître de la ligne de commande, et est ensuite propagé à l’ensemble des processus
fils de ce processus. Cela signifie que tous les processus invoqués dans le cadre de cette commande sont
également arrêtés.

Gel d’un processus

Il est possible de « geler » un processus en cours d’exécution, c’est-à-dire de le suspendre, sans pour
autant l’arrêter définitivement. Cela peut être utilisé pour libérer un peu les capacités de calcul, lorsque
ce processus consomme trop de ressources par exemple. Pour cela, deux méthodes sont possibles :

• soit on utilise la combinaison de touches CTRL+Z, lorsque le processus est en avant-plan ;

• soit on envoie le signal 19 au processus (signal « STOP ») à l’aide de la commande kill.

La première méthode est recommandée pour les processus lancés par une ligne de commande complexe,
car le signal STOP est envoyé au processus maître de la commande, et est propagé à l’ensemble des
processus fils de ce processus. Cela signifie que tous les processus invoqués dans le cadre de cette
commande sont également gelés. La deuxième méthode est plus bas niveau, et permet de geler n’importe
quel processus que l’on a lancé.

Relancement d’un processus

Un processus suspendu peut être relancé soit en avant-plan, soit en arrière-plan. Pour relancer un
processus en avant-plan, il faut utiliser la commande suivante :

fg [PID]

où PID est le PID du processus à relancer en avant-plan. Si ce paramètre n’est pas spécifié, le dernier
processus stoppé sera relancé en arrière-plan. fg est l’abréviation de l’anglais « foreground », ce qui
signifie « avant-plan ». Il faut attendre que ce processus se termine pour entrer de nouvelles commandes.
Par conséquent, on ne peut lancer en avant-plan qu’un seul processus.
De même, pour lancer un processus en arrière-plan, il faut utiliser la commande bg, qui est l’abréviation
de l’anglais « background ». Cette commande s’utilise de la même manière que la commande fg :

bg [PID]

Le relancement d’un processus suspendu peut également se faire en lui envoyant le signal 18 à l’aide de
la commande kill.

Redirections
Pour pouvoir lancer un programme en arrière-plan, il est nécessaire qu’il n’ait pas besoin de demander
des données à l’utilisateur. En effet, lorsqu’il est en arrière-plan, la saisie de ces données ne peut pas se

79
 Chapitre 5. Commandes Unix de base

faire, puisque le shell les interpréterait comme une nouvelle commande. De plus, tout affichage en
provenance d’une commande en arrière-plan apparaît sur la console tel quel, et risque de se mélanger
avec l’affichage des autres programmes ou même avec la commande en cours d’édition. C’est pour
résoudre ces problèmes que le mécanisme des redirections a été introduit.

Principe de base
Le mécanisme des redirections a pour but de transférer les données provenant d’un flux vers les données
d’un autre flux. Il se base sur la notion de descripteur de fichier, utilisée par la plupart des systèmes Unix.
Un descripteur de fichier est un numéro utilisé par les programmes pour identifier les fichiers ouverts.
Les descripteurs 0, 1 et 2 sont respectivement affectés d’office au flux d’entrée standard (nommé
« stdin »), au flux de sortie standard (« stdout ») et au flux d’erreur standard (« stderr »), qui en général
apparaît également sur l’écran.
Les descripteurs de fichiers d’un processus sont généralement hérités par tous ses processus fils. Cela
signifie que, lors de leur lancement, ces processus peuvent utiliser tous les descripteurs de fichiers mis à
leur disposition par leur père. Dans le cas des lignes de commande, les processus fils sont les processus
lancés par le shell, et les descripteurs de fichiers hérités sont donc les descripteurs de fichiers du shell.
C’est de cette manière que le shell peut manipuler les descripteurs de fichiers des processus qu’il lance :
il effectue d’abord les redirections sur ses propres descripteurs de fichiers, puis il lance le processus fils
avec ces redirections actives. Le mécanisme est donc complètement transparent pour les processus fils.
Le mécanisme des redirections permet en fait d’injecter dans un descripteur de fichier des données
provenant d’un autre descripteur ou d’un fichier identifié par son nom, et d’envoyer les données
provenant d’un descripteur de fichier dans un autre descripteur ou dans un fichier identifié par son nom.
Si l’on utilise les descripteurs de fichiers des flux d’entrée / sortie standards, on peut exécuter n’importe
quelle commande interactive en arrière-plan.

Redirections de données en entrée

Pour injecter des données provenant d’un fichier dans le descripteur de fichier n d’un processus, il suffit
d’ajouter la ligne suivante à la fin de la commande permettant de lancer ce processus :

n<fichier

où fichier est le nom du fichier dont les données doivent être injectées dans le descripteur n. Dans
cette syntaxe, le descripteur peut ne pas être précisé. Dans ce cas, le shell utilisera le descripteur 0, et les
données du fichier seront donc envoyées dans le flux d’entrée standard du processus. Par exemple,
supposons que l’on désire utiliser une commande nommée « search », et que cette commande demande
un certain nombre d’informations lors de son exécution. Si l’on sait à l’avance les réponses aux questions
qui vont être posées, on peut créer un fichier de réponse (nommé par exemple « [Link] ») et alimenter
la commande « search » avec ce fichier. Pour cela, on utilisera la ligne de commande suivante :

search < [Link]

Il est également possible d’injecter des données provenant d’un autre descripteur de fichier dans un
descripteur de fichier. On utilisera pour cela la syntaxe suivante :

80
 Chapitre 5. Commandes Unix de base

n<&s

où n est toujours le descripteur de fichier du processus à exécuter dans lequel les données doivent être
injectées, et s est un descripteur de fichier contenant les données sources à injecter. Par défaut, si n n’est
pas précisé, le flux d’entrée standard du processus sera utilisé.

Redirection de données en sortie

Inversement, il est possible d’enregistrer les données écrites par un processus dans un de ses descripteurs
de fichier dans un fichier. Pour cela, on utilisera l’opérateur ’>’ avec la syntaxe suivante :

n>fichier

où n est le numéro du descripteur de fichier du processus à enregistrer, et fichier est le nom du fichier
dans lequel les données doivent être stockées. Par défaut, si n n’est pas spécifié, le descripteur du flux de
sortie standard sera utilisé (descripteur 1). Par exemple, si la commande précédente affiche des résultats
et que l’on désire les stocker dans le fichier « [Link] », on utilisera la ligne de commande suivante :

search < [Link] >[Link]

Notez que cette commande détruira systématiquement le contenu du fichier « [Link] » et le remplacera
par les informations provenant du flux de sortie standard du processus « search ». Il est possible de ne
pas vider le fichier « [Link] » et d’ajouter les informations en fin de fichier, en utilisant l’opérateur
’>>’ à la place de l’opérateur ’>’. Ainsi, la commande suivante :

search < [Link] >>[Link]

aura pour effet d’ajouter à la fin du fichier « [Link] » les informations affichées par le processus
« search ».
Le flux d’erreur standard, qui correspond normalement à l’écran et qui permet d’afficher les messages
d’erreur, peut être redirigé avec l’opérateur ’2>’, de la même manière que l’opérateur ’>’ est utilisé pour
le flux de sortie standard (puisque c’est le descripteur de fichier utilisé par défaut par l’opérateur ’>’).
Par exemple, si l’on veut envoyer les messages d’erreurs éventuels de la commande précédente vers le
périphérique nul (c’est-à-dire le périphérique qui n’en fait rien) pour ignorer ces messages, on utilisera la
ligne de commande suivante :

search <[Link] >[Link] 2> /dev/null

Une telle ligne de commande est complètement autonome, et peut être lancée en arrière-plan, sans
aucune intervention de l’utilisateur :

search <[Link] >[Link] 2> /dev/null &

81
 Chapitre 5. Commandes Unix de base

Il est également possible d’effectuer une redirection des données provenant d’un descripteur de fichier du
processus vers un autre descripteur de fichier de ce processus. On utilisera pour cela la syntaxe suivante :

n>&d

où n est le descripteur de fichier dont les données doivent être redirigées, et d le descripteur de fichier
destination. Cette syntaxe est souvent utilisée pour rediriger le flux d’erreur standard vers le flux d’entrée
standard, lorsqu’on veut récupérer les erreurs et les messages d’exécution normale dans un même fichier.
Par exemple, si l’on veut rediriger le flux de sortie et le flux d’erreurs de la commande « search » dans un
même fichier, on utilisera la ligne de commande suivante :

search <[Link] >[Link] 2>&1

Cette ligne de commande utilise deux redirections successives pour les données affichées par la
commande « search » : la première redirige le flux de sortie standard vers un fichier, et la deuxième le
flux d’erreur standard vers le flux de sortie standard. Notez que l’ordre des redirections est important.
Elles sont appliquées de gauche à droite. Ainsi, dans la commande précédente, le flux de sortie standard
est redirigé vers le fichier « [Link] », puis le flux d’erreur standard est injecté dans le flux de sortie
standard ainsi redirigé.

Note : Il est également possible d’utiliser un autre descripteur de fichier que les descripteurs des flux
standards. Cependant, il est nécessaire, dans ce cas, d’ouvrir ce descripteur dans le shell avant de
lancer la commande. Cela peut se faire à l’aide de la syntaxe suivante :

n<>fichier

où n est un numéro de descripteur de fichier non encore utilisé, et fichier est un nom de fichier. Ce
nouveau descripteur de fichier pourra être utilisé dans les commandes précédentes, afin de faire
manipuler le fichier fichier par les processus fils de manière transparente.
Les descripteurs de fichiers ouverts de cette manière le restent d’une commande sur l’autre dans le
shell. Cela implique que toutes les données écrites dans ces descripteurs de fichiers sont ajoutées
automatiquement à la fin des fichiers manipulés par ces descripteurs. Ce comportement est différent
de la redirection vers un fichier effectuée par l’opérateur ’>’, qui ouvre à chaque fois le fichier en
écriture à son début et qui supprime donc toutes les données déjà existantes. Il n’y a donc pas
d’opérateur ’>>&’ pour ajouter des données à un descripteur de fichier, car cela n’a pas de sens.
Les descripteurs de fichiers peuvent également être manipulés directement, par l’intermédiaire de
fichiers virtuels du répertoire /dev/fd/. À chaque descripteur de fichier (y compris les descripteurs
pour les flux d’entrée/sortie standards !) y correspond un fichier dont le nom est le numéro du
descripteur. Par exemple, le fichier /dev/fd/2 correspond au flux d’erreur standard.
En fait, le répertoire /dev/fd/ est un lien symbolique vers le répertoire /proc/self/fd/ du système
de fichiers virtuel /proc/. Ce système de fichiers est géré par le noyau directement, et permet
d’accéder aux informations sur le système et les processus. Il contient en particulier un
sous-répertoire portant le nom du PID de chaque processus existant dans le système, et chacun de
ces répertoires contient lui-même un sous-répertoire fd/ où sont représentés les descripteurs de
fichiers ouvert par le processus correspondant. Le système de fichiers /proc/ contient également
un lien symbolique self/ pointant sur le sous-répertoire du processus qui cherche à l’ouvrir. Ainsi,
/proc/self/fd/ est un chemin permettant à chaque processus d’accéder à ses propres
descripteurs de fichiers.

82
 Chapitre 5. Commandes Unix de base

En pratique, la manipulation directe des descripteurs de fichiers n’est réellement intéressante que
pour les flux standards, dont les numéros de descripteurs sont fixes et connus de tous les
programmes. Pour les autres descripteurs, cette technique est souvent inutilisable ou inutile, sauf
lorsqu’on utilise des programmes sachant manipuler des descripteurs de numéros bien déterminés.

Insertion de documents
Il existe un dernier opérateur de redirection, qui n’est utilisé en pratique que dans les scripts shell. Cet
opérateur permet d’insérer directement un texte complet dans le flux d’entrée standard, sans avoir à
placer ce document dans un fichier à part. Cette technique permet donc de stocker des données avec le
code des scripts shell, et de n’avoir ainsi qu’un seul fichier contenant à la fois le script et ses données.
Cet opérateur est l’opérateur ’<<’, il s’utilise selon la syntaxe suivante :

<<EOF
texte
.
.
.
EOF

où texte est le contenu du texte à insérer, et EOF est un marqueur quelconque qui sera utilisé seul sur
une ligne afin de signaler la fin du texte.
Par exemple, il est possible de créer un fichier [Link] de la manière suivante :

cat <<fin >[Link]

Ceci est un fichier texte saisi directement dans le shell.
On peut écrire tout ce que l’on veut, et utiliser les fonctions d’éditions
de ligne du shell si l’on veut.
Pour terminer le fichier, il faut taper le mot "fin" tout seul, au début
d’une ligne vide.
fin

Les tubes
Les redirections sont très pratiques lorsqu’il s’agit d’injecter un fichier dans le flux d’entrée standard
d’un processus, ou inversement de rediriger le flux standard d’une commande vers un fichier, mais elles
ont justement le défaut de devoir utiliser des fichiers. Il est des situations où l’on désirerait injecter le
résultat d’une commande dans le flux d’entrée standard d’une autre commande, sans passer par un fichier
intermédiaire. Cela est heureusement réalisable, grâce à ce que l’on appelle les « tubes ».

Syntaxe des tubes

Pour rediriger le résultat d’une commande dans le flux d’entrée d’une autre commande, il faut utiliser
l’opérateur ’|’. Cet opérateur représente un tuyau canalisant les données issues d’une commande vers le

83
 Chapitre 5. Commandes Unix de base

flux d’entrée standard de la commande suivante, d’où le nom de « pipe » en anglais (ce qui signifie
« tuyau » ou « tube »). L’opérateur tube s’utilise de la manière suivante :

• on écrit la première commande, qui doit fournir les données à la deuxième commande ;
• on écrit l’opérateur tube ;
• on écrit la deuxième commande, qui doit lire les données provenant de la première.
La commande se trouvant à la gauche de l’opérateur tube doit être complète, avec ses autres redirections
éventuelles. La redirection dans un tube s’effectue après les autres types de redirections vues
précédemment.
Le système contrôle l’exécution des processus qui se trouvent aux deux bouts d’un tube, de telle sorte
que le transfert de données puisse toujours se faire. Si le processus source a trop de données, il est figé
par le système d’exploitation en attendant que le processus consommateur ait fini de traiter les données
déjà présentes. Inversement, si le processus source est trop lent, c’est le processus consommateur qui
attendra patiemment que les données soient disponibles.
Les tubes sont utilisés très couramment, ne serait-ce que pour afficher page par page le contenu d’un
répertoire. La commande suivante effectue un tel travail :

ls | less

Ici, le résultat de la commande ls est redirigé vers la commande less, qui permet d’afficher page par page
(et de revenir en arrière dans ces pages) la liste des fichiers du répertoire courant.
Prenons un exemple un peu plus complexe. Supposons que l’on veuille archiver et compresser un
répertoire. Il est possible d’archiver ce répertoire avec la commande tar, puis de compresser le fichier
archive résultant :

tar cvf [Link] *

gzip [Link]

Cette méthode est correcte, mais souffre d’un défaut : elle utilise un fichier intermédiaire, qui peut
prendre beaucoup de place disque. Une méthode plus économe consiste à lancer tar et gzip en parallèle,
et à rediriger la sortie standard de l’un dans le flux d’entrée de l’autre. Ainsi, il n’y a plus de fichier
temporaire, et la place consommée sur le disque est minimale :

tar cv * | gzip > [Link]

La première commande demande à tar d’archiver tous les fichiers du répertoire et d’envoyer le résultat
dans le flux standard de sortie. Le pipe redirige ce flux standard vers le flux d’entrée standard de gzip.
Celui-ci compresse les données et les émet vers son flux standard de sortie, qui est lui-même redirigé vers
le fichier [Link]. Aucun fichier temporaire n’a été utilisé, et on a ainsi économisé l’espace
disque de l’archive complète non compressée, c’est-à-dire environ la taille complète du répertoire à
archiver. Ce genre de considération peut être très important lorsque le disque dur commence à être plein...

84
 Chapitre 5. Commandes Unix de base

Note : En fait, la commande tar de GNU permet de compresser à la volée les données à archiver,
permettant d’éviter de se prendre la tête comme on vient de le faire. Pour cela, il suffit d’utiliser
l’option z dans la ligne de commande de tar. Ainsi, la ligne de commande suivante fournit le même
résultat :

tar cvfz [Link] *

Mais cette solution ne fonctionne pas avec les versions non GNU de tar, qui ne supportent pas cette
option.

Un autre exemple pratique est le déplacement de toute une arborescence de fichiers d’un système de
fichiers à un autre. Vous ne pourrez pas y parvenir à l’aide de la commande mv, car celle-ci ne fait que
modifier la structure du système de fichiers pour déplacer les fichiers et les répertoires, elle ne peut donc
pas fonctionner avec deux systèmes de fichiers. Vous ne pouvez pas non plus utiliser la commande cp,
car celle-ci ne prendra pas en compte les dates des fichiers, leur propriétaire et leur groupe, ainsi que les
liens symboliques et physiques. Il faut donc impérativement utiliser un programme d’archivage. La
méthode à suivre est donc de créer une archive temporaire, puis de se déplacer dans le répertoire
destination, et enfin d’extraire l’arborescence de l’archive :

cd source
tar cvf [Link] *
cd destination
tar xvf source/[Link]
rm source/[Link]

Malheureusement, cette technique nécessite beaucoup de place disque, puisque l’archive temporaire est
stockée directement sur disque. De plus, elle est assez lente, car toutes les données à copier sont
recopiées sur le disque dur, et relues ensuite, pour finalement être détruites... La vraie solution est de
réaliser un tube entre les deux processus tar invoqués. Dans ce cas, le transfert se fait simplement via la
mémoire vive :

cd source
tar cv * | (cd destination ; tar xvf -)

La commande à utiliser est cette fois un peu plus compliquée, car la commande d’extraction des fichiers
nécessite un changement de répertoire. Il faut donc utiliser une commande multiple du shell. Ces
commandes sont constituées de plusieurs autres commandes séparées par des points virgules. La
première commande effectuée ici est le changement de répertoire, et la deuxième est l’extraction par tar
de l’archive qui lui est transférée par le flux d’entrée standard (représenté ici par ’-’). Ces deux
commandes sont mises entre parenthèses, car l’opérateur ’|’ du tube est prioritaire sur l’opérateur ’;’ de
concaténation des commandes du shell. Si vous trouvez que cela est un peu compliqué, je vous l’accorde.
Cependant, la commande qui utilise le tube consomme deux fois moins d’espace disque et est deux fois
plus rapide que la commande qui n’en utilise pas. Je vous invite à mesurer le gain de temps sur un
répertoire contenant un grand nombre de données (utilisez la commande time !).

85
 Chapitre 5. Commandes Unix de base

Les tubes nommés

Les tubes créés par l’opérateur ’|’ constituent ce que l’on appelle des tubes anonymes, car ils sont créés
directement par le shell pour une commande donnée. Il est possible de créer manuellement des tubes en
leur donnant un nom, et de les utiliser a posteriori dans plusieurs commandes. Ces tubes constituent ce
que l’on appelle des tubes nommés.
En fait, les tubes nommés sont des fichiers spéciaux, que l’on crée dans un système de fichiers capable de
les gérer. Les seules opérations réalisables sont l’écriture et la lecture, sachant que les données écrites en
premier seront forcément les premières données lues. C’est ce comportement qui a donné leur nom à ces
fichiers, que l’on appelle des « FIFO » (abréviation de l’anglais « First In First Out »). De plus, la
quantité de données en transit dans ces fichiers est souvent très réduite, ce qui fait que ces données sont
toujours placées dans la mémoire cache du système. Ainsi, bien qu’il s’agisse de fichiers, aucune écriture
ou lecture sur disque n’a lieu lors de l’utilisation d’un pipe.
Les tubes nommés sont créés par la commande mkfifo, dont la syntaxe est la suivante :

mkfifo nom

où nom est le nom du tube nommé. Notez que cette commande échouera sur les systèmes de fichiers
incapables de gérer les tubes nommés.
Une fois créé, le fichier de tube peut être utilisé comme n’importe quel fichier dans les redirections que
l’on a vues dans la section précédente. Par exemple, la redirection suivante :

ls | less

peut être réécrite pour utiliser un tube nommé temporaire de la manière suivante :

mkfifo /tmp/tempfifo
ls > /tmp/tempfifo
less < /tmp/tempfifo

La destruction d’un tube nommé se fait comme n’importe quel fichier, à l’aide de la commande rm.

La commande tee
La commande tee est un petit programme permettant d’enregistrer les données qu’il reçoit dans son flux
d’entrée standard dans un fichier et de les renvoyer simultanément vers son flux de sortie standard. Elle
est couramment utilisée, en conjonction avec les tubes, pour dupliquer un flux de données. Sa syntaxe est
la suivante :

tee fichier

où fichier est le nom du fichier dans lequel le flux d’entrée standard doit être enregistré.
Supposons par exemple que l’on désire rediriger tous les messages (d’erreur ou non) de la commande ls
/proc/1/* dans un fichier [Link], tout en continuant à les visualiser sur l’écran. Pour cela, on
utilisera la commande suivante :

86
 Chapitre 5. Commandes Unix de base

ls -l /proc/1 2>&1 | tee [Link]

À l’issue de cette commande, le fichier [Link] contiendra une copie des données qui ont été
émises par la commande ls -l /proc/1 2>&1.

La commande xargs
La commande xargs permet d’appeler une autre commande, en passant en paramètre les données qu’elle
reçoit dans le flux d’entrée standard. Sa syntaxe est la suivante :

xargs commande

où commande est la commande que xargs doit exécuter. xargs construira une ligne de commande
complète pour cette commande, en utilisant comme paramètres les données issues du flux d’entrée
standard. Une fois cette ligne de commande construite, xargs l’exécutera. Par exemple, la commande
suivante :

ls -l

peut être exécutée également de la manière suivante :

xargs ls

et en tapant la chaîne de caractères « -l » suivie du caractère de fin de fichier CTRL+D.

La commande xargs est une commande extrêmement utile lorsqu’elle est utilisée conjointement avec les
tubes, parce qu’elle permet d’utiliser le résultat d’une commande en tant que paramètre pour une autre
commande. Ce mécanisme est donc complémentaire de celui des pipes, puisque ceux-ci permettaient
d’utiliser le résultat d’une commande pour alimenter le flux d’entrée standard d’une autre commande.
Un exemple plus utile que le précédent permettra de mieux comprendre comment on utilise la
commande xargs. Supposons que l’on désire trouver tous les fichiers d’une arborescence complète dont
l’extension est .txt et contenant la chaîne de caractères « test ». La liste des fichiers de l’arborescence
peut être déterminée simplement à l’aide de la commande find, et la recherche du texte dans les fichiers
se fait naturellement à l’aide de la commande grep. On utilisera xargs pour construire la ligne de
commande pour grep, à partir du résultat fourni par la commande find :

find -name "*.txt" | xargs grep -l "test"

Cette commande est plus simple et plus efficace que la commande équivalente :

find -name "*.txt" -exec grep -l "test" {} \;

parce que grep n’est exécuté qu’une seule fois (alors que l’option -exec de la commande find l’exécute
pour chaque fichier trouvé).

87
 Chapitre 5. Commandes Unix de base

Manipulation des variables d’environnement

Les systèmes Unix permettent de définir un environnement d’exécution pour chaque programme en
cours d’exécution. L’environnement est un ensemble de paramètres, que l’on appelle les variables
d’environnement, qui permettent de modifier le comportement du programme. Ces variables contiennent
une valeur de type chaîne de caractères, dont la signification est propre à chaque variable. Il est d’usage
que les noms des variables d’environnement soient écrits complètement en majuscules, mais ce n’est pas
une obligation.
Chaque programme est susceptible de reconnaître un certain nombre de variables d’environnement qui
lui sont propres, mais il existe également des variables standards que tous les programmes utilisent. C’est
notamment le cas de la variable d’environnement PATH, qui contient la liste des répertoires dans lesquels
le système doit rechercher les programmes à exécuter. Cette variable permet donc de lancer les
programmes en tapant simplement leur nom, et de laisser le système rechercher le fichier de ce
programme dans chacun des répertoires indiqués dans cette variable.
Par défaut, les programmes sont lancés avec l’environnement du programme qui les lance, c’est-à-dire
dans la plupart des cas l’environnement d’exécution du shell. Les programmes peuvent également définir
de nouvelles variables d’environnement, qui seront ainsi accessibles par les programmes qu’ils lanceront
eux-mêmes.
Comme tout programme, le shell dispose d’un environnement, qu’il utilise pour stocker ses propres
variables. En effet, comme nous l’avons déjà signalé plus haut, le shell est bien plus qu’un interpréteur
de commande : il est complètement programmable. Et en tant qu’interpréteur d’un langage de
programmation, il fournit la possibilité de définir des variables de ce langage. Les variables du shell sont
donc également des variables d’environnement, mais le shell ne les communique pas par défaut aux
programmes qu’il lance. Pour être plus précis, le shell utilise deux environnements différents :

• son propre environnement, qui contient les variables d’environnement locales à la session du shell en
cours ;
• l’environnement d’exécution, dont les variables d’environnement sont transmises aux programmes que
le shell lance.

Il est très facile de définir une variable du shell. Pour cela, il suffit de lui affecter une valeur, à l’aide de la
syntaxe suivante :

variable=valeur

où variable est le nom de la variable à définir, et valeur est la valeur que l’on désire lui affecter.
Notez qu’il n’est pas nécessaire de fournir une valeur. Dans ce cas, la variable ainsi définie sera vide.
Par exemple, la ligne suivante :

BONJOUR="Bonjour tout le monde \!"

permet de définir la variable BONJOUR. Notez que la valeur est encadrée entre guillemets, car elle
contient des espaces. Notez également que le caractère point d’exclamation (’!’) est précédé d’un
caractère d’échappement antislash (’\’), car il a une signification particulière pour le shell. Ce caractère
d’échappement permet simplement de signaler au shell qu’il ne doit pas interpréter le caractère qui le
suit, et fait donc en sorte que le point d’exclamation fasse partie de la chaînes de caractères à affecter à la

88
 Chapitre 5. Commandes Unix de base

variable. Bien entendu, le caractère antislash étant lui-même un caractère spécial pour le shell, il doit
lui-même être préfixé d’un autre antislash si l’on désire l’utiliser dans une chaîne de caractères.
La valeur d’une variable peut être récupérée simplement en préfixant le nom de la variable du symbole
dollar (’$’). Ainsi, la commande suivante permet d’afficher le contenu de la variable BONJOUR :

echo $BONJOUR

Les variables ainsi définies ne font partie que de l’environnement du shell, elles ne sont donc pas
accessibles aux programmes que le shell lance. Donc, si l’on relance un nouveau shell avec la commande
suivante :

bash

et que l’on essaie de lire le contenu de la variable BONJOUR avec la commande echo, on obtient une
chaîne vide. Cela est normal, puisque le deuxième shell (c’est-à-dire celui qui est en cours d’exécution)
n’utilise pas le même environnement que le premier shell. Vous pouvez quitter le nouveau shell avec la
commande suivante :

exit

Dès lors, vous serez à nouveau dans le shell initial, et la variable BONJOUR sera à nouveau accessible.
Pour rendre une variable du shell accessible aux programmes que celui-ci peut lancer, il faut l’exporter
dans l’environnement d’exécution. Cela peut être réalisé avec la commande export :

export variable

où variable est le nom de la variable du shell à exporter dans l’environnement d’exécution.

La syntaxe précédente exporte de manière permanente les variables du shell. Mais il existe également
une autre syntaxe, qui permet de ne définir des variables d’environnement que pour l’environnement
d’exécution d’une seule commande. Cette syntaxe consiste simplement à préfixer la commande à
exécuter par la définition de ladite variable. Par exemple, la commande suivante :

BONSOIR="Bonsoir tout le monde \!" bash

permet de lancer un shell et de lui communiquer la variable d’environnement BONSOIR. Cette variable
ne sera définie que pour ce programme, si l’on quitte ce shell avec un exit, la variable BONSOIR ne sera
plus définie.
Une variable peut être détruite à tout instant à l’aide de la commande unset. Cette commande prend en
paramètre le nom de la variable à supprimer. Par exemple, la commande suivante supprime notre
variable :

unset BONJOUR

89
 Chapitre 5. Commandes Unix de base

Vous pouvez à tout moment visualiser l’ensemble des variables définies avec la commande set. Le
tableau donné ci-dessous vous présentera les variables d’environnement les plus utilisées, que la plupart
des programmes utilisent pour permettre à l’utilisateur de modifier leur comportement :

Tableau 5-3. Variables d’environnements courantes

Nom Signification
HOME Chemin du répertoire personnel de l’utilisateur.
USER Nom de login de l’utilisateur. Cette information est également
disponible au travers de la variable d’environnement LOGNAME.
TERM Type de terminal utilisé. La valeur de cette variable sert aux
applications pour déterminer les caractérisques du terminal et ses
fonctionnalités afin d’optimiser leur affichage. La valeur de cette
variable est souvent linux sur les consoles Linux, et xterm dans les
émulateurs de terminal graphiques sous X11. Nous verrons l’utilité
de cette variable plus en détail dans la la section intitulée Description
des terminaux dans Chapitre 6.
SHELL Chemin sur le fichier de programme du shell actuellement utilisé.
Sous Linux, il s’agit souvent du shell bash.
PATH Liste des répertoires dans lesquels les programmes à exécuter seront
recherchés. Cette liste ne doit pas contenir le répertoire courant (.)
pour des raisons de sécurité de base (il suffit de placer un cheval de
troie portant le nom d’une commande classique dans un répertoire
pour que l’utilisateur le lance sans s’en rendre compte).
LD_LIBRARY_PATH Liste des répertoires dans lesquels les bibliothèques dynamiques
seront recherchées si elles ne sont pas trouvables dans les répertoires
classiques des bibliothèques de programme du système.
C_INCLUDE_PATH Liste des répertoires dans lesquels le compilateur C recherchera les
fichiers d’en-tête lors de la compilation des fichiers sources C. Cette
liste doit contenir les répertoires additionnels, qui ne sont pas déjà
pris en compte automatiquement par le compilateur C.
CPLUS_INCLUDE_PATH Liste des répertoires dans lesquels le compilateur C++ recherchera
les fichiers d’en-tête lors de la compilation des fichiers sources
C/C++. Cette liste doit contenir les répertoires additionnels, qui ne
sont pas déjà pris en compte automatiquement par le compilateur
C++.
LIBRARY_PATH Liste des répertoires dans lesquels les bibliothèques à utiliser lors de
l’édition de liens des programmes doivent être recherchées. Cette
variable n’est utilisée que par les outils de développement lors de la
compilation de fichiers sources et elle ne doit pas être confondue
avec la variable d’environnement LD_LIBRARY_PATH, qui indique
la liste des répertoires dans lequel l’éditeur de liens dynamiques
recherchera les bibliothèques dynamiques utilisées par les
programmes lors de leur chargement. Les notions de fichiers sources
et de compilation seront détaillées dans le Chapitre 7.

90
 Chapitre 5. Commandes Unix de base

Nom Signification
TMPDIR Répertoire des fichiers temporaires. Par défaut, le répertoire des
fichiers temporaires est le répertoire /tmp/, mais il est possible d’en
changer grâce à cette variable d’environnement.
TZ Définition de la zone horaire de l’utilisateur. Le système travaillant
exclusivement en temps universel, chaque utilisateur peut définir sa
propre zone horaire pour obtenir l’affichage des dates et des heures
dans son temps local. Le format de cette variable d’environnement
est assez complexe. Il est constitué de plusieurs champs séparés par
des espaces, représentant successivement le nom du fuseau horaire
(au moins trois caractères), le décalage à ajouter à l’heure universelle
pour obtenir l’heure locale, le nom du fuseau horaire pour l’heure
d’été, le décalage pour l’heure d’été, et les dates de début et de fin de
l’heure d’été. Les décalages horaires doivent être exprimés avec un
’+’ pour les fuseaux horaires placés à l’ouest de Greenwich, ’-’ pour
ceux situés à l’est. Les dates de début et de fin de la période d’heure
d’été peuvent être exprimés de deux manières différentes. La
première méthode est d’indiquer le numéro du jour dans l’année
après la lettre ’J’. Ce numéro ne doit pas tenir compte du 29 février,
même pour les années bissextiles. La deuxième méthode est
d’indiquer le mois de l’année, la semaine du mois et le jour de la
semaine, séparés par des ’.’, et après la lettre ’M’. Les mois sont
comptés de 1 à 12, les semaines de 1 à 5 et les jours de 0 à 6, 0 étant
le dimanche. Seul le premier champ est obligatoire, et il est possible
d’utiliser les noms de fuseaux horaires définis par la bibliothèque C.
En France, on utilise normalement le fuseau CES (temps d’Europe
centrale).
LANG Nom de la locale à utiliser par défaut pour les paramètres
d’internationalisation des applications. Cette valeur sera utilisée pour
les paramètres qui n’en définissent pas une explicitement. Elle doit
être composée de deux codes à deux caractères, le premier indiquant
la langue, et le deuxième le pays (car plusieurs pays peuvent parler la
même langue, et un pays peut avoir plusieurs langues nationales).
Pour la France, on utilise normalement la valeur « fr_FR ». Cette
valeur peut être redéfinie par l’une des variables d’environnement
décrites ci-dessous.
LC_MESSAGES Nom de la locale à utiliser pour déterminer la langue des messages.
La valeur par défaut est spécifiée par la variable d’environnement
LANG.
LC_TYPE Nom de la locale à utiliser pour déterminer les règles de classification
des caractères. La classification des caractères permet de dire si un
caractère est un chiffre ou non, s’il est en majuscule ou en minuscule,
etc. La valeur par défaut est spécifiée par la variable d’environnement
LANG.

91
 Chapitre 5. Commandes Unix de base

Nom Signification
LC_COLLATE Nom de la locale à utiliser pour déterminer les règles de comparaison
des caractères. La comparaison des caractères est utilisée pour les tris
lexicographiques (tri par ordre alphabétique par exemple). La valeur
par défaut est spécifiée par la variable d’environnement LANG.
LC_MONETARY Nom de la locale à utiliser pour déterminer l’emplacement et le
caractère représentant le symbole monétaire du pays. La valeur par
défaut est spécifiée par la variable d’environnement LANG.
LC_NUMERIC Nom de la locale à utiliser pour déterminer les conventions locales
d’écriture des nombres (séparateur décimal, format de la virgule,
etc.). La valeur par défaut est spécifiée par la variable
d’environnement LANG.

En résumé, le shell utilise les variables d’environnement du système pour gérer ses propres variables, et
permet de les exporter vers l’environnement d’exécution qu’il communique aux commandes qu’il lance.
Un grand nombre de variables d’environnement classiques sont reconnues par les programmes. Elles
servent à paramétrer leur comportement. Nous reverrons ultérieurement quelques-unes de ces variables
lors de la configuration du système de base.

Caractère d’échappement et chaînes de caractères

Un certain nombre de caractères sont interprétés par le shell d’une manière spéciale. Nous en avons déjà
vu quelques-uns pour les redirections et les tubes, mais il en existe d’autres. Par conséquent, il faut
utiliser une syntaxe particulière lorsqu’on désire utiliser un de ces caractères dans une commande du
shell sans qu’il soit interprété par le shell. Pour cela, il suffit de faire précéder ces caractères du caractère
d’échappement antislash (caractère de la barre oblique inverse, ’\’). Ce caractère permet d’indiquer au
shell que le caractère suivant doit être traité tel quel et ne doit pas être interprété avec son sens habituel.
Par exemple, pour créer un répertoire nommé <, on utilisera la commande suivante :

mkdir \<

Bien entendu, le caractère antislash peut lui-même être précédé d’un autre antislash, lorsqu’on veut
l’utiliser en tant que caractère normal.
Le caractère d’échappement antislash permet également, lorsqu’il est placé en fin de ligne, de supprimer
le saut de ligne qui le suit. Cela signifie qu’il permet de répartir une commande trop longue sur plusieurs
lignes, à des fins de lisibilité. Vous trouverez quelques exemples de cette notation plus loin dans ce
document, pour présenter des commandes trop longues pour tenir sur une page A4.
Il peut être relativement fastidieux de devoir taper des antislashs dans les chaînes de caractères qui
contiennent beaucoup de caractères interprétables par le shell. C’est pour cela que le shell permet de
définir des chaînes de caractères dont il ignore le contenu lors de l’analyse syntaxique. Ces chaînes de
caractères sont simplement données entre guillemets simples (caractère ’). Par exemple, la commande
suivante :

MESSAGE=’La syntaxe est A | B’

92
 Chapitre 5. Commandes Unix de base

permet d’affecter la chaîne de caractères La syntaxe est A | B, contenant des espaces et le

caractère | normalement utilisé par le shell pour les tubes, dans la variable d’environnement MESSAGE.

Note : Une chaîne de caractères commence par un guillemet et se termine par un guillemet. Les
chaînes de caractères ne peuvent donc pas contenir de guillemet, même précédé d’un caractère
d’échappement.
On veillera à ne surtout pas confondre les guillemets simples (caractère ’) avec les guillemets
inverses (caractère ‘). Ces deux caractères se ressemblent en effet énormément dans certaines
polices de caractères, mais ont néanmoins une signification très différente. Le premier sert à définir
des chaînes de caractères, et le deuxième à exécuter une commande et à en inclure le résultat dans
une autre commande. Nous verrons plus loin comment utiliser ce type de guillemets.

Les guillemets simples sont donc très pratiques pour écrire simplement une chaîne de caractères, mais ne
permettent pas de bénéficier des fonctionnalités de substitutions du shell, comme par exemple le
remplacement d’une variable par sa valeur dans la chaîne de caractères. De plus, elles ne peuvent pas
contenir de guillemets simples, puisque c’est leur caractère de terminaison. C’est pour ces raisons que le
shell donne la possibilité de définir des chaînes de caractères plus souples, à l’aide des guillemets
doubles (caractère "). Dans ces chaînes de caractères, la plupart des caractères normalement interprétés
par le shell ne le sont plus, comme pour les chaînes de caractères utilisant les guillemets simples.
Cependant, les caractères spéciaux $, ‘ et \ conservent leur signification initiale. Il est donc possible, par
exemple, d’utiliser des variables d’environnement dans les chaînes de caractères de ce type :

echo "Mon nom est $USER"

Le caractère d’échappement antislash peut toujours être utilisé, en particulier pour insérer un caractère de
guillemets doubles dans une chaîne de caractères. En effet, ce caractère marquerait la fin de la chaîne de
caractères s’il n’était pas précédé d’un antislash.

Note : Remarquez que les guillemets et les caractères d’échappement ne sont utilisés que pour
l’analyse de la ligne de commande. Une fois toutes les chaînes de caractères et toutes les
substitutions traitées, les guillemets et les caractères d’échappement inutiles sont supprimés. En
pratique, ce sont tous les caractères d’échappement et les guillemets qui restent après traitement de
la ligne de commande et qui ne font pas partie du résultat d’une des substitutions. Ainsi, la
commande suivante :

echo "Bonjour tout le monde"

a pour but de passer la chaîne de caractères Bonjour tout le monde en tant que premier (et
unique) paramètre de la commande echo, puis de l’exécuter. Les guillemets ne font pas partie de la
chaîne de caractères, ils ont été supprimés par le shell et seul le contenu de la chaîne sera
effectivement affiché.
Notez que la commande précédente est très différente de celle-ci :

echo Bonjour tout le monde

même si le résultat est le même. En effet, cette dernière commande passe les chaînes de caractères
Bonjour, tout, le et monde en tant que paramètres (4 au total) à la commande echo, alors que

93
 Chapitre 5. Commandes Unix de base

l’utilisation des guillemets permet de passer toute la phrase en un seul paramètre. On peut voir la
différence en utilisant plus d’un espace entre chaque mot : les espaces superflus ne sont conservés
que dans la première commande.

Les substitutions
L’une des fonctionnalités les plus puissantes du shell est sans doute sa capacité à effectuer des
substitutions d’expressions par leur valeur. L’une des substitutions les plus courantes est sans doute le
remplacement d’une variable par sa valeur, mais le shell peut faire beaucoup plus que cela. Les lignes de
commandes peuvent être écrites en utilisant différents types d’expressions spéciales, qui seront
remplacées par leur valeur par le shell avant l’exécution de la commande. Ces expressions permettent de
spécifier des motifs de chaîne de caractères, d’exprimer des chemins partiels sur des fichiers ou des
répertoires, de récupérer la valeur des variables du shell, et de calculer des expressions mathématiques,
voire d’inclure le résultat d’une autre commande dans la ligne de commande en cours.
Les mécanismes des substitutions décrits ci-dessous sont présentés par ordre de priorité décroissante.
Cela signifie que si une expression substituable contient elle-même une autre expression substituable de
priorité inférieure, cette expression sera remplacée après la substitution de l’expression contenante.

Génération de chaînes de caractères selon un motif

Il est possible de demander au shell de générer une série de chaînes de caractères selon un motif simple.
Ce motif est toujours constitué d’un préfixe, suivi d’une partie variable, suivie d’un suffixe. La partie
variable du motif est celle qui subira les substitutions pour générer une liste de chaînes de caractères
commençant par le préfixe suivi du résultat de la substitution et se terminant par le suffixe. Cette partie
variable doit être spécifié entre accolades, et prend la forme d’une liste de valeurs possibles pour chaque
substitution, séparées par des virgules. Par exemple, la commande suivante :

ls test{0,1,2,3,4}

sera transformée par le shell en la commande suivante :

ls test0 test1 test2 test3 test4

Note : Ceux qui se souviennent un peu de leurs mathématiques se diront qu’il s’agit là d’une
factorisation. C’est rigoureusement exact.

Substitution du nom d’utilisateur

Le caractère tilde (’~’) est remplacé par le nom de l’utilisateur courant ou, à défaut de nom, par le
chemin sur le répertoire personnel de cet utilisateur. Il est possible de spécifier un autre utilisateur en

94
 Chapitre 5. Commandes Unix de base

donnant le nom de login de cet autre utilisateur immédiatement après le caractère tilde. Par exemple, la
commande suivante :

cp *.txt ~jean

permet de copier tous les fichiers d’extension .txt dans le répertoire personnel de l’utilisateur jean.

Remplacements de variables
Comme il l’a déjà été indiqué plus haut, la valeur des variables du shell et des variables d’environnement
peut être récupérée en préfixant le nom de la variable par le caractère dollar (’$’). En fait, cette écriture
est l’une des formes les plus simples que peuvent prendre les substitutions de paramètres. En effet, il est
possible de remplacer l’expression par une partie seulement de la valeur de la variable, ou une par une
autre valeur calculée à partir de celle de la variable.
En pratique, les expressions utilisées par les substitutions de variables peuvent être relativement
compliquées, et il peut être nécessaire de les isoler du reste de la ligne de commande à l’aide
d’accolades. La syntaxe exacte complète de ce type de substitution est donc la suivante :

${expression}

où expression est l’expression qui définit la chaîne de remplacement à utiliser.

Si cette expression est un nom de variable, ce sera le contenu de cette variable qui sera utilisé pour la
substitution. Il est possible de fournir une valeur par défaut pour le cas où cette variable ne contient rien
ou n’est pas définie. Pour cela, on utilisera la syntaxe suivante :

${variable:-valeur}

où valeur est la valeur par défaut à utiliser dans ce cas. Notez que la variable reste indéfinie après la
substitution. Pour fixer la valeur de la variable à cette valeur par défaut en plus d’effectuer la substitution,
on utilisera plutôt la syntaxe suivante :

${variable:=valeur}

valeur a toujours la même signification dans cette syntaxe.

Il est parfois préférable d’afficher un message d’erreur plutôt que de donner une valeur par défaut
lorsqu’une variable n’est pas définie. Cela peut se faire avec la syntaxe suivante :

${variable:?message}

où message est le message à afficher dans le cas où la variable variable est non définie ou de valeur
nulle.
Si l’on veut tester si une variable est non définie et renvoyer une valeur spécifique si elle est définie, on
utilisera la syntaxe suivante :

${variable:+valeur}

où valeur est la valeur à renvoyer si la variable est définie. Si la variable n’est pas définie, la
substitution sera faite avec la chaîne de caractères vide (l’expression complète sera donc supprimée).

95
 Chapitre 5. Commandes Unix de base

Le shell permet également de faire la substitution avec une sous-chaîne de la valeur de la variable, à
partir d’une position donnée et d’une longueur. La syntaxe à utiliser est donnée ci-dessous :

${variable:position:longueur}

où position est la position à laquelle commence la sous-chaîne à extraire, et longueur est le nombre
de caractères à extraire. Ce dernier champ est facultatif (on ne mettra pas non plus les deux-points
précédents si on décide de ne pas spécifier de longueur). Si on ne le précise pas, la sous-chaîne extraite
sera constituée du reste de la valeur de la variable à partir de la position indiquée. La position quant à elle
doit être positive ou nulle. Une valeur négative indique un point de départ correspondant au nombre de
caractères correspondant à partir de la droite de la valeur de la variable. Si l’on veut obtenir la longueur
d’une chaîne de caractères contenue dans une variable, on utilisera cette syntaxe :

${#variable}

où variable est toujours le nom de la variable.

Il est également possible de considérer que la valeur d’une variable est une chaîne de caractère préfixée
d’une autre chaîne de caractères particulière. Le shell permet d’extraire la chaîne de caractères principale,
en supprimant ce préfixe. Pour réaliser cette opération, on utilisera l’une des syntaxes suivantes :

${variable#préfixe}

ou :

${variable##préfixe}

où variable est la variable contenant la chaîne de caractères à traiter, et préfixe est le préfixe à
supprimer.
En fait, le préfixe peut être spécifié à l’aide d’un motif de caractères. Ce motif peut correspondre à une
partie plus ou moins grande de la valeur de la variable. Dans ce cas, il y a plusieurs manières
d’interpréter ce motif, et donc plusieurs choix de préfixes possibles à supprimer. La première syntaxe
devra être utilisée lorsqu’on désire supprimer le plus petit préfixe possible correspondant au motif. La
deuxième syntaxe, quant à elle, permettra de supprimer le préfixe le plus long. Par exemple, si la variable
VAR contient la chaîne de caractères abbbc, la commande suivante :

echo ${VAR#a*b}

affichera la chaîne de caractères bbc, car le plus petit préfixe correspondant au motif a*b est ab.
Inversement, la commande :

echo ${VAR##a*b}

utilisera le préfixe le plus long, à savoir abbb. Le résultat de cette substitution sera donc la chaîne de
caractères c. La syntaxe des motifs de caractères utilisés ici sera précisée dans la la section intitulée Les
expressions rationnelles.
Le shell fournit une syntaxe similaire pour extraire des suffixes de la valeur des variables. Cette syntaxe
utilise simplement le caractère % au lieu du caractère #. Comme pour les préfixes, le fait de doubler ce
caractère implique que le suffixe le plus long correspondant au motif sera utilisé, alors que l’utilisation
d’un seul % permet de choisir le suffixe le plus court. Ainsi, la commande :

96
 Chapitre 5. Commandes Unix de base

echo ${VAR%b*c}

affichera la chaîne de caractères abb, alors que la commande :

echo ${VAR%%b*c}

n’affichera que a.
Pour terminer ce tour d’horizon des remplacements de variables, nous allons voir les possibilités de
recherche et de remplacement du shell dans les chaînes de caractères contenues dans des variables. La
syntaxe suivante :

${variable/motif/remplacement}

permet de rechercher la plus grande sous-chaîne de caractères correspondant au motif motif dans la
chaîne contenue dans la variable variable, et de remplacer cette sous-chaîne par la chaîne de caractères
remplacement. Par exemple, si la variable VAR contient la chaîne de caractères abab, la commande
suivante :

echo ${VAR/b/d}

affichera la chaîne de caractères adab.

Ce remplacement n’est donc effectué qu’une seule fois. Si l’on veut que toutes les occurrences du motif
soient remplacées par la chaîne de remplacement, il suffit de doubler le premier / :

${variable//motif/remplacement}

Dans les deux syntaxes, la présence du champ remplacement est facultative. Cela permet de supprimer
purement et simplement les sous-chaînes de caractères qui correspondent au motif.
La syntaxe des motifs sera détaillée dans la la section intitulée Les expressions rationnelles. Cependant,
une précision doit être signalée : si le motif commence par le caractère #, il sera obligatoirement
recherché au début de la chaîne de caractères contenue dans la variable. De même, si le motif commence
par le caractère %, il sera obligatoirement recherché à la fin de cette chaîne. Ces deux notations
permettent d’obtenir le même effet que les suppressions de préfixes et de suffixes présentées plus haut.

Substitution du résultat d’une commande

Le shell peut évaluer une commande apparaissant dans une expression afin de la remplacer par son
résultat. Il existe deux syntaxes pour réaliser ce type de substitutions. La première, et la plus classique
(voire historique), utilise des guillemets inverses :

‘commande‘

où commande est la commande devant être remplacée par son résultat (c’est-à-dire ce qu’elle enverra ce
résultat sur le flux standard de sortie). Pour donner un exemple, la commande suivante :

kill ‘cat /var/pid/[Link]‘

97
 Chapitre 5. Commandes Unix de base

a pour résultat de lancer un signal SIGTERM au processus dont le PID est stocké dans le fichier
/var/pid/[Link]. La commande cat est utilisée pour afficher le contenu de ce fichier, et elle est
substituée par ce contenu. En fin de compte, la commande kill est appliqué au PID affiché par cat.
La deuxième syntaxe utilisable est la suivante :

$(commande)

où commande est toujours la commande à exécuter et à substituer. La différence entre ces deux syntaxes
est que, dans le premier cas, les caractères $, ‘ et \ sont toujours interprétés par le shell et doivent être
précédés d’un antislash s’ils doivent apparaître tels quels dans la commande à substituer, alors que, dans
le deuxième cas, on peut utiliser tous les caractères sans protection particulière (sauf, bien entendu, la
parenthèse fermante, puisqu’elle marque la fin de la commande).

Évaluation d’expressions arithmétiques

En général, le shell ne manipule que des chaînes de caractères. Cependant, il est capable d’évaluer des
expressions mathématiques simples faisant intervenir des entiers. Pour cela, il faut utiliser la syntaxe
suivante :

$((expression))

où expression est l’expression à évaluer.

Les expressions mathématiques peuvent contenir tous les opérateurs classiques du langage C : addition,
soustraction, multiplication et division. Il existe en plus un opérateur d’élévation à la puissance,
représenté par une double étoile (**). Les opérateurs de décalage binaires vers la gauche (<<) et la
droite (>>) sont également utilisables, ainsi que les opérateurs de manipulation de bits & (« ET
binaire »), | (« OU binaire »), ^ (« OU binaire exclusif ») et ~ (« négation binaire »).
Comme en C, les comparaisons logiques peuvent également être évaluées, elles ont la valeur 1 lorsque
l’expression qui les utilise est vraie, et 0 dans le cas contraire. Les opérateurs disponibles sont ==, <, <=,
>, >= et !=. Les tests peuvent être composés à l’aide des opérateurs && (« ET logique ») et || (« OU
logique »).
Les divers opérateurs d’affectation du langage C +=, -=, etc. sont également disponibles.

Substitution de commandes
Nous avons déjà vu qu’il était possible de récupérer le résultat d’une commande pour l’insérer dans une
ligne de commande. Cette technique s’apparente à ce qu’il est possible de faire avec la commande xargs
et un pipe. De la même manière, le shell fournit une substitution permettant d’obtenir des fonctionnalités
similaires à celles fournies par les pipes nommés. Cette substitution est la substitution de commande.
La syntaxe utilisée par les substitutions de commandes est similaire à celle des redirections classiques :

<(command)

ou :

>(command)

98
 Chapitre 5. Commandes Unix de base

où command est la commande à substituer.

La première syntaxe permet de lancer une commande en arrière-plan en redirigeant son flux standard de
sortie vers un descripteurs de fichiers du shell. Le résultat de cette substitution est le nom du fichier
/dev/fd/n permettant de lire les données écrites par la commande dans ce descripteur de fichier. En
pratique, on utilise donc cette substitution en lieu et place d’un fichier d’entrée pour une commande
normale. La deuxième commande permet de lancer également une commande en arrière-plan, mais en
redirigeant le flux d’entrée standard de cette commande cette fois. Il est alors possible de fournir les
données nécessaires à cette commande en écrivant dans le fichier /dev/fd/n dont le nom est fourni par
le résultat de la substitution.
Ces deux commandes permettent donc de simplifier l’usage des pipes nommés, en évitant d’avoir à créer
un fichier de tube nommé manuellement et d’avoir à lancer les deux commandes devant se servir de ce
tube pour communiquer. Ainsi, la commande suivante :

cat <(ls)

est fonctionnellement équivalente à la série de commandes suivante :

mkfifo /tmp/lsfifo
ls > /tmp/lsfifo
cat /tmp/lsfifo
rm /tmp/lsfifo

Les substitutions de commandes sont donc nettement plus pratiques et plus sûres, car elles n’imposent
pas la création d’un fichier de pipe nommé dont le nom peut être choisi arbitrairement.

Découpage en mots
Les résultats provenant des substitutions vues précédemment sont systématiquement décomposés en
série de mots par le shell avant de poursuivre le traitement de la ligne de commande. Cela signifie que les
résultats de substitutions sont analysés pour identifier les mots qu’ils contiennent, en se basant sur la
notion de séparateur. Par défaut, les séparateurs utilisés sont l’espace, le caractère de tabulation et le
retour de ligne, mais il est possible de spécifier des séparateurs différents à l’aide de la variable
d’environnement IFS (abréviation de l’anglais « Internal Field Separator »).
Par exemple, le résultat de la commande ls dans la commande suivante :

echo ‘ls‘

est une chaîne de caractères contenant la liste des fichiers du répertoire courant, chacun étant séparé du
suivant par un caractère de saut de ligne. La substitution du résultat de cette commande est donc soumise
au découpage en mots, et chaque caractère de retour à la ligne est interprété comme un séparateur. Par
conséquent, cette chaîne de caractères est transformée en une liste de mots, chacun de ces mots étant un
des noms de fichiers renvoyés par la commande ls. Au final, la commande echo est appelée, avec comme
paramètres ces noms de fichiers, à raison d’un par paramètre. Les noms de fichiers sont donc affichés sur
une seule ligne.

99
 Chapitre 5. Commandes Unix de base

Note : Ce découpage en mot est effectué automatiquement par le shell à la suite des substitutions
vues précédemment. Cela signifie en particulier que s’il n’y a pas de substitution, il n’y a pas de
découpage en mots non plus.

Remplacement des caractères génériques

Si, après avoir appliqué toutes les formes de substitutions précédentes, le shell trouve des caractères
génériques * et ? dans l’expression en cours de traitement, il interprétera la partie de l’expression
contenant ces caractères comme un motif représentant des chemins de fichier Unix. Les caractères * et ?
auront donc le comportement que l’on a déjà décrit dans la la section intitulée Notions sur les chemins
Unix. Ce motif sera donc remplacé par autant de chemins Unix lui correspondant que possible.
Rappelons que le caractère générique * représente 0 ou plusieurs caractères quelconques, et que le
caractère générique ? représente un caractère et un seul. Les chemins générés sont classés par ordre
alphabétique.
Il est possible également de restreindre le jeu de caractères utilisé par le shell pour rechercher les noms de
fichiers correspondants au motif. Pour cela, il faut lui indiquer un ensemble de caractères ou de plages de
caractères utilisables, séparés par des virgules, et entre crochets. Les plages de caractères sont spécifiées
en indiquant le premier et le dernier caractère, séparés par un tiret. Par exemple, la commande suivante :

ls [a-c,m-t]*.txt

permet d’afficher tous les fichiers dont le nom commence par les lettres a, b, c et les lettres allant de m à
t, et dont l’extension est .txt. Vous trouverez de plus amples renseignements sur la syntaxe de ces
motifs dans la la section intitulée Les expressions rationnelles.
Sauf paramétrage pour indiquer explicitement de faire le contraire, le shell ignore systématiquement les
répertoires . et .. dans les substitutions. Cela est très important. En effet, une commande utilisant le
caractère générique * ne s’appliquera pas, par défaut, sur le répertoire courant et le répertoire parent.
Paramétrer bash pour qu’il prenne en compte ces répertoires peut être extrêmement dangereux, surtout
avec une commande telle que rm -f *, qui dans ce cas effacerait également les répertoires parents en
plus du contenu du répertoire courant !

Les expressions rationnelles

Les substitutions de variables et de noms de fichiers utilisent des motifs pour identifier des chaînes de
caractères. Ces motifs peuvent être reconnus dans plusieurs chaînes de caractères différentes, car ils
contiennent une ou plusieurs parties variables qui pourront représenter chacune une sous-chaîne des
chaînes qui vérifient ce motif. Par exemple, le motif a*b représente toute chaîne de caractères
commençant par un a et se terminant par un b. La sous-chaîne située entre ces deux caractères peut être
quelconque, et constitue la partie variable du motif.
La syntaxe utilisée pour définir les motifs de chaînes de caractères dans le shell bash est un
sous-ensemble d’un langage plus complexe permettant de décrire ce que l’on appelle les expressions
rationnelles (l’usage dit également « expressions régulières »). Le langage des expressions rationnelles
est relativement compliqué, mais extrêmement puissant. Ce langage permet d’identifier avec précision

100
 Chapitre 5. Commandes Unix de base

des sous-chaînes de caractères dans un chaîne de caractères à l’aide des parties variables des expressions
rationnelles, et permet éventuellement de remplacer ces sous-chaînes par des chaînes de substitutions.
Malheureusement, la description des expressions rationnelles pourrait prendre plusieurs pages, aussi ne
verrons-nous ici que expressions utilisables dans les substitutions du shell bash.
Comme vous l’avez sans doute déjà deviné au travers des exemples précédents, le caractère ’*’ permet
d’identifier une quelconque chaîne de caractères, y compris la chaîne vide. Utilisé dans les expressions
rationnelles, il constitue la partie variable principale de ces expressions. De la même manière, le
caractère ’?’ représente un et un seul caractère quelconque. Ce caractère sera donc utilisé quand on
désirera contrôler la taille de la partie variable d’une expression rationnelle, éventuellement en le
répétant un certain nombre de fois.
Les deux caractères de substitutions précédents peuvent contenir n’importe quel caractère, ce qui peut
parfois ne pas être assez restrictif dans la définition d’un motif. Le shell fournit donc une syntaxe plus
évoluée, permettant de définir précisément le jeu de caractère auquel un caractère du motif doit
appartenir. Cette syntaxe consiste simplement à donner la liste des caractères du jeu de caractères entre
crochets :

[...]

Les points de suspension représentent ici l’ensemble des caractères qui peuvent apparaître dans le motif
ainsi défini. Notez que dans le cas d’une suite de caractères, il suffit de spécifier le premier et le dernier
caractère, et de les séparer par un trait d’union (caractère ’-’). Ainsi, le motif suivant :

[a-egt]

représente n’importe lequel des caractères de ’a’ à ’e’, plus les caractères ’g’ et ’t’.

Note : Pour spécifier le caractère - lui-même, il suffit de le placer tout seul au début ou à la fin de la
liste de caractères spécifiée entre les crochets. De même, pour spécifier le caractère ’]’ lui-même
(normalement utilisé pour marquer la fin du jeu de caractères), il faut le placer au début de la liste,
juste après le crochet ouvrant.

Pour finir, sachez que le shell bash est également capable de prendre en charge des expressions
rationnelles plus complexes que celles présentées ici. Cependant, ces expressions ne sont pas actives par
défaut, et ne sont donc accessibles qu’en activant une option complémentaire du shell. Ces extensions ne
seront pas décrites ici, mais vous pouvez consulter la page de manuel de bash si vous désirez en savoir
plus à ce sujet.

Structures de contrôle
Tout langage de programmation digne de ce nom dispose de structures de contrôles évoluées permettant
de contrôler l’exécution du programme, de réaliser des boucles et de structurer l’ensemble d’un
programme. Le shell n’échappe pas à la règle, et fournit la plupart des constructions classiques. Cette
section a pour but d’exposer leurs syntaxes.

101
 Chapitre 5. Commandes Unix de base

Les instructions composées

Dans le langage du shell, une instruction se termine soit par un retour à la ligne (non précédé d’un
antislash), soit par un point-virgule. Les instructions peuvent être pourtant très complexes, car elles
peuvent contenir des tubes et des redirections. En fait, une instruction peut à peu près être définie comme
étant une ligne de commande normale du shell.
Le shell permet bien entendu de réaliser des instructions composées, afin de regrouper plusieurs
traitements dans un même bloc d’instructions. La méthode la plus simple pour réaliser un bloc
d’instructions est tout simplement de les regrouper sur plusieurs lignes, ou de les séparer par des
points-virgules, entre accolades. Par exemple, les instructions suivantes constituent un bloc
d’instructions :

{
cd /tmp
rm *.bak
}

Notez que l’accolade fermante est considérée comme une instruction à part entière. Cela signifie que si
l’on ne met pas l’accolade fermante sur une ligne indépendante, il faut faire précéder l’instruction
précédente d’un point-virgule. De même, il faut le faire suivre d’un autre point-virgule s’il ne se trouve
pas à la fin d’une ligne.
Les instructions des instructions composées créées à l’aide des accolades sont exécutées au sein du shell
courant. Les variables qu’elles définissent, ainsi que les changements de répertoires, sont donc toujours
valides à l’issue de l’exécution de ces instructions. Si cela n’est pas désirable, on pourra créer des
instructions composées à l’aide de parenthèses. Les instructions seront alors exécutées dans un autre
shell, lancé pour l’occasion, et elles n’auront donc pas d’effet de bord imprévu dans le shell appelant. Par
exemple, le répertoire courant à l’issue de l’instruction composée précédente est le répertoire /tmp/,
alors que l’instruction composée suivante :

(
cd /tmp
rm *.bak
)

ne change pas le répertoire courant.

Note : On ne confondra pas les instructions composées utilisant des parenthèses et les substitutions
de résultat de commande. Les instructions composées renvoient le code d’erreur de la dernière
instruction exécutée, alors que le résultat des substitutions est ce que la commande a écrit sur son
flux de sortie standard.

Le shell permet également de réaliser des instructions composées conditionnelles, où l’exécution de

chaque instruction de l’instruction composée est conditionnée par le résultat de l’instruction précédente.
Ces instructions composées sont définies à l’aide des opérateurs || et &&. La syntaxe de ces opérateurs
est la même :

command1 || command2
command1 && command2

102
 Chapitre 5. Commandes Unix de base

où command1 et command2 sont deux commandes du shell (composées ou non). Avec l’opérateur ||, la
commande command2 n’est exécutée que si le code de retour de la commande command1 est non nul,
ou, autrement dit, si cette commande ne s’est pas exécutée correctement. Inversement, avec l’opérateur
&&, la commande command2 n’est exécutée que si la première commande s’est exécutée correctement (et
renvoie donc un code de retour nul). Par exemple, la commande suivante :

rm *.txt 2> /dev/null || echo "Aucun fichier à supprimer"

permet d’effacer tous les fichiers d’extension .txt, ou d’afficher le message d’erreur « Aucun fichier
à supprimer » s’il n’existe pas de fichier ayant une telle extension.

Les instructions composées peuvent être utilisées comme n’importe quelle commande normale. En
particulier, elles peuvent être utilisées dans des commandes plus complexes, par exemple comme
destination d’un tube. C’est ce que faisait l’exemple de déplacement de toute une arborescence dans la la
section intitulée Syntaxe des tubes.

Les tests
Sous Unix, chaque processus reçoit plusieurs valeurs en paramètres et renvoie un code de retour. La
plupart des paramètres sont passés en ligne de commande, et sont récupérés directement par le processus,
mais d’autres paramètres peuvent être fournis par le processus appelant par l’intermédiaire de variables
d’environnement et de descripteurs de fichiers. Le code de retour, quant à lui, est un entier signalant si
l’exécution du processus s’est terminée correctement ou si des erreurs ont eu lieu. Si les codes d’erreurs
varient grandement d’un programme à un autre, la valeur 0 signifie toujours, et ce quel que soit le
programme, que l’exécution s’est déroulée correctement.
Il est possible de tester le code de retour d’une commande avec l’instruction if. La syntaxe la plus
simple pour un test est la suivante :

if commande ; then
action
fi

où commande est la commande dont on désire tester le code de retour, et action est la commande à
exécuter si ce code vaut 0 (c’est-à-dire, si la commande commande s’est exécutée correctement).
Il peut paraître réducteur de ne pouvoir tester que le code de retour d’une commande. Mais en fait, c’est
une fonctionnalité très puissante du shell, car elle permet de réaliser tous les types de tests imaginables.
En effet, il existe une commande spéciale, [, qui permet de réaliser divers types de tests sur les
paramètres qu’on lui passe, et d’ajuster son code d’erreur en conséquence. Par exemple, pour tester
l’égalité d’une variable d’environnement avec une chaîne de caractères, on utilisera la syntaxe suivante :

if [ $variable == valeur ] ; then

action
fi

Notez que dans cette syntaxe, le test effectué est une commande complète. Cela implique qu’il faut
mettre une espace entre chaque paramètre, et en particulier entre le nom de la commande ([), le premier
opérande ($variable), l’opérateur utilisé (==), le deuxième opérande (valeur) et le caractère de
marque de fin de test (]).

103
 Chapitre 5. Commandes Unix de base

La commande [ est capable d’effectuer tous les tests standards. Par défaut, elle considère que les deux
opérandes du test sont des chaînes de caractères, et elle utilise l’ordre lexicographique pour les comparer.
Les tests d’égalité et d’inégalité sont effectués respectivement avec les opérateurs == et !=. Les
opérateurs d’antériorité dans l’ordre lexicographique sont < et <=, et les opérateurs de postériorité sont
> et >=. Notez que l’utilisation de ces opérateurs peut être relativement pénible, parce que les caractères
< et > sont interprétés par le shell en tant que redirections. Par conséquent, il faut souvent les précéder
du caractère d’échappement antislash.
L’ordre lexicographique convient dans la plupart des cas, mais il n’est pas très approprié pour la
comparaison de valeurs numériques. Par exemple, le test suivant :

if [ -1 \< -2 ] ; then
echo "-1 est plus petit que -2"
fi

est vérifié, car le caractère 1 précède le caractère 2 dans l’ordre lexicographique. La commande [ fournit
donc la possibilité d’utiliser une autre syntaxe pour comparer les entiers. Cette syntaxe utilise les options
lt et gt respectivement pour les tests d’infériorité stricte et de supériorité stricte, et les options le et ge
respectivement pour les tests d’infériorité et de supériorité ou d’égalité. Ainsi, le test :

if [ $i -gt 3 ] ; then
echo "$i est supérieur à 3"
fi

permet de comparer la valeur entière de la variable i avec le nombre 3.

Nous avons vu dans la la section intitulée Les instructions composées que les opérateurs || et &&
permettent de tester le code de retour d’une commande, et qu’en fonction de la valeur de ce code de
retour, d’exécuter ou non la commande suivante. La syntaxe de ces opérateurs provient en fait de la
possibilité de les employer pour effectuer des tests complexes avec l’instruction if. Par exemple, pour
effectuer un ET logique entre deux tests, on utilisera la syntaxe suivante :

if [ $i == "A" ] && [ $j -lt 3 ] ; then

echo "i contient la lettre \"A\" et j contient un nombre inférieur à 3"
fi

Notez que la deuxième commande [ n’est exécutée que si le premier test est vérifié. L’utilisation de
l’opérateur || se fait selon le même principe. Il est bien entendu possible de regrouper plusieurs
commandes de test ensemble, à l’aide de parenthèses.
Comme dans la plupart des langages informatiques, l’instruction if peut prendre une forme plus
complexe pour traiter les cas où le test n’est pas vérifié. Ainsi, pour exécuter une action spécifique pour
le cas où le test serait faux, on peut utiliser la syntaxe suivante :

if commande ; then
action1
else
action2
fi

104
 Chapitre 5. Commandes Unix de base

où commande est toujours la commande dont le code de retour sera testé, action1 est l’action qui doit
être réalisée si cette commande a renvoyé le code de retour 0, et action2 la commande à exécuter dans
le cas contraire. De même, si l’on veut enchaîner des tests, on utilisera le mot clé elif. La syntaxe
générale du test est donc la suivante :

if commande1 ; then
action1
elif commande2 ; then
action2
elif commande3 ; then
...
else
actionn
fi

Note : Pour des raisons d’optimisation, le shell peut simuler le comportement du programme [, et
éviter ainsi de le lancer à chaque fois qu’il a à faire un test. Cependant, le principe originel était bien
celui décrit ci-dessus. Cette description, bien que n’étant plus tout à fait exact, permet de mieux
comprendre la syntaxe du shell.
Il est possible de récupérer la valeur du code de retour de la dernière commande exécutée grâce à
la variable spéciale $?. Cependant, il est très rare d’avoir à manipuler cette valeur directement, car
les structures de contrôle du shell telles que if permettent d’effectuer les actions qui s’imposent
sans avoir à la connaître.
Pour ceux qui savent programmer en C, sachez que le code de retour est la valeur renvoyée par la
fonction C exit ou par l’instruction return de la fonction principale main. Les paramètres de la ligne
de commande, quant à eux, sont récupérables par l’intermédiaire des paramètres de la fonction
principale main.

Il ne faut pas oublier que la fonction première du shell est de permettre les manipulations de fichiers. Il
n’est donc pas étonnant que la commande [ permette également de réaliser tous les tests imaginables sur
les fichiers. Ces tests vont de l’existence d’un fichier au test de sa nature et de ses attributs, en passant par
les tests sur l’identité de son propriétaire et de son groupe. La syntaxe générale de ces tests est la
suivante :

if [ option fichier ] ; then

.
.
.
fi

où option est une option de la commande [ décrivant la propriété testée, et fichier est le nom du
fichier sur lequel le test doit porter.
Les principales options utilisables dans les tests sur les fichiers sont récapitulées dans le tableau
ci-dessous :

Tableau 5-4. Tests sur les fichiers

105
 Chapitre 5. Commandes Unix de base

Option Signification
-e Test d’existence d’un fichier ou d’un répertoire.
-d Test d’existence d’un répertoire.
-f Test d’existence d’un fichier normal.
-s Test d’existence d’un fichier et vérification que sa taille est non nulle.
-L Test d’existence d’un lien symbolique.
-b Test d’existence d’un fichier spécial de périphérique de type bloc (disque dur,
CD-ROM, lecteur de cassettes, etc.).
-c Test d’existence d’un fichier spécial de périphérique de type caractère (port série,
port parallèle, carte son...).
-p Test d’existence d’un tube.
-r Test d’existence du fichier et d’accessibilité en lecture de ce fichier.
-w Test d’existence du fichier et d’accessibilité en écriture de ce fichier
-x Test d’existence du fichier et de possibilité d’exécution de ce fichier.
-g Test d’existence du fichier et de présence du bit setgid sur ce fichier.
-u Test d’existence du fichier et de présence du bit setuid sur ce fichier
-k Test d’existence du fichier et de présence du bit sticky sur ce fichier.
-O Test d’existence du fichier et d’appartenance de ce fichier à l’utilisateur effectif
courant.
-G Test d’existence du fichier et d’appartenance de ce fichier au groupe effectif
courant.
-N Test d’existence du fichier et de modification de ce fichier depuis la dernière fois
qu’il a été lu.

Note : Ce tableau n’est pas exhaustif, mais les options les plus importantes et les plus utilisées s’y
trouvent.
Vous pourrez vous rafraîchir la mémoire sur les notions de bit setuid, setgid et sticky, ainsi que sur
les notions d’utilisateur et de groupe effectifs en relisant la la section intitulée Sécurité et utilisateurs
dans Chapitre 3.

La commande [ accepte également les options -nt et -ot, qui permettent respectivement de tester si un
fichier est plus récent ou plus vieux qu’un autre, en se basant sur les dates de dernière modification de
ces fichiers. Ces deux opérateurs s’utilisent avec la syntaxe suivante :

if [ fichier1 option fichier2 ] ; then

.
.
.
fi

où fichier1 et fichier2 sont les deux fichiers sur lesquels la comparaison doit porter, et option est
l’une des options -nt ou -ot.

106
 Chapitre 5. Commandes Unix de base

Le branchement conditionnel
Lorsqu’on veut effectuer différentes opérations selon la valeur d’une variable, l’instruction if peut
devenir très lourde à utiliser. En effet, si le nombre de valeurs différentes est grand, elle peut conduire à
écrire un grand nombre de tests. Le shell fournit donc une instruction de branchement conditionnel, qui
permet de spécifier quelle action doit être prise pour chaque valeur de la variable.
Le branchement conditionnel s’utilise de la manière suivante :

case valeur in
( motif1 | motif2 | ... ) commande1 ;;
( motifn | motifn+1 | ... ) commande2 ;;
.
.
.
esac

où motif1, motif2... motifn+1 sont des motifs spécifiant les valeurs possibles pour la valeur valeur,
et commande1, commande2, etc. sont les commandes à exécuter pour les valeurs de ces motifs.
La commande exécutée est la première commande pour laquelle la variable correspond à l’un de ses
motifs correspondants. Une fois exécutée, la recherche se termine, et l’exécution reprend à la suite du
branchement conditionnel. Par exemple ce branchement conditionnel :

case $i in
( *.txt ) echo "$i est un fichier texte" ;;
( *.gz ) echo "$i est compressé avec gzip" ;;
( *.tar ) echo "$i est une archive" ;;
esac

affiche la nature du fichier dont le nom est stocké dans la variable i à partir de son extension.
Le code de retour du branchement conditionnel est 0 si la variable ne correspond à aucun des motifs, ou
le code de retour de la commande exécutée sinon.

Les boucles
Il existe deux types de boucles : le while et le until. La syntaxe des boucles while est la suivante :

while commande ; do
action
done

où commande est une commande dont le code de retour est utilisé comme critère de la fin de la boucle, et
action est l’instruction (composée ou non) exécutée à chaque itération de la boucle. Comme on le voit,
le shell utilise le même principe pour les boucles que pour les tests pour évaluer une condition. Tant que
la commande commande renvoie un code de retour égal à 0, l’instruction action est exécutée.
L’instruction until utilise la même syntaxe que l’instruction while :

until commande ; do
action
done

107
 Chapitre 5. Commandes Unix de base

à ceci près que l’instruction action est exécutée tant que la commande commande renvoie un code de
retour non nul. L’instruction until utilise donc simplement le test inverse de celui de l’instruction
while.

Bien entendu, il est possible d’utiliser la commande [ pour effectuer des tests plus complexes que le
simple test du code de retour d’une commande. Par exemple, la boucle suivante calcule la somme des dix
premiers entiers :

result=0
i=0
while [ $i -le 10 ] ; do
result=$(($result + $i))
i=$(($i + 1))
done
echo $result

Les itérations
Les itérations sont des boucles qui s’exécutent pour chaque élément d’un ensemble donné. Le shell gère
les itérations par l’intermédiaire de l’instruction for. La syntaxe de cette instruction est la suivante :

for variable [ in ensemble ] ; do

action
done

où variable est un nom de la variable utilisée pour l’itération, ensemble est l’ensemble des valeurs
que peut prendre cette variable, et action est la commande (simple ou composée) à exécuter pour
chaque valeur de cette variable.
Le principe des itérations est très simple. Pour chaque valeur indiquée dans l’ensemble des valeurs, la
commande est exécutée, avec la valeur en question accessible dans la variable utilisée pour l’itération.
Par exemple, la commande suivante :

for i in *.txt ; do
mv $i ${i/%.txt/.doc}
done

permet de renommer tous les fichiers portant l’extension .txt en fichier du même nom, mais avec
l’extension .doc.
Il n’est pas nécessaire de préciser l’ensemble des valeurs que peut prendre la variable. Dans ce cas,
l’ensemble utilisé sera celui de tous les paramètres du script ou de la fonction. Nous verrons plus loin
comment réaliser des fonctions et des scripts, ainsi que la manière de récupérer leurs paramètres.

Les ruptures de séquence

Il est parfois nécessaire de modifier l’ordre d’exécution dans les boucles et les itérations du shell. Par
exemple, il est souvent nécessaire de sortir de la boucle courante, soit parce qu’on ne peut plus la

108
 Chapitre 5. Commandes Unix de base

continuer dans de bonnes conditions, soit parce que le traitement est terminé. C’est notamment le cas
lorsqu’une erreur se produit, ou lorsqu’on recherche une valeur spécifique en itérant sur les valeurs
possibles d’un ensemble.
Le shell fournit donc les instructions break et continue, qui permettent respectivement de sortir de la
boucle courante et de passer directement à l’itération suivante. Ces deux commandes peuvent être
utilisées aussi bien à l’intérieur des boucles while et until que dans les itérations écrites avec
l’instruction for. Par exemple, le calcul de la somme des dix premiers entiers aurait pu être écrit de la
manière suivante :

result=0
i=0
while true ; do
result=$(($result + $i))
i=$(($i + 1))
if [ $i ==11 ] ; then break ; fi
done
echo $result

Les instructions break et continue peuvent prendre un paramètre entier indiquant le niveau
d’imbrication de la boucle sur laquelle elles s’appliquent. Ce paramètre doit impérativement être
supérieur à sa valeur par défaut, c’est-à-dire 1. Ainsi, pour sortir directement d’une double boucle
lorsqu’on est dans le corps de la boucle la plus imbriquée, on utilisera la commande suivante :

break 2

Les fonctions
Le langage du shell est un langage procédural. Cela signifie que l’on peut créer des fonctions pour
regrouper des séries d’instructions couramment exécutées. La syntaxe permettant d’écrire de telles
fonctions est la suivante :

function nom () {
instructions
}

où nom est le nom de la fonction, et instructions est la liste des commandes à exécuter dans cette
fonction.
Vous constaterez qu’il n’y a pas de déclaration des paramètres de cette fonction. C’est normal : les
paramètres des fonctions sont passés implicitement dans les variables d’environnement $1, $2, $3, etc.
En fait, comme nous le verrons plus loin, cette syntaxe est également celle utilisée pour récupérer les
paramètres de la ligne de commande des scripts shell. Cela signifie que les paramètres du script ne sont
pas accessibles dans le corps d’une fonction, puisqu’ils sont masqués par les paramètres de la fonction.
Les autres variables utilisées dans les fonctions sont des variables globales. Celles qui sont déclarées
dans une fonction sont donc également globales, et restent accessibles même après l’exécution de cette

109
 Chapitre 5. Commandes Unix de base

fonction. Si l’on veut définir des variables locales, on précédera la définition de la variable du mot clé
local :

local variable=valeur

où variable est le nom de la variable locale, et valeur est sa valeur.

Les fonctions peuvent retourner une valeur numérique en code de retour. Cette valeur peut être indiquée
à l’aide de l’instruction return. Par exemple, la fonction suivante calcule la somme des entiers de 0 à la
valeur de l’entier qu’elle reçoit en paramètre :

function somme () {
local result=0
local i=0
while [ $i -le $1 ] ; do
result=$(($result + $i))
i=$(($i + 1))
done
return $result
}

Ce code d’erreur pourra être récupéré par l’appelant dans la variable d’environnement $? :

somme 10
echo $?

Les entrées / sorties de données

Tout langage de programmation qui se respecte dispose de possibilités d’entrée / sortie pour permettre la
communication avec l’utilisateur de manière interactive, et le shell n’échappe pas à la règle.
Nous avons déjà vu la commande echo dans bon nombre des exemples qui précédaient, et vous avez sans
doute deviné qu’il s’agissait là de la commande qui permet d’afficher du texte à l’écran. Son utilisation
est des plus simples, puisqu’elle se contente d’envoyer sur le flux de sortie standard une chaîne de
caractères contenant tous les paramètres qu’elle reçoit, séparés par des espaces. Nous ne nous attarderons
donc pas sur cette commande, qui n’a pas dû vous poser de problèmes jusqu’à présent.
Il ne nous reste donc plus qu’à voir la manière de demander à l’utilisateur de saisir une valeur. Avec bash,
la demande de saisie des données se fait classiquement à l’aide de la commande read. Cette commande
lit une ligne sur le flux d’entrée standard, la découpe en une ou plusieurs données et place les résultats
dans les variables d’environnement qu’elle reçoit en paramètre. La syntaxe de read est donc la suivante :

read variable1 variable2 ... variablen

où variable1, variable2, etc. sont les noms des variables d’environnement dans lesquelles les
résultats de la saisie doivent être placés.
La commande read utilise les séparateurs indiqués dans la variable d’environnement IFS pour découper
la ligne lue dans le flux d’entrée standard. Si le nombre de variables spécifié est inférieur au nombre de

110
 Chapitre 5. Commandes Unix de base

mots de cette ligne après découpage, les premières variables d’environnement reçoivent les premiers
mots, et la dernière reçoit le reste de la commande. Par exemple, la commande suivante :

read MOT RESTE

permet de lire le premier mot d’une ligne dans la variable d’environnement MOT et de placer le reste
dans la variable RESTE.
La commande read dispose d’une syntaxe simplifiée, qui ne prend aucun paramètre. Dans ce cas, la ligne
lue dans le flux d’entrée standard est placée telle quelle dans la variable d’environnement REPLY. Il est à
la charge du programmeur d’analyser son contenu.
Le shell dispose également d’une instruction évoluée permettant de réaliser des menus simplifiés :
l’instruction select. Cette instruction construit un menu à partir d’un certain nombre de choix, chaque
choix étant précédé par un numéro, et demande à l’utilisateur de taper le numéro de son choix. Elle
affecte alors la valeur du choix correspondant à une variable d’environnement, et exécute une commande
pour le traitement du choix. La syntaxe générale de l’instruction select est donnée ci-dessous :

select variable in liste ; do

action
done

où variable est le nom de la variable devant recevoir la valeur choisie par l’utilisateur, liste est la
liste des valeurs que cette variable peut prendre, et action est la liste des instructions à exécuter pour
chaque choix effectué.
Si le choix de l’utilisateur est incorrect, la variable de contrôle reçoit la valeur nulle. Le programmeur
peut récupérer la valeur saisie par l’utilisateur dans la variable d’environnement REPLY et effectuer un
traitement d’erreur approprié.
L’instruction select est une boucle. Le menu est reproposé après chaque exécution de l’action action.
La sortie de cette boucle ne peut se faire que si un caractère de fin de fichier (CTRL + D) est lu sur le flux
d’entrée standard, ou si une option de menu spécifique est proposée pour quitter cette boucle. Vous
trouverez un exemple de menu simplifié ci-dessous :

select LU in A B C D Sortir; do
case $LU in
("A") echo "Vous avez choisi A" ;;
("B") echo "Vous avez choisi B" ;;
("C") echo "Vous avez choisi C" ;;
("D") echo "Vous avez choisi D" ;;
("Sortir") break ;;
esac
done

111
 Chapitre 5. Commandes Unix de base

Les alias
Il est incontestable que certaines commandes peuvent avoir une grande complexité, et il peut être
fastidieux de les retaper complètement à chaque fois que l’on en a besoin. D’autre part, la saisie d’une
longue ligne de commande multiplie les risques de faire une faute de frappe et d’avoir à corriger la
commande. Cela peut au mieux faire perdre son temps à l’utilisateur, et au pire l’énerver.
Le shell fournit donc un mécanisme pour donner un nom simplifié aux commandes complexes : le
mécanisme des alias. Les alias représentent en fait des chaînes de caractères complexes, et sont
remplacés automatiquement par le shell lorsqu’il analyse les lignes de commandes. C’est un mécanisme
plus souple que celui des variables d’environnement, et qui permet de définir des macro-commandes plus
facilement qu’avec les fonctions du shell.
Pour créer un alias, vous devrez utiliser la syntaxe suivante :

alias nom=chaîne

où nom est le nom de l’alias, et chaîne est la chaîne de caractères représentée par cet alias. Par exemple,
pour faire un alias nommé beep permettant de faire un bip sonore, on pourra utiliser la commande
suivante :

alias beep="echo $’\a’"

Cet alias pourra être simplement utilisé simplement en tapant beep en ligne de commande.
Vous pouvez visualiser la liste des alias existant simplement à l’aide de la commande alias, appelée sans
paramètres. Je vous recommande de consulter cette liste, pour vous donner une idée des alias courants,
qui se révèlent généralement très utiles.
La suppression des alias se fait à l’aide de la commande unalias. Sa syntaxe est la suivante :

unalias nom

où nom est le nom de l’alias à supprimer.

Note : Les alias ne sont remplacés par la chaîne de caractères qu’ils représentent que lorsque le
shell analyse la ligne de commande. Cela signifie que les définitions d’alias ne sont valides qu’après
validation de cette ligne. On évitera donc de définir des alias dans la déclaration d’une instruction
composée, car cet alias ne sera pas disponible à l’intérieur de son propre bloc d’instructions.
Par défaut, les alias ne sont disponibles que dans les shells interactifs. Ils ne peuvent donc pas être
utilisés dans les scripts shell. La notion de script shell est détaillée dans la la section intitulée Les
scripts shell.

Les scripts shell

Pour l’instant, toutes les fonctionnalités de bash, aussi puissantes soient-elles, ne constituent que
l’interface d’un interpréteur de commandes puissant. Mais nous avons dit que le shell était véritablement
un langage de programmation. Cela signifie qu’il est possible d’écrire des programmes complexes en

112
 Chapitre 5. Commandes Unix de base

langage shell, simplement en stockant plusieurs commandes dans un fichier. On appelle ces fichiers des
scripts shell.
L’écriture d’un script shell n’est pas plus compliquée que de taper les commandes du programme les
unes à la suite des autres dans un shell interactif. La seule différence est que les scripts shell peuvent être
rejoués plusieurs fois, recevoir des paramètres en ligne de commande et renvoyer un code de retour.
Tout script shell est en fait un fichier texte sur lequel on a mis les droits d’exécution. Il contient les
différentes commandes qu’il doit exécuter. Sa première ligne est très importante, elle permet d’indiquer
au shell exécutant quelle est la nature du fichier. La syntaxe de cette ligne est la suivante :

#!shell

où shell est le chemin absolu sur le shell ou l’interpréteur de commande capable d’exécuter ce script.
En pratique, pour bash, on utilisera toujours la ligne suivante :

#!/bin/bash

Les paramètres des scripts shell sont accessibles exactement comme des paramètres de fonction. On
récupérera donc le premier paramètre avec l’expression $1, le deuxième avec l’expression $2, le
troisième avec l’expression $3, etc.
Le code de retour d’un shell pourra être fixé à l’aide de la commande exit. Par exemple :

exit 0

Ce code de retour pourra être récupéré par l’appelant à l’aide de l’expression $?.
Nous n’irons pas plus loin dans la description du shell bash, car ce n’est pas le but de ce document. Vous
pouvez vous référer à un bon livre d’Unix ou aux pages de manuel si vous désirez approfondir le sujet.
Comme vous avez dû vous en rendre compte dans cette section, les shells Unix sont des véritables
langages de programmation, qui dépassent de très loin les interpréteurs de commandes du type DOS. De
plus, il existe plusieurs autres langages dont nous n’avons pas parlé ici, chacun étant conçu souvent pour
réaliser un certain type de tâche (administration système, manipulation de fichiers textes, création de
pages Web dynamiques, création d’interfaces utilisateur en mode fenêtré, pilotage d’applications, etc.).
Si vous vous y intéressez, vous verrez que le sujet est réellement vaste et passionnant.

113
Chapitre 6. Administration du système de base
Un certain nombre d’opérations que l’on peut faire avec un système Unix ne rentre pas dans le cadre
d’une utilisation quotidienne, mais est destinée plutôt à l’administration du système lui-même. Ces
opérations peuvent être réalisées à l’aide de commandes Unix spéciales, généralement réservées à
l’administrateur du système, ou peuvent être réalisées en modifiant les fichiers de configuration du
système.
Il est très probable que le programme d’installation ou le programme de configuration de votre
distribution vous permette d’effectuer ces tâches de manière relativement aisée ou conviviale.
L’utilisation de ces programmes est très simple, puisqu’en général il suffit de répondre à quelques
questions et les modifications sont effectuées automatiquement pour vous. Il est fortement recommandé
de toujours essayer les programmes de ce type en premier lieu, car eux seuls connaissent les spécificités
de chaque distribution. Cela dit, ces programmes ne peuvent pas tout prévoir, parce que Linux est un
système capable d’effectuer un grand nombre de tâches très diversifiées d’une part, et parce que ce que
vous voulez en faire personnellement ne correspond pas forcément à un standard prédéterminé d’autre
part.
Cette partie décrira donc les commandes d’administration et de maintenance les plus importantes et le
mécanisme général d’amorçage des systèmes Linux. Les principaux fichiers de configuration permettant
de modifier le comportement du système seront également décrits afin de permettre un usage courant de
Linux dans de bonnes conditions. Les notions les plus avancées concernant l’administration système ne
seront en revanche pas abordées, car cela dépasserait le cadre de ce document. Les lecteurs les plus
intéressés pourront toujours se référer à un guide d’administration Unix.
L’administration du système est un peu moins sensible que son installation. En effet, les seuls risques que
l’on encourt sont de détruire les fichiers de configuration du système, et donc de devoir les recréer
manuellement. Il n’y a pas de manipulation de partitions ou de système de fichiers à créer, aussi le risque
de perdre des données est-il nettement plus faible. Cependant, les opérations d’administration se feront
sous le compte root, ce qui implique une prudence extrême. C’est pour cette raison que nous allons
commencer par sauvegarder l’ensemble des fichiers de configuration, afin de pouvoir revenir à l’état
initial après installation, sans repasser par la case départ.

Sauvegarde de la configuration d’installation

La sauvegarde de la configuration du système est une opération facile à réaliser. En effet, tous les fichiers
de configuration sont placés dans le répertoire /etc/. Par conséquent, il suffit de faire une archive des
fichiers de ce répertoire et de ses sous-répertoires. Cette opération peut être réalisée avec la commande
suivante :

tar cvfz /root/[Link] /etc/*

Cette commande créera une archive nommée [Link] dans le répertoire personnel de
l’administrateur système. On notera que, pour certaines distributions, quelques fichiers de configuration
sont placés dans le répertoire /sbin/init.d/. Pour ces distributions, on utilisera donc plutôt la
commande suivante :

114
 Chapitre 6. Administration du système de base

tar cvfz /root/[Link] /etc/* /sbin/init.d/*

De cette manière, si l’on a un gros problème avec la configuration de la machine, on peut revenir
simplement à la configuration utilisée juste après l’installation du système avec la simple commande
suivante :

tar xvfz /root/[Link]

commande que l’on exécutera dans la racine du système de fichiers.

Cette commande écrasera tous les fichiers existants par ceux de la sauvegarde. Les fichiers qui ont été
ajoutés depuis cette sauvegarde seront bien entendu conservés.
Il est également recommandé de faire une sauvegarde identique à celle-ci une fois que l’on aura réussi à
configurer le système correctement et que, théoriquement, il n’y aura plus à toucher aux fichiers de
configuration. Cette sauvegarde devra être placée sur une disquette ou un support amovible que l’on
conservera en lieu sûr.

Mise à l’heure du système

Les systèmes d’exploitation utilisent l’heure pour un certain nombre de tâches. En particulier, les fichiers
disposent de plusieurs dates (date de création, date d’accès et date de dernière modification), qui sont
utilisées par différents programmes. Les programmes de sauvegarde en font évidemment partie, parce
qu’ils se basent sur les dates de modification des fichiers pour déterminer quels sont les fichiers qui
doivent être sauvegardés depuis la dernière sauvegarde (cas des sauvegardes dites « incrémentales »).
Les programmes de maintenance sont également lancés à des dates précises, et les applications normales
des utilisateurs peuvent utiliser la date système pour l’intégrer dans leurs documents. En clair, il est
important que votre système soit à l’heure.
En fait, il existe deux horloges dans votre système. La première horloge, qui est l’horloge de référence
pour toutes les opérations effectuées dans le système, est l’horloge dite « système ». Cette horloge est
maintenue par le noyau grâce à un compteur qui est incrémenté régulièrement, sur la base d’une
interruption matérielle. La précision de ce compteur est a priori la même que celle de l’interruption du
timer matériel. Sur les PC, cette interruption a lieu, par défaut, 18,6 fois par seconde, ce qui donne pour
la plus petite unité de temps mesurable environ 1/20 de seconde (cependant, la plupart des systèmes
reprogramment la fréquence de cette interruption à 100 Hz environ). La deuxième horloge est l’horloge
matérielle, qui est l’horloge qui maintient l’heure de votre ordinateur pendant qu’il est éteint. Cette
horloge est couramment appelée l’horloge CMOS, parce qu’elle est gérée par un composant CMOS qui
stocke toutes les informations permanentes du BIOS.
Pour répondre immédiatement à une question (désormais sans objet), précisons que Linux n’a aucun
problème vis-à-vis des dates critiques du changement de millénaire. En effet, les systèmes Unix
n’utilisent qu’un seul format de date au niveau application : le nombre de secondes écoulées depuis le
01/01/1970 à 0 heure. Ce compteur est stocké sur 32 chiffres binaires sur la plupart des machines et
passe donc allègrement le cap de l’an 2000. En fait, le débordement de ce compteur est prévu pour 2038,
mais n’aura jamais lieu car l’apparition des processeurs 64 bits va porter, d’ici là, la taille de ce compteur
à 64 bits. Cela étant, il est possible que certaines applications mal écrites n’utilisent pas ce format de
date, et ne soient donc pas compatibles. Heureusement, ce cas de figure est très rare sous Unix. Bien

115
 Chapitre 6. Administration du système de base

entendu, le problème reste entier si l’horloge matérielle de votre PC n’est pas compatible. Dans ce cas, la
solution la plus simple est de régler l’heure système à chaque démarrage, manuellement ou à l’aide de
scripts de correction de la date renvoyée par l’horloge matérielle.
La valeur du compteur de l’horloge système est toujours interprétée en temps universel (« UTC » en
anglais, abréviation de « Universal Time Coordinated »), c’est-à-dire le temps de référence valide dans le
monde entier. Ce temps ne comprend pas les fuseaux horaires ni les réglementations concernant les
heures d’hiver et d’été. Cette convention est utilisée partout dans le système, ce qui est la condition sine
qua non pour que tous les ordinateurs du monde utilisent la même date et la même heure. Ainsi, deux
ordinateurs connectés à Internet peuvent communiquer sans se poser de questions quant à leurs
localisations respectives, ce qui simplifie beaucoup les choses. Notez également que le fait de compter le
temps en secondes permet de s’affranchir des conventions de découpage du temps et des calendriers
utilisés dans chaque pays.
Bien entendu, les dates présentées à l’utilisateur doivent être traduites en temps local, corrigé des écarts
pour l’heure d’été et l’heure d’hiver. Cela est réalisé par tous les programmes qui doivent afficher ces
dates (par exemple, les simples commandes ls et date). Cette conversion est effectuée par le système en
fonction du fuseau horaire et des plages de validité des horaires d’été et d’hiver.
La solution la plus simple pour régler la date et l’heure de votre machine est donc de régler l’horloge
matérielle sur le temps universel, et de définir le fuseau horaire dans lequel elle se trouve, pour que le
système puisse calculer l’heure locale. Malheureusement, les systèmes d’exploitation de Microsoft ne
voient pas la chose de la même manière. Ils attendent que l’horloge matérielle soit réglée à l’heure
locale. Par conséquent, si Linux est installé sur un ordinateur disposant déjà de Windows, vous devrez
régler l’heure de votre ordinateur en temps local. A priori, cela ne fait aucune différence, le système étant
également capable de calculer le temps universel à partir de l’heure locale et de la zone horaire.
Cependant, cela a un inconvénient : il est nécessaire de mettre à l’heure l’horloge système en cas de
déplacement de la machine, et à chaque changement d’horaire d’été ou d’hiver. Bien sûr, Windows est
supposé être capable de mettre à jour l’heure matérielle en « observation avec l’heure d’été / d’hiver ».
Mais il utilise pour cela des règles qui sont fixées définitivement dans le système et qui ne peuvent pas
être mises à jour avec les réglementations locales (par exemple, la règle de changement d’heure a été
modifiée en 1996, si bien que Windows 95 n’a jamais pu fonctionner correctement sur ce point...).
Quoi qu’il en soit, la mise à l’heure d’un système Linux requiert la définition de la zone horaire, la mise
à l’heure du système et la mise à l’heure de l’horloge matérielle. La définition de la zone horaire est
primordiale et doit avoir lieu avant toute autre opération, car le réglage des horloges dépend évidemment
de cette zone.
Les zones horaires sont définies par un ensemble de règles, qui comprennent chacune la période de
validité de la règle (en général avec une date de départ et une date de fin) et la différence entre le temps
universel et le temps local lorsque cette règle s’applique (gestion des horaires d’été et d’hiver compris).
Toutes ces règles portent le nom de la zone géographique dans laquelle elles sont valides. Vous pourrez
trouver des exemples de définitions de règles (ainsi que l’historique des conventions concernant le
temps) dans le répertoire « timezone » des sources de la bibliothèque C GNU.
Les fichiers de règles des zones horaires doivent être compilés avec le programme zic et installés dans le
répertoire /usr/share/zoneinfo. Normalement, votre système dispose de la totalité des règles, déjà
compilées, des différentes zones horaires du monde. Le programme zic permet également de définir la
zone horaire active. Cette opération se fait dans les fichiers de démarrage de votre système, avec une
commande similaire à la suivante :

zic -l zone

116
 Chapitre 6. Administration du système de base

où zone est le chemin relatif du fichier de définition des règles de la zone horaire locale, par rapport au
répertoire de base /usr/share/zoneinfo. Pour les systèmes situés en France métropolitaine, la
commande utilisée est donc celle-ci :

zic -l Europe/Paris

Une fois la zone horaire fixée, il est possible de régler l’horloge système. Il existe deux solutions pour
cela. La première solution est d’utiliser la commande système date. Cette commande, appelée sans
paramètres, permet d’obtenir la date système, exprimée en temps local. Mais elle permet également de
modifier la date et l’heure système avec l’option -s. La syntaxe complète utilisée est donnée ci-dessous :

date -s "MM/JJ/AAAA HH:MM:SS"

Il n’est pas nécessaire de préciser l’année si celle-ci ne doit pas être changée. De même, vous pouvez ne
donner que l’heure, si la date du jour est correcte. En revanche, vous devez obligatoirement préciser
l’heure si vous changez la date. Notez que l’heure doit être donnée en temps local, à moins que l’option
-u ne soit précisée. Le système réglera son horloge en temps universel automatiquement, selon les règles
de zones horaires en vigueur qui ont été indiquées par zic. Vous pouvez obtenir l’heure exacte en
appelant le 3699.
La deuxième solution est celle qui est utilisée au démarrage du système. Elle consiste à initialiser
l’horloge système à partir de l’horloge matérielle. Cette opération se fait normalement à l’aide de la
commande clock (qui en fait est un lien symbolique vers hwclock, mais la commande Unix
traditionnelle est clock). La syntaxe de cette commande est la suivante :

clock [-u] -s | -w | -a

L’option -s permet d’initialiser l’horloge système à partir de la date et de l’heure stockées dans l’horloge
matérielle. C’est typiquement cette commande qui est utilisée dans les scripts de démarrage du système.
L’option -w permet de réaliser l’opération inverse, c’est-à-dire sauvegarder la date et l’heure de l’horloge
système dans l’horloge matérielle. Elle n’est en général utilisée qu’après avoir remis à l’heure l’horloge
système. L’option -a permet, quant à elle, de corriger l’avance ou le retard que l’horloge matérielle peut
prendre.
Ce dernier point mérite quelques explications complémentaires. En fait, l’horloge matérielle n’est pas
extrêmement précise, et peut se décaler petit à petit de l’heure réelle. Heureusement, ce décalage est
constant, ce qui fait qu’il est possible de le mesurer et de le prendre en compte. Le programme clock
utilise le fichier /etc/adjtime pour enregistrer de combien est ce décalage afin de pouvoir effectuer les
corrections. Le principe de fonctionnement est le suivant :

• lors du premier réglage de l’horloge matérielle (avec l’option -w), il enregistre l’instant de ce réglage
dans le fichier /etc/adjtime ;
• lors des réglages suivants, il calcule le temps qui s’est écoulé depuis le réglage précédent, et le
décalage entre l’heure de l’horloge matérielle et l’heure à laquelle celle-ci aurait dû se trouver. Il

117
 Chapitre 6. Administration du système de base

enregistre ce décalage et met à jour la date de mise à l’heure (pour pouvoir refaire ce calcul
ultérieurement) ;
• lorsqu’on l’appelle avec l’option -a, clock ajuste l’horloge matérielle. Pour cela, il regarde la date
courante, calcule le temps écoulé depuis la dernière mise à l’heure ou le dernier ajustement, en déduit
l’avance ou le retard de l’horloge matérielle, et la remet à l’heure en conséquence. Il enregistre
également la date de cet ajustement comme nouvelle date de mise à l’heure, afin de ne pas faire deux
fois l’ajustement pour cette période la prochaine fois.
De cette manière, il est possible de maintenir l’horloge système à une valeur proche de la réalité (sans ce
genre de mécanisme, il est courant de prendre 5 minutes d’écart en trois ou quatre mois, ce qui est déjà
considérable).
Les scripts d’initialisation de votre système doivent donc certainement contenir au moins les deux lignes
suivantes après le réglage de la zone horaire :

# Ajuste l’horloge matérielle :

clock -a
# Initialise l’horloge système :
clock -s

Dans tous les cas, l’option -u permet d’indiquer que l’horloge matérielle est réglée en temps universel.
Si votre machine ne dispose pas d’autre système que Linux, il est recommandé de procéder ainsi et
d’utiliser systématiquement cette option.

Note : Il est important de définir la zone horaire avec zic avant d’utiliser clock. En effet, si l’horloge
matérielle est réglée en temps local, clock ne pourra pas déterminer l’heure en temps universel.
D’autre part, clock initialise la structure de zone horaire interne noyau, que celui-ci utilise
notamment pour l’écriture des dates en temps local sur les systèmes de fichiers FAT (Eh oui, les
dates des fichiers des systèmes de fichiers FAT sont enregistrées en temps local...).
Sachez également que l’horloge système peut également se décaler sensiblement sur de longues
périodes. Évidemment, ce phénomène ne peut se détecter que si le système reste actif
suffisamment longtemps, ce qui en pratique ne se produit que dans les serveurs (n’oubliez pas que
Linux peut fonctionner des mois sans interruption...). Si vous êtes intéressé par la manière de
resynchroniser l’horloge système pour de telles configurations, vous devriez vous intéresser à la
diffusion du temps sur le réseau Internet avec le protocole NTP (« Network Time Protocol »). En
général, la resynchronisation de l’heure système doit se faire progressivement afin de ne pas
perturber la ligne du temps pour les applications. Cela peut être fait avec le programme adjtimex.

Gestion des utilisateurs et de la sécurité

La règle de sécurité numéro un sous Unix est de ne jamais travailler dans le compte root. En effet, ce
compte dispose de tous les droits, et la moindre erreur de la part de l’utilisateur dans ce compte peut
endommager non seulement ses propres données, mais également l’ensemble du système d’exploitation.
De plus, le fait de ne pas travailler sous le compte root restreint à un seul utilisateur les dégâts que
pourraient faire un éventuel virus ou programme défectueux.

118
 Chapitre 6. Administration du système de base

L’une des premières étapes dans l’installation d’un système est donc de créer un compte utilisateur
normal, qui devra être utilisé pour le travail quotidien. Le compte root ne doit donc être réservé qu’aux
tâches d’administration, et toute opération réalisée sous cette identité doit être contrôlée deux fois avant
d’être effectivement lancée. Les programmes d’installation des distributions demandent donc toujours un
mot de passe pour protéger le compte root et le nom et le mot de passe pour au moins un compte
utilisateur standard après une nouvelle installation. Le mot de passe root doit être choisi avec un grand
soin, surtout si l’ordinateur est susceptible d’être connecté à Internet. En effet, la moindre erreur de
configuration au niveau des services fournis par l’ordinateur, couplée avec un mot de passe faible, risque
de laisser votre ordinateur à la merci de pirates mal intentionnés.
Ces mêmes programmes d’installation peuvent être utilisés par la suite pour ajouter de nouveaux
utilisateurs dans le système. Il est d’ailleurs recommandé de les utiliser dès qu’une telle opération doit
être effectuée. Cela dit, il est bon de connaître la manière dont les utilisateurs sont gérés dans les
systèmes Unix, aussi une approche plus bas niveau sera-t-elle adoptée dans cette section.

Mécanismes d’authentification des utilisateurs

La sécurité des systèmes Unix repose fondamentalement sur les mécanismes d’authentification des
utilisateurs. Ces mécanismes visent à s’assurer que chacun est bien celui qu’il prétend être, afin de
donner à chacun les droits d’accès aux différents services du système en fonction de ses privilèges.
L’accès aux services du système repose donc sur deux opérations essentielles : l’identification et
l’authentification. L’opération d’identification consiste à annoncer qui l’on est, afin de permettre au
système de déterminer les droits auxquels on a droit, et l’opération d’authentification consiste à
« prouver » qu’on est bien celui qu’on prétend être. Le système refuse ses services à tout utilisateur
inconnu (c’est-à-dire qui s’est identifié sous un nom inconnu) ou qui n’a pas passé avec succès la phase
d’authentification.
En interne, les systèmes Unix identifient les utilisateurs par un numéro qui est propre à chacun, son
« UID » (abréviation de l’anglais « User IDentifier »), mais il existe une correspondance entre cet UID et
un nom d’utilisateur plus humainement lisible. Ce nom est classiquement appelé le « login », en raison
du fait que c’est la première chose que le système demande lorsqu’on cherche à accéder à ses services,
pendant l’opération dite de login.
L’authentification des utilisateurs se fait classiquement par mot de passe, bien que d’autres mécanismes
soient possibles en théorie. L’accès au système se passe donc toujours de la manière suivante :

• le système demande à l’utilisateur son nom (c’est-à-dire son login) ;

• il demande ensuite son mot de passe ;
• il vérifie la validité du couple (login / mot de passe) pour déterminer si l’utilisateur a le droit de
l’utiliser ;
• et, si l’utilisateur est connu et s’est correctement authentifié, le programme qui a réalisé
l’authentification prend l’identité et les privilèges de l’utilisateur, fixe son environnement et ses
préférences personnelles, puis lui donne accès au système.

L’exemple classique de ces opérations est tout simplement l’opération de login sur une console : le
programme getty de gestion de la console demande le nom de l’utilisateur, puis passe ce nom au
programme login qui l’authentifie en lui demandant son mot de passe. Si l’authentification a réussi, il

119
 Chapitre 6. Administration du système de base

prend l’identité de cet utilisateur et lance son shell préféré. La suite des opérations dépend du shell. S’il
s’agit de bash, le fichier de configuration /etc/profile est exécuté (il s’agit donc du fichier de
configuration dans lequel toutes les options communes à tous les utilisateurs pourront être placées par
l’administrateur), puis les fichiers de configuration ~/.bash_profile et ~/.bashrc sont exécutés.
Ces deux fichiers sont spécifiques à chaque utilisateur et permettent à chacun d’entre eux de spécifier
leurs préférences personnelles. Le fichier ~/.bash_profile n’est exécuté que lors d’un nouveau login,
alors que le fichier ~/.bashrc est exécuté à chaque nouveau lancement de bash.
Bien entendu, ces opérations nécessitent que des informations relatives aux utilisateurs soient stockées
dans le système. Historiquement, elles étaient effectivement stockées dans le fichier de configuration
/etc/passwd. Cela n’est, en général, plus le cas. En effet, cette technique se révèle peu pratique lorsque
plusieurs ordinateurs en réseau sont accédés par des utilisateurs itinérants. Dans ce genre de
configuration, il est courant de recourir à un service réseau permettant de récupérer les informations
concernant les utilisateurs à partir d’un serveur centralisé. Plusieurs solutions existent actuellement (NIS,
LDAP, etc.), mais elles fonctionnent toutes plus ou moins selon le même principe. De plus, même pour
des machines isolées, le fichier /etc/passwd ne contient plus que les informations « publiques » sur les
utilisateurs. Les informations utilisées pour l’authentification sont désormais stockées dans un autre
fichier de configuration, qui n’est lisible que pour l’utilisateur root : le fichier /etc/shadow. La raison
première de procéder ainsi est d’éviter que des utilisateurs malicieux puissent « casser » les mots de
passe.

Note : Les mots de passe n’ont jamais été stockés en clair dans le fichier passwd. Le mécanisme
d’authentification repose en effet sur une fonction à sens unique générant une empreinte. Les
fonctions de ce type ne disposent pas de fonction inverse, il n’est donc virtuellement pas possible de
retrouver un mot de passe à partir de son empreinte. Lorsqu’un utilisateur saisit son mot de passe,
l’empreinte est recalculée de la même manière que lorsqu’il l’a défini initialement, et c’est cette
empreinte qui est comparée avec celle qui se trouve dans le fichier /etc/passwd ou le fichier
/etc/shadow. Ainsi, il est nécessaire de connaître le mot de passe en clair pour authentifier
l’utilisateur, mais à aucun moment ce mot de passe n’est stocké sur le disque dur.
Cela dit, même si la récupération des mots de passe est quasiment impossible, la connaissance des
empreintes des mots de passe peut être d’une aide précieuse. Un intrus potentiel peut essayer de
calculer les empreintes de tous les mots de passe possibles et imaginables à l’aide d’un dictionnaire
ou de mots de passe probablement choisis par les utilisateurs peu inventifs, et comparer le résultat
avec ce qui se trouve dans le fichier de mot de passe. S’il y a une correspondance, l’intrus pourra
pénétrer le système et tenter d’utiliser d’autres failles pour acquérir les droits de l’utilisateur root.
Cette technique, dite attaque du dictionnnaire, est tout à fait réalisable, d’une part parce que la
puissance des machines actuelles permet de calculer un nombre considérable d’empreintes à la
seconde, et d’autre part parce que bon nombre de personnes utilisent des mots de passe triviaux
(leur date de naissance, le nom de leur chien, etc.) facilement devinables et testables.
Les systèmes Unix utilisent deux techniques pour pallier ces problèmes. La première est de ne pas
calculer l’empreinte du mot de passe tel qu’il est fourni par l’utilisateur, mais de la calculer avec une
donnée générée aléatoirement et stockée dans le fichier de mot de passe. Cette donnée, que l’on
appelle classiquement « sel », jour le rôle de vecteur d’initialisation de l’algorithme de génération
d’empreinte. Le sel n’est jamais le même pour deux utilisateurs, ce qui fait que deux utilisateurs qui
auraient le même mot de passe n’auraient toutefoirs pas la même empreinte. Cela complique la
tâche des attaquants qui utilisent la force brute, car ils doivent ainsi recalculer les empreintes pour
chaque utilisateur.
La deuxième technique utilisée est tout simplement de ne pas laisser le fichier des empreintes
accessible à tout le monde. C’est pour cela que le fichier de configuration /etc/shadow a été
introduit. Étant lisible uniquement par l’utilisateur root, un pirate ne peut pas récupérer les

120
 Chapitre 6. Administration du système de base

empreintes de mots de passe pour les comparer avec des empreintes de mots de passe
précalculées. Il doit donc essayer les mots de passe un à un, ce qui peu en décourager plus d’un,
surtout si le système se bloque pendant un certain temps après quelques tentatives infructueuses...

La technique d’authentification par mot de passe peut paraître relativement primitive, à l’heure où les
cartes à puce sont légions et où l’on commence à voir apparaître des scanners d’empreintes digitales. En
fait, c’est une bonne solution, mais qui ne saurait en aucun cas être exhaustive en raison des problèmes
mentionnés ci-dessus. L’idéal est donc d’utiliser plusieurs systèmes d’authentification en série, ce qui
laisse libre cours à un grand nombre de possibilités.
Il est évident que la technique des mots de passe traditionnellement utilisée sur les systèmes Unix
n’évoluera pas aisément vers de nouveaux mécanismes d’authentification. C’est pour cela que les
programmes devant réaliser une opération d’authentification ou de gestion des utilisateurs de manière
générale ont été modifiés pour utiliser la bibliothèque PAM (abréviation de l’anglais « Pluggable
Authentification Modules »). Cette bibliothèque permet de réaliser les opérations d’identification et
d’authentification de manière externe aux programmes qui l’utilisent, et se base pour ces opérations des
fichiers de configuration et des modules dynamiquement chargeables. Ainsi, grâce à la bibliothèque
PAM, l’administrateur peut définir avec précision les différentes opérations réalisées pour identifier et
authentifier les utilisateurs, sans avoir à modifier les programmes qui ont besoin de ces fonctionnalités.
De plus, il est possible d’ajouter de nouveaux modules au fur et à mesure que les besoins évoluent, et de
les intégrer simplement en modifiant les fichiers de configuration.
De nos jours, la plupart des distributions utilisent la bibliothèque PAM. Bien entendu, il existe des
modules qui permettent de réaliser les opérations d’identification et d’authentification Unix classiques, et
ce sont ces modules qui sont utilisés par défaut. Nous verrons le format des fichiers de configuration de
la bibliothèque PAM plus en détail dans les sections suivantes.

Note : Les mécanismes décrits ici ne sont sûrs que dans le cadre d’une connexion sur un terminal
local. Cela dit, il faut bien prendre conscience que la plupart des applications réseau sont de
véritables passoires ! En effet, ils utilisent des protocoles qui transmettent les mots de passe en clair
sur le réseau, ce qui implique que n’importe quel pirate peut les capter en moins de temps qu’il n’en
faut pour le dire. Les protocoles applicatifs suivants sont réputés pour être non sûrs et ne devront
donc JAMAIS être utilisés sur un réseau non sûr (et donc, à plus forte raison, sur Internet) :

• TELNET, qui permet d’effectuer des connexions à distance :

• FTP, qui permet de transférer et de récuperer des fichiers sur une machine distante ;

• POP3, qui permet de consulter son mail ;

• SMTP, qui permet d’envoyer des mails à un serveur de messagerie ;

• X, qui permet aux applications graphiques d’afficher leurs fenêtres sur un terminal X.

Cette liste n’est pas exhaustive mais regroupe déjà les protocoles réseau des applications les plus
utilisées.
La sécurisation de ces protocoles ne peut se faire qu’en les encapsulant dans un autre protocole
utilisant un canal de communication chiffré. L’un des outils les plus courant pour cela est sans doute
ssh. Cet outil sera décrit dans la la section intitulée Utilisation de SSH dans Chapitre 9> du chapitre
traitant du réseau.

121
 Chapitre 6. Administration du système de base

Création et suppression des utilisateurs

La création d’un nouvel utilisateur est une opération extrêmement facile. Il suffit simplement de lui créer
un répertoire personnel dans le répertoire /home/ et de le définir dans le fichier de configuration
/etc/passwd. Si votre système utilise les shadow passwords, ce qui est probable, il faut également
définir cet utilisateur dans le fichier de configuration /etc/shadow. De plus, il faut ajouter cet
utilisateur dans au moins un groupe d’utilisateurs dans le fichier /etc/group.
Le fichier de configuration /etc/passwd est constitué de plusieurs lignes, à raison d’une ligne par
utilisateur. Chaque ligne est constituée de plusieurs champs, séparés par deux points (caractère ’:’). Ces
champs contiennent respectivement le login de l’utilisateur, l’empreinte de son mot de passe, son
identifiant numérique, l’identifiant numérique de son groupe principal, son nom complet ou un
commentaire, le chemin de son répertoire personnel et le chemin sur son interpréteur de commandes
favori. Si le champ du mot de passe contient un astérisque, le compte est désactivé. S’il est vide, le mot
de passe est stocké dans le fichier /etc/shadow.
Le fichier de configuration /etc/shadow a une syntaxe similaire à celle de /etc/passwd, mais
contient les champs suivants : le login de l’utilisateur, l’empreinte de son mot de passe, le nombre de
jours depuis que le mot de passe a été défini (comptés à partir du premier janvier 1970), le nombre de
jours après cette date à attendre avant que le mot de passe puisse être changé, le nombre de jours au delà
duquel le mot de passe doit obligatoirement être changé, le nombre de jours avant la date d’expiration de
son mot de passe pendant lesquels l’utilisateur doit être averti que son mot de passe va expirer, le nombre
de jours à attendre avant de désactiver le compte après l’expiration du mot de passe, et le nombre de
jours depuis que le compte est désactivé, comptés depuis le premier janvier 1970. Il est possible de
supprimer l’obligation pour les utilisateurs de changer régulièrement de mot de passe en donnant un
nombre de jours minimum supérieur au nombre de jours maximum avant le changement de mot de passe.
Enfin, le fichier de configuration /etc/group, dans lequel les groupes d’utilisateurs sont définis, ne
dispose que des champs suivants : le nom du groupe, son mot de passe (cette fonctionnalité n’est plus
utilisée), son identifiant numérique, et la liste des utilisateurs qui y appartiennent, séparés par des
virgules.
Bien entendu, tous ces champs ne doivent pas être modifiés à la main. La commande useradd permet de
définir un nouvel utilisateur simplement. Cette commande suit la syntaxe suivante :

useradd [-c commentaire] [-d répertoire] [-e expiration] [-f inactivité] \

[-g groupe] [-G groupes] [-m [-k modèle]] [-p passe]
[-s shell] [-u uid [-o]] login

Comme vous pouvez le constater, cette commande prend en paramètre le login de l’utilisateur,
c’est-à-dire le nom qu’il devra utiliser pour s’identifier sur le système, et un certain nombre d’options
complémentaires. Ces options sont récapitulées dans le tableau suivant :

Option Signification
-c Permet de définir le champ commentaire du fichier de mot de passe.
-d Permet de fixer le répertoire personnel de l’utilisateur.
-e Permet de fixer la date d’expiration du compte. Cette date doit être spécifiée au
format AAAA-MM-JJ.

122
 Chapitre 6. Administration du système de base

Option Signification
-f Permet de définir le nombre de jours avant que le compte ne soit désactivé une fois
que le mot de passe est expiré. La valeur -1 permet de ne jamais désactiver le
compte.
-g Permet de définir le groupe principal auquel l’utilisateur appartient. Il s’agit
souvent du groupe users.
-G Permet de donner la liste des autres groupes auxquels l’utilisateur appartient. Cette
liste est constituée des noms de chacun des groupes, séparés par des virgules.
-m Permet de forcer la création du répertoire personnel de l’utilisateur. Les fichiers du
modèle de répertoire personnel stockés dans le répertoire /etc/skel/ sont
automatiquement copiés dans le nouveau répertoire. Si ces fichiers doivent être
copiés à partir d’un autre répertoire, il faut spécifier celui-ci à l’aide de l’option -k
-p Permet de donner le mot de passe initial du compte. Cette option ne doit jamais être
utilisée, car le mot de passe apparaît dans la ligne de commande du processus et
peut être lue par un utilisateur mal intentionné. On fixera donc toujours le mot de
passe initial de l’utilisateur à l’aide de la commande passwd.
-s Permet de spécifier le shell par défaut utilisé par l’utilisateur.
-u Permet de spécifier l’UID de l’utilisateur. Cette valeur doit être unique en général,
cependant, il est possible de forcer l’utilisation d’un même UID pour plusieurs
utilisateurs à l’aide de l’option -o. Cela permet de créer un deuxième compte pour
un utilisateur déjà existant.

L’ajout d’un groupe se fait avec la commande groupadd, qui suit la syntaxe suivante, beaucoup plus
simple que celle de useradd :

groupadd [-g GID [-o]] nom

où nom est le nom du groupe et GID son numéro. Il n’est normalement pas possible de définir un groupe
avec un identifiant numérique déjà attribué à un autre groupe, sauf si l’on utilise l’option -o.
De la même manière, la suppression d’un utilisateur peut se faire manuellement en effaçant son
répertoire personnel et en supprimant les lignes qui le concernent dans les fichiers /etc/passwd,
/etc/shadow et /etc/group. Il est également possible d’utiliser la commande userdel. Cette
commande utiliser la syntaxe suivante :

userdel [-r] login

où login est le nom de l’utilisateur. L’option -r permet de demander à userdel d’effacer récursivement
le répertoire personnel de l’utilisateur, ce qu’elle ne fait pas par défaut. Il existe également une
commande groupdel pour supprimer un groupe d’utilisateurs (cette commande supprime le groupe
seulement, pas les utilisateurs qui y appartiennent !).

Note : Comme pour la plupart des autres opérations d’administration système, il est fortement
probable que l’outil de configuration fourni avec votre distribution dispose de toutes les
fonctionnalités nécessaires à l’ajout et à la suppression des utilisateurs. Il est recommandé d’utiliser
cet outil, car il peut effectuer des opérations d’administration complémentaires que les outils
standards n’effectuent pas forcément, comme la définition des comptes mail locaux par exemple.

123
 Chapitre 6. Administration du système de base

Description de la bibliothèque PAM

La bibliothèque PAM permet de centraliser toutes les opérations relatives à l’identification et à
l’authentification des utilisateurs. Ces tâches sont en effet déportées dans des modules spécialisés qui
peuvent être chargés dynamiquement dans les programmes qui en ont besoin, en fonction de paramètres
définis dans des fichiers de configuration. Le comportement des applications peut donc être parfaitement
défini simplement en éditant ces fichiers.
La bibliothèque PAM permet une très grande souplesse dans l’administration des programmes ayant trait
à la sécurité du système et devant réaliser des opérations privilégiées. Il existe déjà un grand nombre de
modules, capables de réaliser une multitude de tâches diverses et variées, et que l’on peut combiner à
loisir pour définir le comportement de toutes les applications utilisant la bibliothèque PAM. Il est hors de
question de décrire chacun de ces modules ici, ni même de donner la configuration des programmes qui
utilisent PAM. Cependant, nous allons voir les principes généraux permettant de comprendre comment
les modules de la bibliothèque sont utilisés.
Initialement, toute la configuration de PAM se faisait dans le fichier de configuration /etc/[Link].
Ce fichier contenait donc la définition du comportement de chaque programme utilisant la bibliothèque
PAM, ce qui n’était pas très pratique pour l’administration et pour les mises à jour. Les informations de
chaque programme ont donc été séparées en plusieurs fichiers distincts, à raison d’un fichier par
application, tous stockés dans le répertoire /etc/pam.d/. Il est fort probable que votre distribution
utilise cette solution, aussi le format du fichier /etc/[Link] ne sera-t-il pas décrit.
Certains modules utilisent des fichiers de configuration pour déterminer la manière dont ils doivent se
comporter. Ces fichiers de configuration sont tous stockés dans le répertoire /etc/security/. Les
modules de PAM eux-mêmes sont, quant à eux, stockés dans le répertoire /lib/security/.
Le principe de fonctionnement est le suivant. Lorsqu’un programme désire réaliser une opération relative
à l’authentification d’un utilisateur, il s’adresse à la bibliothèque PAM pour effectuer cette opération. La
bibliothèque recherche dans le répertoire /etc/pam.d/ le fichier de configuration correspondant à cette
application (il porte généralement le nom de l’application elle-même), puis détermine les modules qui
doivent être chargés dynamiquement dans l’application. Si le fichier de configuration d’une application
ne peut pas être trouvé, le fichier de configuration /etc/pam.d/other est utilisé, et la politique de
sécurité par défaut qui y est définie est utilisée. Quel que soit le fichier de configuration utilisé, chaque
module est utilisé en fonction des paramètres qui y sont stockés. Les modules peuvent, s’ils en ont
besoin, utiliser leurs propres fichiers de configuration, qui se trouvent dans le répertoire
/etc/security/. Ces fichiers portent généralement le nom du module avec l’extension .conf. Par
exemple, le fichier de configuration du module limits, qui prend en charge les limites d’utilisation des
ressources système pour chaque utilisateur, est le fichier /etc/security/[Link].
Les fichiers de configuration des applications sont constitués de lignes définissant les différents modules
qui doivent être chargés, le contexte dans lequel ils sont chargés, et comment doit se comporter
l’application en fonction du résultat de l’exécution des opérations réalisées par ces modules. L’ordre des
lignes est important, puisqu’elles sont analysées les unes après les autres. Chaque ligne est constituée de
trois colonnes. La première colonne indique le cadre d’utilisation du module. La deuxième colonne
indique le comportement que doit adopter la bibliothèque PAM en fonction du résultat renvoyé par le

124
 Chapitre 6. Administration du système de base

module après son exécution. Enfin, la troisième colonne donne le chemin d’accès complet au module,
éventuellement suivi des options qui doivent lui être communiquées pour son exécution.
Les modules peuvent être utilisés dans l’un des contextes suivants :

• auth, qui est le contexte utilisé par les programmes qui demandent l’authentification de l’identité de
utilisateur ;
• account, qui est le contexte utilisé par les programmes qui désirent obtenir des informations sur
l’utilisateur (répertoire personnel, shell, etc.)
• password, qui est le contexte utilisé par les applications qui cherchent à revalider l’authentification de
l’utilisateur. Les programmes comme passwd par exemple, qui demandent le mot de passe de
l’utilisateur avant d’en fixer un nouveau, sont susceptibles d’utiliser ce contexte ;
• session, qui est le contexte utilisé par les applications lorsqu’elles effectuent les opérations de
gestion d’ouverture et de fermeture de session. Ce contexte peut être utilisé pour réaliser des tâches
administratives, comme l’enregistrement de l’utilisateur dans la liste des utilisateurs connectés ou le
chargement des préférences personnelles de l’utilisateur par exemple.

Une même application peut définir plusieurs jeux de règles pour plusieurs contextes différents, et
certains modules peuvent être utilisés dans plusieurs contextes différents également. Cependant,
lorsqu’une application réalise une demande à la bibliothèque PAM, cette demande n’est exécutée que
dans le cadre d’un contexte bien défini. Attention cependant, une même application peut effectuer
plusieurs opérations successivement dans des contextes différents. Par exemple, le programme login peut
utiliser le contexte auth pour valider l’identité de l’utilisateur, puis le contexte account pour
déterminer le répertoire personnel de l’utilisateur, et enfin le contexte session pour enregistrer
l’utilisateur dans le journal des utilisateurs connectés.
Le comportement de la bibliothèque PAM en fonction du résultat de l’exécution des modules dépend de
ce qui est spécifié dans la deuxième colonne des lignes de ces modules. Les options qui peuvent y être
utilisées sont les suivantes :

• required, qui permet d’indiquer que le succès de l’opération effectuée par le module est nécessaire
pour que l’opération effectuée dans le contexte spécifié dans la première colonne de la ligne réussisse.
Un échec sur cette ligne ne provoque pas l’arrêt de l’analyse du fichier de configuration, ce qui permet
d’appeler d’autres modules, par exemple pour générer des traces dans les fichiers de traces du système.
Cependant, quel que soit le comportement des modules suivants, l’opération demandée par le
programme appelant échouera ;
• requisite, qui permet d’indiquer que le succès de l’opération effectuée par le module est nécessaire,
faute de quoi l’opération réalisée par le programme appelant échoue immédiatement. Les autres
modules ne sont donc pas chargés en cas d’échec, contrairement à ce qui se passe avec l’option
required ;

• sufficient, qui permet d’indiquer que le succès de l’exécution du module garantira le succès de
l’opération demandée par le programme appelant. Les modules suivants seront chargés malgré tout
après l’appel de ce module, sauf s’il s’agit de modules de type required ;
• optional, qui permet d’indiquer que le résultat du module ne doit être pris en compte que si aucun
autre module ne peut déterminer si l’opération est valide ou non. Dans le cas contraire, le module est
chargé, mais son résultat est ignoré.

125
 Chapitre 6. Administration du système de base

À titre d’exemple, nous pouvons présenter deux implémentations possibles du fichier de configuration
par défaut /etc/pam.d/other. Une configuration extrêmement sûre interdira l’accès à toute
fonctionnalité fournie par un programme n’ayant pas de fichier de configuration. Dans ce cas de
configuration, on utilisera un fichier comme celui-ci :

auth required /lib/security/pam_warn.so

auth required /lib/security/pam_deny.so
account required /lib/security/pam_deny.so
password required /lib/security/pam_warn.so
password required /lib/security/pam_deny.so
session required /lib/security/pam_deny.so

Nous voyons que toutes les opérations de type authentification ou de revalidation de l’identité sont
d’abord tracées dans les fichiers de traces du système, puis déclarées comme interdites. Une telle
configuration peut être un peu trop restrictive car, en cas d’erreur dans un fichier de configuration d’une
application, l’accès à cette application peut être interdit systématiquement. Une autre configuration, plus
permissive, cherchera à utiliser les mécanismes d’identification et d’authentification Unix classiques.
Cela se fait avec les modules pam_unix_auth, pam_unix_acct, pam_unix_passwd et
pam_unix_session :

auth required /lib/security/pam_unix_auth.so

account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_unix_passwd.so
session required /lib/security/pam_unix_session.so

Les autres fichiers de configuration ne seront pas décrits ici, car ils dépendent de chaque application et de
chaque distribution. Vous pouvez consulter ceux qui sont installés sur votre système si vous désirez en
savoir plus.
Nous ne décrirons pas non plus la syntaxe des fichiers de configuration des différents modules, car cela
dépasserait largement le cadre de ce document. Cela dit, la plupart de ces fichiers sont parfaitement
commentés et leur modification ne devrait pas poser de problème particulier. À titre d’exemple, on peut
présenter le cas du module de gestion des limites des ressources consommées par les utilisateurs. Si l’on
désire restreindre le nombre de processus que les utilisateurs peuvent lancer, on pourra ajouter la ligne
suivante dans le fichier /etc/security/[Link] :

@users hard nproc 256

Il faudra également demander le chargement de ce module dans les fichiers de configuration des
applications fournissant un accès au système. Pour cela, on ajoutera une ligne telle que celle-ci à la fin de
leur fichier de configuration :

session required /lib/security/pam_limits.so

Il est également possible de limiter le nombre de login de chaque utilisateur, la quantité de mémoire qu’il
peut consommer, la durée de connexion autorisée, la taille maximum des fichiers qu’il peut manipuler,

126
 Chapitre 6. Administration du système de base

etc. Vous trouverez de plus amples renseignements sur la configuration des modules de PAM dans le
guide d’administration de PAM pour Linux, que l’on trouvera avec les sources de PAM
([Link]

Gestion des paquetages

Il existe plusieurs systèmes de gestion de paquetages, chaque distribution fournissant ses propres outils.
Toutefois, les fonctionnalités de ces outils sont toujours de maintenir la liste des paquetages installés, et
de permettre l’installation, la mise à jour et la suppression de ces paquetages. Nous ne présenterons ici
que les systèmes de paquetages des distributions les plus utilisées. Si les outils de votre distribution ne
sont pas décrits dans cette section, ne vous alarmez pas, leur documentation vous permettra sans doute de
trouver rapidement la manière de réaliser les opérations élémentaires équivalentes.

Le gestionnaire de paquetages rpm

La plupart des distributions actuelles utilisent le format de fichier « rpm » (« Redhat Package Manager »)
pour leurs paquetages. Ce format de fichier a été introduit par la distribution Redhat, mais a été licencié
sous la licence GNU, ce qui a permis aux autres distributions de l’utiliser. Ces fichiers encapsulent tous
les fichiers des paquetages, ainsi que des informations permettant de gérer les dépendances entre les
paquetages, leurs versions, la manière de les installer dans le système, de les supprimer ou de les mettre à
jour facilement.
Les fichiers rpm peuvent être manipulés à l’aide du programme rpm. Il est probable que le programme
d’installation de votre distribution vous évite d’avoir à manipuler cet outil vous-même. Cependant, les
principales commandes de rpm seront décrites ici, afin que vous puissiez l’utiliser en cas de besoin.
Le programme rpm utilise une syntaxe très classique :

rpm options [paquetage]

Les options indiquent les opérations à effectuer. La première option est bien entendu l’option -i, qui
permet l’installation d’un paquetage :

rpm -i paquetage

La mise à jour d’un paquetage déjà installé se fait à l’aide de l’option -U :

rpm -U paquetage

La suppression d’un paquetage se fait à l’aide de l’option -e :

rpm -e paquetage

127
 Chapitre 6. Administration du système de base

La commande permettant d’obtenir les informations (auteur, description, version) sur un paquetage
contenu dans un fichier rpm est la suivante :

rpm -qi -p paquetage

Enfin, la commande pour lister tous les fichiers d’un paquetage contenu dans un fichier rpm est la
suivante :

rpm -ql -p paquetage

Cette commande affiche les chemins complets, ce qui permet de savoir dans quel répertoire chaque
fichier sera installé.
Il existe beaucoup d’autres options disponibles. Cependant, leur description dépasserait le cadre de ce
document. Vous pouvez toujours consulter la page de manuel rpm si vous désirez plus d’informations.

Le gestionnaire de paquetages apt

Les distributions basées sur la distribution Debian utilisent le gestionnaire de paquetages apt-get, qui est
sans doute l’un des plus performants qui soit. Ce gestionnaire de paquetages permet d’installer, mettre à
jour et supprimer des paquetages en tenant compte des dépendances entre ceux-ci, et ce à partir de
n’importe quelle source. Ainsi, si l’on est connecté en réseau, il est possible d’installer ou de mettre à
jour n’importe quel paquetage via le réseau. Dans le cas contraire, il faut référencer le répertoire
contenant les paquetages pour que apt-get puisse les utiliser, ce après quoi les opérations sont
exactement les mêmes.
La liste des localisations des paquetages est stockée dans le fichier de configuration
/etc/apt/[Link]. Ce fichier contient une ligne par référentiel disponible. Le format général
de ces lignes est le suivant :

type site distribution sections

où type est le type du paquetage, site est l’emplacement du référentiel, distribution est le nom de
la distribution, et sections une liste des sections dans lesquelles les paquetages pourront être trouvés.
Le type de paquetage le plus courant est deb, qui est utilisé pour les paquetages binaires pour la
distribution Debian. Par exemple, la ligne suivante permet de référencer le site principal de Debian aux
États-Unis :

deb [Link] stable main contrib non-free

Par défaut, le fichier /etc/apt/[Link] contient les références sur les principaux sites Internet
de Debian. Si vous voulez installer des paquetages que vous avez téléchargés, il va vous falloir y rajouter
une ligne telle que celle-ci :

deb file:/base répertoire/

128
 Chapitre 6. Administration du système de base

où base est un répertoire dans lequel vous devez placer un sous-répertoire contenant vos paquetages, et
répertoire est le nom de ce sous-répertoire. Vous pouvez bien entendu classer vos paquetages dans
différents sous-répertoires, du moment que vous ajoutez les lignes adéquates dans le fichier
[Link].

apt-get recherchera alors, dans chacun de ces sous-répertoires, un fichier d’index contenant la liste des
paquetages. Ce fichier doit être nommé [Link], et peut être créé simplement en compressant le
résultat de la commande dpkg-scanpackages. La commande à utiliser pour créer un tel fichier est la
suivante :

dpkg-scanpackages répertoire /dev/null | gzip > répertoire/[Link]

où répertoire est le sous-répertoire du répertoire de base dans lequel vous avez placé vos paquetages
binaires. Cette ligne de commande suppose que le répertoire courant soit le répertoire base spécifié dans
la ligne que vous avez ajouté dans le fichier [Link].
Dans le cas des CD-ROMs, la procédure est plus simple. En effet, l’utilitaire apt-cdrom permet de
prendre en compte un CD-ROM de manière automatique, avec une simple commande telle que celle-ci :

apt-cdrom -d répertoire add

où répertoire est le répertoire servant de point de montage de votre CD-ROM. Cette commande
ajoute la référence du CD-ROM dans le fichier /var/lib/apt/[Link]. Il n’existe pas de
commande pour supprimer un CD-ROM de cette liste.
Une fois les sources de paquetages définies, leur manipulation est élémentaire. Avant toute chose, il est
nécessaire de mettre à jour la liste des paquetages dans le système de paquetages. Cette opération doit
être réalisée de manière assez régulière en général, car cette liste évolue assez rapidement. Pour effectuer
cette opération, il suffit simplement d’exécuter la commande update d’apt-get :

apt-get update

L’installation d’un paquetage se fait avec la commande install d’apt-get :

apt-get install paquetage

paquetage est ici le nom du paquetage à installer. Si ce paquetage est déjà installé et que l’on désire le
réinstaller, par exemple pour le réparer ou pour le mettre à jour ajoutera l’option --reinstall :

apt-get --reinstall install paquetage

La suppression d’un paquetage est toute aussi simple. Elle se fait évidemment avec la commande
remove :

apt-get remove paquetage

Cette commande supprime le paquetage, mais ne détruit pas les fichiers de configuration qu’il a installé.
Cela permet d’éviter de perdre les éventuelles modification que l’on pourrait y avoir apportées. Si l’on
désire supprimer ces fichiers également, il faut ajouter l’option --purge :

apt-get --purge remove paquetage

129
 Chapitre 6. Administration du système de base

La mise à jour de tous les paquetages existants se fait simplement avec la commande upgrade d’apt-get :

apt-get upgrade

Cette commande ne permet pas toujours de résoudre les nouvelles dépendances sur les paquetages. C’est
pour cela que la commande dist-upgrade a été définie. Elle permet de mettre à jour le système complet
(mais est évidemment bien plus longue).
Enfin, si vous désirez obtenir des informations sur un paquetage, vous devez utiliser le programme
apt-cache. Ce programme permet de rechercher un paquetage à l’aide de mots-clefs, et d’afficher les
informations complètes sur le paquetage. Par exemple, pour obtenir des informations sur un paquetage, il
faut utiliser la commande suivante :

apt-cache show paquetage

où paquetage est le nom du paquetage. De même, pour obtenir la liste des paquetages qui se rapporte à
un mot-clef particulier, il faut utiliser la commande search d’apt-cache :

apt-cache search mot-clé

où mot-clé est le mot-clé que l’on doit rechercher dans les paquetages.

Le gestionnaire de paquetages pkgtool

Les distributions basées sur la Slackware utilisent le gestionnaire de paquetages pkgtool. Celui-ci est
beaucoup plus rudimentaire que les gestionnaires présentés précédemment, car il ne prend pas en charge
les dépendances entre les paquetages, et ne s’occupe pas de localiser les paquetages sur le réseau. Bien
entendu, la manipulation des paquetages est très simplifiée, et il est du ressort de l’utilisateur de savoir ce
qu’il fait.
L’installation d’un paquetage se fait avec la commande installpkg :

installpkg paquetage

où paquetage est le nom du paquetage à installer.

La suppression d’un paquetage se fait avec la commande removepkg :

removepkg paquetage

Enfin, la mise à jour d’un paquetage se fait avec la commande upgradepkg :

upgradepkg paquetage

Cette commande supprime toutes les anciennes versions du paquetage après avoir installé la nouvelle. La
commande upgradepkg peut également accepter en paramètre l’option --install-new, qui permet
d’installer le paquetage s’il n’est pas encore installé, et l’option --reinstall, qui permet de réinstaller
le paquetage s’il est déjà installé.

130
 Chapitre 6. Administration du système de base

Enfin, la Slackware fournit l’outil pkgtool, qui est un peu plus convivial à utiliser que les outils en ligne
de commande précédents. Cet outil fournit une interface utilisateur en mode texte permettant d’installer,
de supprimer, d’obtenir des informations sur les paquetages, ainsi que de reconfigurer le système.

Notion de niveau d’exécution et amorçage du système

La plupart des systèmes Unix disposent de plusieurs modes de fonctionnement, que l’on appelle des
niveaux d’exécution. Dans chaque niveau d’exécution, un certain nombre de services sont accessibles.
Ainsi, le lancement et l’arrêt des services des systèmes Unix peut se faire de manière groupée
simplement en changeant de niveau d’exécution. En général, il existe 7 niveaux d’exécution, dont
seulement trois fournissent des services bien définis pour quasiment toutes les distributions de Linux.
Le niveau 0 correspond à l’arrêt du système, et aucun service n’est disponible (à part le redémarrage de
la machine bien entendu...). Le fait de passer dans le niveau d’exécution 0 correspond donc à arrêter le
système. Le niveau 6 correspond au redémarrage de la machine. Le fait de passer dans le niveau
d’exécution 6 revient donc à arrêter et à redémarrer la machine. Le niveau d’exécution 1 correspond au
mode de fonctionnement mono utilisateur (encore appelé mode de maintenance). Ce niveau d’exécution
fournit les services de base pour un seul utilisateur (normalement l’administrateur du système). Dans ce
niveau d’exécution, l’administrateur peut changer la configuration et effectuer les tâches de maintenance
les plus critiques (par exemple, vérifier le système de fichiers racine). La signification des autres niveaux
d’exécution dépend de la distribution que vous utilisez mais en général le niveau d’exécution 2
correspond au mode multi-utilisateur avec réseau mais sans XWindow, et les niveaux d’exécution 3 et 4
correspond au mode multi-utilisateur avec login graphique sous XWindow. Les autres niveaux restent à
votre disposition.
Le programme en charge de gérer les niveaux d’exécution est le programme init. Ce programme est le
premier programme lancé par le noyau après qu’il a été chargé et démarré par le gestionnaire d’amorçage
(à savoir, en général, LILO ou le GRUB). Ce programme ne peut pas être détruit ou arrêté, et c’est
réellement le processus père de tous les autres dans le système. Le rôle fondamental d’init est de gérer
les changements de niveau d’exécution et de lancer et arrêter les services du système en fonction de ces
niveaux. Toutefois, il s’occupe également de tâches de base concernant la gestion des autres processus.
En particulier, il permet de supprimer les processus zombies.

Note : Un processus « zombie » est un processus qui vient de se terminer et dont aucun processus
n’a lu le code de retour. De tels processus apparaissent généralement lorsque leur processus père
se termine avant eux car, généralement, c’est toujours le processus père qui lit le code de retour de
ses processus fils.

Il suffit d’utiliser la syntaxe suivante pour forcer le changement de niveau d’exécution :

init niveau

où niveau est le niveau d’exécution à atteindre. Cela dit, cette manière de faire est assez rare, car en
général on n’a pas besoin de changer de niveau d’exécution, sauf pour arrêter et redémarrer la machine.
Mais pour ces opérations, les commandes shutdown, halt et reboot sont déjà disponibles.

131
 Chapitre 6. Administration du système de base

Le niveau d’exécution dans lequel le système doit se placer lors de son démarrage peut également être
précisé en paramètre du noyau lors du démarrage. Vous devrez donc utiliser une commande semblable à
celle-ci : LILO boot:linux niveau si vous utilisez LILO, ou kernel noyau niveau si vous
utilisez le GRUB pour démarrer le noyau noyau Linux dans le niveau d’exécution niveau. Ainsi, pour
passer en mode monoutilisateur (c’est-à-dire le mode de maintenance), il suffit de taper la commande
suivante à l’amorçage de LILO :

LILO boot:linux 1

ou la commande suivante sur la ligne de commande interactive du GRUB :

kernel /boot/vmlinuz 1

Note : Il est également possible d’utiliser le paramètre single, qui est synonyme du niveau
d’exécution 1.

Le comportement d’init est défini dans le fichier de configuration /etc/inittab. Ce fichier contient la
description des niveaux d’exécution, le niveau par défaut dans lequel le système se place au démarrage, et
les actions qu’init doit effectuer lorsque certains événements arrivent. En particulier, il est indiqué quels
sont les scripts qui doivent être exécutés lors du changement de niveau d’exécution. Il est fortement, mais
alors très fortement déconseillé de toucher au fichier /etc/inittab pour des raisons bien évidentes.
Vous trouverez de plus amples renseignements dans les pages de manuel d’init et d’inittab.
Lorsqu’on change de niveau d’exécution, ainsi qu’au démarrage du système, init appelle des scripts de
configuration pour effectuer les opérations de configuration du système et de lancement et d’arrêt des
différents services. Comme on l’a vu, ces scripts sont spécifiés dans le fichier /etc/inittab. En
général, ils sont tous placés dans le répertoire /etc/rc.d/ (ou /sbin/init.d/, selon votre
distribution). Ce répertoire contient donc :

• le script exécuté lors du démarrage du système ;

• les scripts exécutés lors de la sortie d’un niveau d’exécution ;
• les scripts exécutés lors de l’entrée dans un niveau d’exécution.

Le script appelé lors du démarrage du système est en général spécifié directement dans /etc/inittab.
Vous pouvez y ajouter les commandes spécifiques à votre système, comme par exemple les commandes
de configuration du matériel. Ce fichier n’est exécuté qu’une seule fois et est placé directement dans
/etc/rc.d/ (ou dans /sbin/init.d/).

En revanche, les scripts appelés lors du changement de niveau d’exécution sont souvent placés dans des
sous-répertoires du répertoire rc.d ou init.d. Ils sont classés à raison d’un répertoire par niveau
d’exécution. Ces sous-répertoires portent le nom de rc0.d, rc1.d, rc2.d, etc. pour les différents
niveaux d’exécution. En fait, un seul script est exécuté par init lorsqu’on change de niveau d’exécution,
et ce script se charge d’exécuter les bons scripts dans les sous-répertoires de rc.d ou init.d.

132
 Chapitre 6. Administration du système de base

Classiquement, ce script principal est appelé avec le numéro du niveau d’exécution en paramètre, et il
commence par appeler les scripts de sortie du niveau d’exécution courant, puis les scripts d’entrée dans
le nouveau niveau d’exécution.
La distinction entre les scripts d’entrée et de sortie dans chaque répertoire rc?.d se fait par la première
lettre du script. Sur certaines distributions, la lettre ’K’ correspond aux scripts de sortie et la lettre ’S’ au
script d’entrée (ces deux lettres correspondent respectivement aux mots anglais « Kill » et « Start »). De
plus, l’ordre dans lequel ces scripts doivent être exécutés est indiqué par le nombre suivant cette lettre
dans le nom du script. Cela dit, ces conventions peuvent varier selon votre distribution. Consultez votre
documentation pour plus de détails à ce sujet.
Il est assez courant que les répertoires rc?.d ne contiennent que des liens symboliques vers les fichiers
de scripts, et que ceux-ci soient tous placés directement dans le répertoire /etc/rc.d/ (ou
/sbin/init.d/). La raison en est qu’un même script peut être utilisé pour différents niveaux
d’exécution, et qu’il n’a donc pas de raison d’être dans le répertoire d’un niveau plutôt que celui d’un
autre.
De même, il est assez courant que chacun de ces scripts gère à la fois l’entrée et la sortie du niveau
d’exécution, selon le paramètre qu’il reçoit lors de son appel. Parmi les paramètres les plus courants, on
retrouve les suivants :

• start, pour le démarrage du service correspondant ;

• stop, pour son arrêt.
Ce sont les deux paramètres que le script de contrôle de changement de niveau d’exécution (celui appelé
par init et enregistré dans /etc/inittab) utilisera lors de l’entrée et de la sortie du niveau d’exécution.
Il existe d’autres paramètres, par exemple restart permet de redémarrer le service correspondant.
De cette manière, vous pouvez ajouter ou supprimer des services simplement dans chaque niveau
d’exécution. Il suffit d’écrire un fichier script capable de prendre en paramètre l’action à réaliser sur le
service (start ou stop), de le placer dans /etc/rc.d/ (ou /sbin/init.d/) et de créer les liens dans
les sous-répertoires /etc/rc.d/rc?.d/ (ou /sbin/init.d/rc?.d/). Dès lors, votre service sera
arrêté ou redémarré selon le niveau d’exécution dans lequel passera le système.
La rédaction des scripts shells de configuration dépasse largement le cadre de ce document, de même que
la configuration du comportement du système à chaque changement de niveau d’exécution. La
description qui était donnée ici permet simplement d’avoir une idée plus claire de la manière dont le
système se comporte au démarrage et à l’arrêt. Consultez la documentation de votre distribution pour
plus de détails à ce sujet.

Maintenance des systèmes de fichiers

Cette section vous présentera les opérations de base sur les systèmes de fichiers, telle que leur création,
leur montage et démontage, et leur vérification. Vous y trouverez également la manière de monter
automatiquement les systèmes de fichiers les plus utilisés au démarrage du système, ainsi que la manière
de monter « à la demande » les systèmes de fichiers amovibles. Vous verrez enfin comment réaliser des
agrégats de volumes et comment chiffrer vos systèmes de fichiers. En revanche, la description des
systèmes de fichiers réseau sera donnée dans le chapitre traitant de la configuration réseau.

133
 Chapitre 6. Administration du système de base

Création des systèmes de fichiers

Nous avons vu lors de l’installation comment créer un nouveau système de fichiers EXT2 sur une
partition à l’aide de la commande mke2fs. Cependant, Linux peut gérer de nombreux autres systèmes de
fichiers, et leur création peut se faire de manière tout à fait semblable à la création d’un système de
fichiers EXT2.
Pour chaque système de fichiers, une commande spécifique est fournie afin de le créer. Toutefois, une
commande générique de création de systèmes de fichiers permet d’uniformiser la manière de créer les
systèmes de fichiers, rendant ainsi inutile la connaissance de ces commandes spécifiques.
Cette commande générique est la commande mkfs. Elle prend en paramètre le type de système de
fichiers à créer, que l’on peut spécifier à l’aide de l’option -t. En fait, mkfs appelle systématiquement la
commande de création du système de fichiers spécifié en paramètre. Pour que cela fonctionne, il est
nécessaire que cette commande ait un nom de la forme [Link], où type est le nom du système de
fichiers. Ainsi, pour créer un système de fichiers JFS (système de fichiers journalisé créé par IBM) sur la
première partition du premier disque SCSI, il suffit d’exécuter la commande suivante :

mkfs -t jfs /dev/sda1

En général, les commandes [Link] ne sont rien d’autre que des liens vers les programmes de création
spécifiques des systèmes de fichiers.
Les commandes de création des systèmes de fichiers peuvent prendre des options particulières, qu’il faut
donc pouvoir leur fournir via mkfs. mkfs transfère donc toutes les options qu’il trouve après la
spécification du type de système de fichiers telles quelles aux programmes de création spécifique des
systèmes de fichiers. La liste des options effectivement disponibles peut être consultée dans les pages de
manuel respectives de ces programmes.

Montage des systèmes de fichiers

Comme il l’a été vu dans le chapitre expliquant les généralités sur Unix, les systèmes de fichiers ne sont
donc pas accessibles directement. Ils doivent en effet subir une opération que l’on nomme le montage
avant de pouvoir être utilisés. Le montage est donc l’opération qui consiste à associer un répertoire au
point d’entrée d’un système de fichiers. Une fois monté, les données d’un système de fichiers sont
accessibles à partir de ce répertoire. L’opération de montage permet ainsi de réaliser une abstraction du
support des systèmes de fichiers, qui peuvent se trouver aussi bien sur disque qu’en mémoire ou que sur
un réseau.
L’opération permettant de monter un disque suit la syntaxe suivante :

mount [-t type] fichier base

où fichier est le fichier contenant le système de fichiers à monter (en général, il s’agit d’un fichier
spécial de périphérique, mais ce peut également être une image disque), et base est le point de montage,
c’est-à-dire le répertoire à partir duquel le système de fichiers doit être accédé. L’option -t permet
d’indiquer le type du système de fichiers. Notez qu’en général il n’est pas nécessaire de le préciser, car le
noyau sait reconnaître la plupart des systèmes de fichiers automatiquement.
Pour information, les types de systèmes de fichiers les plus utilisés sont les suivants :

134
 Chapitre 6. Administration du système de base

• ext2, pour les systèmes de fichiers EXT2 ;

• ext3, pour les systèmes de fichiers EXT3. Il est nécessaire d’avoir créé le journal du système de
fichiers au préalable, avec l’option -j de la commande mke2fs ou de la commande tune2fs ;
• reiserfs, pour les systèmes de fichiers ReiserFS ;
• iso9660, pour les CD-ROM (qu’ils soient avec extensions Joliet ou Rock Ridge ou en mode ISO
9660 pur) ;
• ntfs, pour les systèmes de fichiers NTFS ;
• msdos, pour les systèmes de fichiers FAT normaux ;
• vfat, pour les systèmes de fichiers FAT32.

Si le répertoire de montage n’est pas vide, les fichiers qui s’y trouvent sont masqués par le système de
fichiers monté. Il est donc recommandé de ne monter les systèmes de fichiers que dans des répertoires
vides.
Pour les supports de système de fihciers amovibles, il arrive parfois que Linux ne puisse pas déterminer
la géométrie ou la table de partition du support de données. Par exemple, lorsque l’on insère une carte
mémoire dans un lecteur de carte, Linux considère que le périphérique n’a pas changé (puisque le lecteur
de carte est toujours branché) et ne relit donc pas les informations de la carte mémoire. Il peut donc être
nécessaire de demander explicitement au système de relire la table de partition du périphérique. Cela
peut être réalisé avec l’option --rereadpt de la commande blockdevnbsp;:

blockdev --rereadpt périphérique

où périphérique est le fichier spécial de périphérique dont la table de partition doit être relue.
La commande mount peut prendre diverses options pour le montage des systèmes de fichiers. Par
exemple, elle permet de monter des systèmes de fichiers en lecture seule, ou de monter des systèmes de
fichiers placés dans des images disques. Ces options sont introduites par l’option de ligne de commande
-o, et doivent être séparées les unes des autres par des virgules.

Par exemple, pour monter un système de fichiers ISO9660 en lecture seule, on utilisera la ligne de
commande suivante :

mount -t iso9660 -o ro fichier base

Une autre option utile pour le montage des CD-ROMs est sans doute l’option session, qui permet
d’indiquer le numéro de la session à monter dans le cas des CD-ROMs multisessions. Par exemple, pour
monter la deuxième session d’un CD-ROM multisession, on utilisera une ligne de commande telle que
celle-ci :

mount -t iso9660 -o ro,session=2 fichier base

Le système de fichiers EXT3 prend également des options supplémentaires par rapport au système de
fichiers EXT2. Ces options permettent de contrôler la manière dont la journalisation des opérations sur
disque est réalisée. Avec EXT3, le journal peut être utilisé pour stocker toutes les opérations concernant
la structure de données même du système de fichiers (c’est-à-dire ce que l’on appelle les

135
 Chapitre 6. Administration du système de base

« méta-données » du système de fichiers) et les opérations concernant les données des fichiers
elles-mêmes. La différence est importante et il faut bien la comprendre. Si l’on choisit de ne journaliser
que les méta-données du système de fichiers, les informations concernant les répertoires, les fichiers et
les droits d’accès seront toujours dans un état cohérent. En revanche, les données stockées dans les
fichiers eux-mêmes peuvent être a priori fausses à la suite d’un redémarrage impromptu. Si, en revanche,
on décide de stocker également les informations concernant les données des fichiers dans le journal, le
contenu des fichiers sera également garanti, au détriment d’une perte de performances notable. Le mode
de fonctionnement à utiliser est spécifié à l’aide de l’option data du système de fichiers, qui doit donc
être fixée lors de l’opération de montage. Cette option peut prendre l’une des trois valeurs suivantes :

• journal, qui permet d’effectuer une journalisation complète des méta-données et des données des
fichiers. Il est donc garanti que le contenu des fichiers est toujours cohérent, tout comme l’est le
système de fichiers. Cette option procure le maximum de sécurité, mais c’est également celle qui
pénalise le plus les performances du système (les données sont écrites deux fois, une fois dans le
journal, et une fois sur disque) ;
• ordered, qui est l’option par défaut et qui permet de ne journaliser que les méta-données, mais qui
garantit également que les tampons d’écriture sont vidés avant chaque journalisation d’une opération
disque. Tout comme avec l’option journal, il est garantit que le système de fichiers est dans un état
cohérent. Les données des fichiers seront également cohérentes avec les structures de données du
système de fichiers. Cependant, rien ne garantit que le contenu des fichiers sera lui aussi cohérent en
interne, car même si les données sont écrites avant toute modification du système de fichiers, aucun
contrôle n’est effectué pour que les écritures soient réalisées dans l’ordre dans lequel les applications
les ont effectuées. Cela dit, les performances sont meilleures qu’avec l’option journal, tout en
garantissant une sécurité quasi totale des fichiers ;
• writeback, qui permet de ne journaliser que les méta-données du système de fichiers. Le contenu des
fichiers peut donc être incorrect, voire même contenir des données aléatoires à la suite d’un arrêt brutal
du système, mais le système de fichiers est toujours dans un état correct. Cette option permet donc
simplement de rendre facultative la vérification et la réparation des systèmes de fichiers EXT2 au
redémarrage. Les performances sont quasiment aussi bonnes que pour le système de fichiers EXT2.

Enfin, il est possible de monter un système de fichiers plusieurs fois, éventuellement avec des options
différentes, dans différents points de montage. De même, il est possible de monter une partie d’un
système de fichiers seulement dans un autre répertoire, par exemple pour réaliser un raccourci vers un
sous ensemble du système de fichiers hôte. Vous pouvez consulter la page de manuel de la commande
mount pour obtenir plus de détail à ce sujet.
Vous pourrez trouver la liste des autres options acceptées par mount et par les systèmes de fichiers dans
la page de manuel mount.

Démontage des systèmes de fichiers

Les systèmes de fichiers sont gérés de manière très efficace par les systèmes d’exploitation. Des
mécanismes de copie en mémoire des données sont utilisés afin d’accélérer leur lecture, et les écritures
peuvent être différées pour être regroupées et ainsi optimiser les transferts. De ce fait, l’état du système
de fichiers sur le support n’est quasiment jamais exactement en phase avec celui du système de fichiers en
mémoire lorsqu’il est en cours d’utilisation. Il est donc nécessaire de signaler au système d’exploitation

136
 Chapitre 6. Administration du système de base

que l’on désire l’arrêter avant de couper le courant, ou que l’on désire retirer un lecteur amovible avant
de le faire, afin qu’il puisse effectuer les synchronisations nécessaires. Ne pas le faire risquerait de
provoquer des pertes de données irrémédiables. Cette opération s’appelle simplement le démontage.

Note : Bien entendu, les commandes d’arrêt du système se chargent (entre autres) de démonter
tous les systèmes de fichiers avant d’éteindre l’ordinateur.

La commande permettant de démonter un système de fichiers est beaucoup plus simple que celle
permettant de les monter, car aucune option n’est nécessaire. Il suffit en effet d’exécuter l’une des
commandes suivantes :

umount fichier

ou :

umount base

Dans ce commandes, fichier représente le fichier contenant le système de fichiers à démonter, et base
est le répertoire dans lequel ce système de fichiers est monté. On peut utiliser l’un ou l’autre de ces
paramètres, la commande umount se débrouillera pour retrouver l’autre automatiquement. On notera
qu’il est impossible de démonter un système de fichiers qui est en cours d’utilisation par quelqu’un. En
particulier, il ne faut pas être dans le répertoire servant de point de montage pour pouvoir démonter un
système de fichiers, car dans ce cas on est en train de l’utiliser. Faites bien attention à l’orthographe de la
commande umount, elle a perdu son ’n’ depuis bien longtemps déjà, et on ne l’a jamais retrouvé. Si
vous savez où il se trouve, faites-le savoir.
Pour les supports de systèmes de fichiers amovibles, le démontage du système de fichiers peut ne pas être
suffisant. En effet, il peut être nécessaire d’arrêter le périphérique correctement avant de l’ejecter. C’est
en particulier le cas pour les systèmes de fichiers sur les clefs USB par exemple. Cette opération peut être
réalisée à l’aide de la commande eject :

eject périphérique

où périphérique est le fichier spécial du périphérique à ejecter. Cette commande réalise également
l’opération de démontage sur les systèmes de fichiers montés avant d’ejecter le disque.

Vérification des systèmes de fichiers

La vérification des systèmes de fichiers est une opération que l’on ne devrait jamais avoir à faire. Il y a
plusieurs raisons à cela. Premièrement, si l’on arrête le système correctement avant d’éteindre la
machine, et si l’on démonte bien les systèmes de fichiers avant de retirer les lecteurs amovibles, les
systèmes de fichiers sont normalement toujours dans un état correct. Deuxièmement, les systèmes de
fichiers Unix sont réputés pour être très fiables. Troisièmement, une vérification périodique est faite par
le système au bout d’un certain nombre de démarrages. Quatrièmement, si un système de fichiers n’est
pas démonté correctement avant l’arrêt du système, celui-ci sera vérifié automatiquement au démarrage
suivant, ce qui fait qu’il n’y a pas lieu de le faire soi-même. Enfin, pour les systèmes de fichiers
journalisés tels que EXT3, JFS ou ReiserFS, cette opération peut être réalisée très rapidement à l’aide
des informations qui sont stockées dans le journal des transactions du système de fichiers.

137
 Chapitre 6. Administration du système de base

Toutefois, même le meilleur système du monde ne saurait être à l’abri des secteurs défectueux du disque
dur sur lequel il est installé. Il est donc parfois nécessaire d’effectuer une vérification manuelle des
systèmes de fichiers, et il faut savoir le faire même quand plus rien ne fonctionne.
Un système de fichiers ne se manipule que lorsqu’il est démonté. Cela pose évidemment quelques
problèmes pour le système de fichiers racine, puisqu’on ne peut pas accéder aux outils de vérification
sans le monter. Pour ce système de fichiers, il n’y a donc que deux possibilités :

• soit on utilise une disquette de démarrage contenant les outils de vérification et de réparation des
systèmes de fichiers ;
• soit on monte le système de fichiers racine en lecture seule.
La deuxième solution est la seule réalisable si l’on ne dispose pas de disquette de démarrage. Par
conséquent, c’est cette méthode qui sera décrite ici.
La première étape consiste à passer en mode mono utilisateur, afin de s’assurer que personne ni aucun
programme n’accède au système de fichiers racine en écriture. Pour cela, il suffit de taper la commande
suivante :

init 1

qui fait passer le système dans le niveau d’exécution 1. On peut également passer le paramètre single
au noyau lors de l’amorçage du système, comme il l’a été expliqué dans la section précédente. Ensuite, il
faut s’assurer que le système de fichiers racine est en lecture seule, ce qui se fait avec la commande
suivante :

mount -n -o remount,ro /

L’option remount permet de démonter et de remonter le système de fichiers racine, et l’option ro

indique qu’il doit être remonté en lecteur seule (« ro » signifie « Read Only »). Les options sont séparées
par des virgules (attention, il ne faut pas insérer d’espace). De plus, l’option -n indique à mount qu’il ne
doit pas écrire dans le fichier /etc/mtab lorsqu’il aura remonté le système de fichiers, parce que ce
fichier sera alors également en lecture seule et qu’on ne pourra pas y écrire. Ce fichier est utilisé par
mount pour mémoriser les systèmes de fichiers qui sont montés, afin de pouvoir en donner la liste (ce
que la commande mount fait lorsqu’elle est appelée sans paramètres) et de permettre à la commande
umount de vérifier que les systèmes de fichiers à démonter ne le sont pas déjà.

Note : Normalement, le noyau monte toujours le système de fichiers racine en lecture seule lors de
l’amorçage. Ce sont les scripts de démarrage du système, lancés par init, qui le remontent en
lecture / écriture s’il est dans un état correct. Il est donc fortement probable, si votre système ne
démarre plus correctement, que le système de fichiers racine soit déjà en lecture seule après un
démarrage en mode de maintenance. La commande précédente n’est donc décrite qu’à titre indicatif.

Une fois le système de fichiers racine monté en lecture seule, on peut utiliser le programme fsck afin de
le vérifier et éventuellement le réparer. En réalité, ce programme ne fait rien d’autre que d’appeler un
programme spécifique pour chaque système de fichiers, de la même manière que mkfs appelle des
programmes spécifiques pour les créer. Par exemple, pour les systèmes de fichiers EXT2 et EXT3, fsck
appelle le programme [Link] (qui est un lien vers e2sfck).

138
 Chapitre 6. Administration du système de base

La ligne de commande à utiliser pour vérifier un système de fichiers avec fsck est la suivante :

fsck -a fichier

où fichier est le fichier spécial du périphérique ou le fichier image contenant le système de fichiers à
vérifier. Il faut donc, généralement, spécifier la partition sur laquelle le système de fichiers racine se
trouve. L’option -a demande à fsck d’effectuer les éventuelles corrections automatiquement en cas
d’erreur sur le système de fichiers ainsi vérifié, sans confirmation de la part de l’utilisateur.
Il est également possible de demander la vérification de tous les systèmes de fichiers enregistrés dans le
fichier de configuration /etc/fstab. Ce fichier contient la liste des systèmes de fichiers les plus utilisés
et leurs options respectives. Il suffit donc d’ajouter l’option -A :

fsck -a -A

Il n’est évidemment plus nécessaire de spécifier le fichier spécial du périphérique contenant le système
de fichiers à vérifier, puisque cette information est enregistrée dans le fichier /etc/fstab. La syntaxe
de ce fichier sera décrite dans la section suivante.
Si le disque dur contient des secteurs défectueux, il peut être nécessaire de les marquer comme tels dans
les structures du système de fichiers afin de ne pas les utiliser par la suite. De manière générale, la
recherche de ces blocs peut être faite à l’aide du programme badblocks. Cette commande effectue un
test de lecture de tous les blocs du disque sur lequel le système de fichiers se trouve, et génère une liste
des blocs défectueux. Vous pouvez l’appeler directement et fournir cette liste au programme e2fsck à
l’aide de son option -l, mais le plus simple est encore de demander à e2fsck d’appeler badblocks
lui-même. Pour cela, il suffit de lui passer l’option -c, ce qui se fait en faisant précéder cette option d’un
double-tiret dans la ligne de commande de fsck :

fsck -a -- -c périphérique

Note : L’option -c est spécifique à e2fsck et peut ne pas fonctionner avec d’autres systèmes de
fichiers. En particulier, certains systèmes de fichiers ne sont pas capable de gérer correctement les
blocs défectueux des disques durs. C’est le cas du système de fichiers ReiserFS.
Le programme badblocks peut également effectuer un test d’écriture sur le disque dur, si on lui
communique l’option -w. Il va de soi que ce type de test est destructif, car toutes les données du
disque sont alors écrasées par des motifs particuliers. Il ne faut donc JAMAIS utiliser cette option sur
un système de fichiers contenant des données !

De manière général, il vaut mieux prévenir que guérir, aussi est-il recommandé d’utiliser la commande
badblocks au moins une fois avant d’utiliser un système de fichiers. Cette vérification peut être réalisée
de manière automatique lors de la création du système de fichiers à l’aide de l’option -c de la commande
mke2fs.
Une fois que vous aurez terminé la vérification du système de fichiers, vous pourrez le remonter en
lecture et écriture avec la commande suivante :

mount -n -o remount,rw /

139
 Chapitre 6. Administration du système de base

Cette commande est similaire à celle que l’on a vue pour monter le système de fichiers en lecture seule, à
ceci près que l’option rw est utilisée à la place de l’option ro. Cette option permet de remonter le
système de fichiers en lecture et en écriture (« rw » est l’abréviation de l’anglais « Read Write »).

Configuration du montage des systèmes de fichiers

Le montage des systèmes de fichiers peut devenir très vite est une opération assez fastidieuse.
Heureusement, elle peut être automatisée au démarrage pour les systèmes de fichiers situés sur les
disques fixes, et simplifiée pour les systèmes de fichiers amovibles. Pour cela, il faut enregistrer ces
systèmes de fichiers et leurs options de montage dans le fichier de configuration /etc/fstab.
Ce fichier contient, entre autres, le répertoire de montage, le type du système de fichiers et le fichier de
périphérique à utiliser pour chaque système de fichiers. De cette manière, il est possible d’utiliser la
commande mount de manière simplifiée, en ne précisant que le répertoire servant de point de montage
ou le fichier spécial de périphérique.
Le fichier /etc/fstab contient une ligne pour chaque système de fichiers enregistré. Chaque ligne
contient plusieurs champs séparés par des espaces. Les informations suivantes sont enregistrées dans ces
champs :

• le fichier spécial permettant d’accéder au système de fichiers ;

• le répertoire servant de point de montage par défaut ;
• le type du système de fichiers ;
• les options de montage pour ce système de fichiers ;
• un entier indiquant si le système de fichiers doit être sauvegardé ;
• un entier indiquant l’ordre que ce système de fichiers doit avoir dans la liste des systèmes de fichiers à
vérifier.

Grâce à ces informations, l’emploi de la commande mount est plus simple :

mount périphérique

ou :

mount répertoire

où périphérique est le fichier spécial de périphérique contenant le système de fichiers à monter, et

répertoire est le répertoire servant de point de montage indiqué dans le fichier /etc/fstab. Il est
possible d’utiliser indifféremment le fichier spécial de périphérique ou le répertoire du point de montage.
Le type du système de fichiers est l’un des types disponibles acceptés par la commande mount.
Consultez la page de manuel de cette commande pour plus de renseignements à ce sujet. Les principales
options disponibles pour le montage sont les suivantes :

• l’option defaults, qui permet de choisir les options par défaut pour ce système de fichiers ;

140
 Chapitre 6. Administration du système de base

• l’option auto, qui permet de faire en sorte que le système de fichiers soit monté automatiquement au
démarrage du système ;
• l’option user, qui permet d’autoriser le montage de ce système de fichiers par les utilisateurs ;
• l’option ro, qui permet de monter le système de fichiers en lecture seule ;
• l’option rw, qui permet de monter le système de fichiers en lecture et écriture ;
• l’option exec, qui permet d’autoriser l’exécution des fichiers exécutables sur ce système de fichiers si
celui-ci ne supporte pas la notion de droit d’exécution ;
• l’option acl, qui permet d’autoriser l’utilisation des ACLs (« Access Control List ») pour fixer les
droits des utilisateurs sur les fichiers ;
• l’option uid=utilisateur, qui permet de spécifier le numéro utilisateur de l’utilisateur
propriétaire du répertoire racine de ce système de fichiers ;
• l’option gid=groupe, qui permet de spécifier le numéro groupe du groupe d’utilisateurs auquel le
répertoire racine du système de fichiers appartient ;
• l’option mode=valeur, qui permet de fixer les droits sur le répertoire racine du système de fichiers à
monter. La valeur valeur est donnée en octal ;
• l’option umask=valeur, qui permet de fixer les droits sur les fichiers qui ne sont pas gérés par le
système de fichiers. La valeur valeur est donnée en octal ;
• les options codepage=cp et iocharset=charset, qui permettent de fixer les tables de conversion
des caractères pour les systèmes de fichiers pour lesquels les noms de fichiers doivent être transcodés.

Nous allons détailler un peu quelques-unes de ces options.

Par défaut, les utilisateurs n’ont pas le droit de monter et de démonter les systèmes de fichiers. L’option
user permet de désactiver cette protection. Elle peut être utile pour permettre le montage et le
démontage des disquettes et des CD-ROM. De même, l’exécution des fichiers exécutables n’est par
défaut pas autorisée sur les systèmes de fichiers. Cette restriction permet d’éviter l’exécution de
programmes placés sur des systèmes de fichiers de systèmes d’exploitation différents. Elle peut être
levée grâce à l’option exec.
Tous les systèmes de fichiers disposant de l’option auto seront montés automatiquement au démarrage
du système par la commande mount -a. Les autres systèmes de fichiers sont montables manuellement,
avec les autres options indiquées dans le fichier /etc/fstab.
Les options ro et rw permettent d’indiquer à mount si le système de fichiers doit être monté en lecture
seule ou en lecture et écriture. Les systèmes de fichiers devant être réparés doivent être montés en lecture
seule si l’on ne peut pas les démonter (c’est le cas notamment du système de fichiers racine). Il en va de
même pour les CD-ROM, car on ne peut bien entendu pas écrire dessus.
Les options uid et gid permettent de spécifier le propriétaire et le groupe du répertoire racine du
système de fichiers à monter. Par défaut, c’est l’utilisateur root qui devient propriétaire de ce système de
fichiers.
L’option mode permet de spécifier les droits d’accès sur tous les fichiers du système de fichiers à monter.
L’option umask permet quant à elle de fixer les droits qui ne sont pas gérés par le système de fichiers. Ce
peut être utile pour les systèmes de fichiers FAT et FAT32. Il est ainsi possible de donner les droits de
lecture et d’exécution pour les fichiers de ces systèmes avec une valeur de masque nulle. Cela permet de

141
 Chapitre 6. Administration du système de base

monter les systèmes de fichiers FAT et FAT32 de telle sorte que tous les fichiers appartiennent à
l’utilisateur root par défaut, et de donner cependant tous les droits à tous les utilisateurs sur ces fichiers.
On prendra garde à ces options, car elles permettent à quiconque d’écrire des fichiers sous le nom de
root, et donc constituent un grave défaut dans la sécurité du système.
Les options codepage et iocharset permettent de spécifier respectivement la page de codes et le jeu
de caractères utilisés pour les systèmes de fichiers qui ne stockent pas les noms de fichiers Unix
nativement. En particulier, elles permettent de modifier la page de code et le jeu de caractères
sélectionnés par défaut dans la configuration du noyau pour les systèmes de fichiers FAT. L’option
codepage est utilisée pour donner la page de codes utilisée pour la conversion des noms de fichiers en
noms de fichiers courts. En général, pour les systèmes français, la page de codes utilisée est la page de
codes 850. Il faut donc donner à cette option la valeur cp850. L’option iocharset quant à elle est
utilisée pour faire la conversion des noms de fichiers Unix en Unicode. Elle est utilisée pour les systèmes
de fichiers VFAT, car ceux-ci stockent les noms de fichiers longs en Unicode. Pour la plupart des
systèmes, le jeu de caractères le plus approprié est sans doute le jeu de caractères ISO8859-1. Aussi
faut-il généralement donner à cette option la valeur iso8859-1. Cette option n’est pas nécessaire pour
les systèmes de fichiers FAT purs, puisque ceux-ci ne savent pas gérer les noms de fichiers longs.
Les deux derniers champs de /etc/fstab spécifient des options pour des programmes annexes.
L’avant-dernier contrôle le comportement du programme de sauvegarde dump, et le dernier celui du
programme de vérification de système de fichiers fsck. Consultez les pages de manuel pour plus de
détails à ce sujet.
Si vous disposez de systèmes de fichiers FAT ou FAT32, vous pourrez monter ces partitions
automatiquement lors du démarrage du système. Comme les systèmes de fichiers basés sur la FAT ne
peuvent pas gérer les droits des utilisateurs, vous allez devoir faire un choix pour fixer ces droits à une
valeur raisonnable. Vous pouvez par exemple donner le droit de lecture à tous les utilisateurs, mais le
droit d’écriture uniquement à l’administrateur système. La ligne à ajouter dans le fichier /etc/fstab
sera alors la suivante :

/dev/partition répertoire vfat auto,exec,codepage=cp850,iocharset=iso8859-1 0 0

où partition est la partition contenant le système de fichiers FAT, et répertoire est le répertoire
servant de point de montage pour cette partition. Cette ligne permettra de monter automatiquement ce
système de fichiers en tant que FAT32 au démarrage du système. Les fichiers binaires seront exécutables,
bien qu’ils ne soient pas stockés sur un système de fichiers EXT2. Si vous voulez laisser les droits
d’écriture aux utilisateurs, vous pouvez utiliser la ligne suivante à la place de celle indiquée ci-dessus :

/dev/partition répertoire vfat auto,codepage=cp850,iocharset=iso8859-1,umask=0 0 0

Cette ligne permet de monter le système de fichiers FAT en laissant les droits d’exécution et d’écriture
aux utilisateurs. Cependant, aucun fichier exécutable de ce système de fichiers ne pourra être lancé, car
l’option exec n’a pas été précisée.
Par ailleurs, certaines distributions spécifient des options incorrectes pour le système de fichiers
/dev/pts/ dans le fichier /etc/fstab. Veuillez vous assurer que la ligne utilisée pour ce système de
fichiers est bien identique à la ligne suivante :

none /dev/pts devpts auto,gid=5,mode=620 0 0

142
 Chapitre 6. Administration du système de base

Si ce n’est pas le cas, certains émulateurs de terminaux développés récemment ne fonctionneront pas
correctement. Le système de fichiers /dev/pts/ est en effet un système de fichiers virtuel, géré
directement par le noyau, dans lequel des fichiers spéciaux de périphériques utilisés par les émulateurs de
terminaux sont placés. Si les droits ne sont pas correctement fixés sur le répertoire racine de ce système
de fichiers, les émulateurs de terminaux utilisant cette fonctionnalité ne pourront se connecter au système
que sous le compte root. Il faut donc impérativement corriger cette ligne, si vous voulez que les
utilisateurs normaux puissent utiliser ces émulateurs. Notez également qu’il faut que tout le monde ait les
droits d’écriture et de lecture sur le fichier spécial de périphérique /dev/ptmx pour que les utilisateurs
non privilégiés puissent utiliser ce système de fichiers virtuel.
Vous devrez également ajouter le système de fichiers virtuel /dev/shm/ dans votre fichier /etc/fstab.
Ce système de fichiers permet aux applications qui le désirent d’utiliser des segments de mémoire
partagée de manière compatible avec la norme POSIX, par exemple pour réaliser des communications
inter-processus. Ce système de fichiers permet en effet de créer des fichiers qui sont directement stockés
dans la mémoire virtuelle et qui peuvent être ouverts par plusieurs processus simultanément, ce qui
permet d’utiliser les fonctionnalités classiques de partage de fichiers pour partager des zones de mémoire
entre plusieurs processus. Ce type de communication peut être utilisé par des processus courants, aussi
faut-il vous assurer que la ligne suivante se trouve bien dans la fichier fstab :

tmpfs /dev/shm tmpfs defaults 0 0

Bien entendu, vous devrez créer le point de montage /dev/shm/ si celui-ci n’existe pas avant de monter
ce système de fichiers virtuels.
Vous pouvez monter les systèmes de fichiers virtuels du noyau, qui vous permettront d’obtenir des
informations sur votre système et d’en modifier le comportement, en ajoutant les deux lignes suivantes
dans le fichier /etc/fstab :

proc /proc proc defaults 0 0

sysfs /sys sysfs defaults 0 0

La première ligne monte le système de fichiers /proc/, qui contient tous les paramètres du noyau et
permet de paramétrer son comportement, et la deuxième contient le système de fichiers /sys/, qui
contient une vue de tous les objets systèmes gérés par le noyau. Ce système de fichiers n’est disponible
qu’avec les versions 2.6 et plus du noyau. Ces deux lignes ne sont généralement pas nécessaires, car ces
systèmes de fichiers sont montés automatiquement dans les scripts d’initialisation des distributions.
Enfin, si vous utilisez des périphériques USB, il vous faudra également monter le système de fichiers
virtuel /proc/bus/usb/ en ajoutant la ligne suivante dans le fichier fstab :

none /proc/bus/usb usbfs defaults 0 0

Cette ligne doit être placée après celle qui effectue le montage du système de fichiers virtuel /proc/.

Montage des systèmes de fichiers à la demande

Les systèmes de fichiers sur les supports amovibles ne peuvent pas être montés automatiquement au
démarrage du système, étant donné qu’ils ne sont pas forcément présents à ce moment. Les entrées qui
les décrivent dans le fichier fstab doivent donc utiliser l’option noauto. De ce fait, l’utilisation des

143
 Chapitre 6. Administration du système de base

systèmes de fichiers stockés sur les supports amovibles nécessite toujours un montage et un démontage
manuel, et même si ces opérations sont simplifiées, elles restent gênantes.
Il est toutefois possible de faire en sorte que ces systèmes de fichiers soient montés à la demande, c’est à
dire dès qu’un accès est réalisé dans les répertoires de montage dédiés à ces systèmes par un quelconque
programme. Ainsi, il n’est plus nécessaire de monter ces systèmes de fichiers manuellement. Le
démontage quant à lui peut être réalisé automatiquement après un temps d’inactivité, ou manuellement,
lorsqu’on veut retirer le lecteur amovible. Notez que le démontage reste vital si le système de fichiers est
accédé en écriture, car des données pourraient être perdues si l’on supprime le lecteur avant qu’elles ne
soient écrites.
Les opérations de montage et de démontage sont réalisées par un démon, que le noyau appelle
automatiquement dès qu’une opération susceptible de concerner un système de fichiers amovible se
produit. Ce démon se nomme automount, et il s’appuie donc sur une fonctionnalité dédiée du noyau
Linux. Pour que le montage automatique des systèmes de fichiers fonctionne, il faut activer soit l’option
« Kernel automounter support », soit l’option « Kernel automounter version 4 support
(also supports v3) » du menu « File systems » du programme de configuration du noyau.

Note : Un démon est un processus qui tourne en arrière plan dans le système. Les démons
fonctionnent souvent dans le compte root et offrent des services de base que les autres programmes
utilisent. Le terme « démon » provient de la traduction littérale « daemon », ce qui signifie « ange »
en réalité. Le démon se place donc en tant qu’intermédiaire entre Dieu (c’est-à-dire le noyau) et les
hommes (c’est-à-dire les applications normales). Le terme « daemon » a été ensuite éclairci et défini
comme l’acronyme de l’anglais « Disk And Execution MONitor ».

Le démon automount peut surveiller plusieurs points de montage, s’ils sont tous placés dans le même
répertoire. Le noyau surveille simplement les accès sur les sous-répertoires de ce répertoire, et signale à
automount toutes les opérations susceptibles de nécessiter un montage de système de fichiers.
Les informations spécifiques aux points de montage doivent être stockées dans un fichier de
configuration, que l’on doit fournir à automount en ligne de commande. Cette ligne de commande est
donc typiquement de la forme suivante :

automount -t durée répertoire file fichier

où durée est la durée d’inactivité avant démontage automatique du système de fichiers, répertoire est
le répertoire dont les sous-répertoires seront utilisés comme points de montage des systèmes de fichiers
(il s’agit généralement du répertoire /mnt/), et fichier est le fichier de configuration pour les points
de montage placés dans ce répertoire. La durée d’inactivité doit être spécifiée en secondes, et la valeur
par défaut est de cinq minutes. Pour désactiver le démontage automatique, il suffit de spécifier une valeur
nulle.

Note : automount est capable d’utiliser d’autres méthodes de paramétrage des systèmes de
fichiers amovibles que des fichiers de configuration, principalement utilisées dans le contexte du
montage automatique des systèmes de fichiers en réseau. Ces méthodes de paramétrage ne seront
toutefois pas décrites ici, vous pouvez consulter la page de manuel du démon automount pour plus
de détails à ce sujet.

144
 Chapitre 6. Administration du système de base

Les fichiers de configuration pour automount sont généralement placés dans le répertoire /etc/, et
portent un nom de la forme « [Link] », où nature est la nature des systèmes de fichiers décrits
par ce fichier. Par exemple, le fichier de configuration pour les lecteurs amovibles locaux pourrait
s’appeler /etc/[Link]. Ce fichier de configuration est constitué de plusieurs lignes, à raison
d’une ligne par point de montage. Chaque ligne utilise la syntaxe suivante :

répertoire -options périphérique

où répertoire est le sous-répertoire du répertoire spécifié en ligne de commande à automount et

devant servir de point de montage, options est la liste des options de montage du système de fichiers,
séparées par des virgules, et périphérique est la localisation du système de fichiers. Pour les lecteurs
amovibles, il s’agit du fichier spécial de périphérique permettant d’y accéder, précédé du caractère ’:’.
Par exemple, pour réaliser le montage automatique du lecteur de CD-ROM et du lecteur de disquettes,
vous devez ajouter deux lignes telles que celles-ci dans le fichier de configuration d’automount :

cdrom -fstype=iso9660,ro :/dev/cdrom

floppy -fstype=auto,umask=0 :/dev/fd0

Vous noterez que les options sont précédées d’un tiret (’-’), et que les fichiers spéciaux de périphérique
sont précédés de deux points (’:’). Une fois ce fichier défini, vous n’aurez plus qu’à lancer automount
avec la ligne de commande suivante :

automount -t 60 /mnt file /etc/[Link]

En général, les distributions lancent automatiquement le démon automount au démarrage, via le script
d’initialisation [Link]. Ce script utilise le fichier de configuration /etc/[Link] pour
déterminer les noms des fichiers de configuration à fournir en paramètre aux démons automount, ainsi
que pour déterminer les options avec lesquelles ils doivent être lancés. Ce fichier est constitué de lignes,
à raison d’une ligne par instance du démon automount qui doit être lancée. Le format de ces lignes est le
suivant :

répertoire fichier options

où répertoire est le répertoire spécifié en ligne de commande à automount, fichier est le fichier de
configuration, et option est la liste des options à lui fournir. Par exemple, pour lancer automatiquement
automount comme dans l’exemple précédent, la ligne suivante devrait être ajoutée dans le fichier
/etc/[Link] :

/mnt /etc/[Link] -t 60

Note : Vous noterez que lorsque les systèmes de fichiers ne sont pas montés, le répertoire
contenant leurs points de montage est vide. De ce fait, les chemins sur ces répertoires devront être
saisis explictement pour forcer le montage des systèmes de fichiers. Cela peut être gênant lorsque
l’on utilise les fonctionnalités de complétion automatique des shells, ou lorsqu’on cherche à localiser
un fichier dans un de ces répertoires avec un gestionnaire de fichiers ou une boîte de dialogue d’un

145
 Chapitre 6. Administration du système de base

programme graphique. Une solution pour résoudre ce problème est de forcer une référence aux
points de montage. Pour cela, il suffit de définir des liens symboliques sur les points de montage, et
d’utiliser ces liens symboliques vers ces points de montage. Par exemple, on pourra définir les liens
symboliques /cdrom et /floppy pour référencer les points de montage /mnt/cdrom et
/mnt/floppy, et laisser automount monter les systèmes de fichiers relatifs et créer les répertoires
des points de montage dès qu’on accèdera aux liens symboliques.

Gestion des volumes

Linux fournit des mécanismes très puissants permettant de créer des fichiers spéciaux de périphérique de
type bloc virtuels, et d’indiquer les données qui seront accédées au travers de ces fichiers. Cela permet de
manipuler des systèmes de fichiers stockés sur un fichier. Linux permet également de réaliser des
agrégats de volumes. Ces agrégats peuvent ensuite être accédés via différentes techniques, par exemple
pour réaliser de la réplication de données ou tout simplement pour simuler un périphérique de très grande
taille. Ils permettent également de réaliser à la volée des opérations de chiffrement sur les données
écrites, et de les déchiffrer en lecture. Ainsi, ces mécanismes d’agrégation sont utilisés pour gérer les
volumes de manière beaucoup plus souple que les mécanismes de partitionnement classiques et pour
créer des systèmes de fichiers chiffrés à l’aide des algorithmes cryptographiques du noyau. Nous allons
présenter tous ces mécanismes dans les sections suivantes.

Gestion des fichiers images

Linux permet de stocker des systèmes de fichiers dans des fichiers image et de les manipuler de manière
transparente, grâce à un mécanisme de périphériques de type bloc virtuel. Le principe est d’associer le
fichier à l’un de ces périphériques, et d’utiliser simplement le fichier spécial de périphérique
correspondant comme un fichier spécial de périphérique de type bloc classique. Il est ainsi possible de
construire une image de systèmes de fichiers de manière tout à fait transparente, et d’accéder aux
données stockées dans une image de CD-ROM de manière tout aussi facile.
Les fichiers spéciaux de périphérique utilisés pour manipuler les fichiers images sont les fichiers
/dev/loopX, où X est un numéro allant de 0 à 7. Ces fichiers ne sont utilisables que si l’option
« Loopback device support » du menu « Block devices » a été activée dans la configuration du
noyau.
L’association entre le périphérique de type bloc virtuel et le support des données peut être réalisée à
l’aide de la commande losetup. La syntaxe la plus simple de cette commande est la suivante :

losetup /dev/loopX fichier

où loopX est le fichier spécial de périphérique de type bloc virtuel à utiliser, et fichier est le fichier
dans lequel les données de ce périphérique doivent être stockées. Une fois cette association faite, on peut
utiliser ce périphérique comme un véritable périphérique. Ainsi, pour créer un système de fichiers dans
un fichier image de 10 Mo, on procédera comme suit :

dd if=/dev/zero of=image bs=1024 count=10240

146
 Chapitre 6. Administration du système de base

losetup /dev/loop0 image

mkfs -t ext2 /dev/loop0

Note : La commande dd permet de copier un certain nombre de blocs, ici 10240 (option count) de
1024 octets (taille indiquée par l’option bs) du fichier spécial de périphérique /dev/zero dans le
fichier image. Cette commande a déjà été présentée dans le chapitre d’installation pour réaliser une
copie du secteur de boot principal du disque dur.
En réalité, les commandes de création de systèmes de fichiers peuvent également créer directement
les systèmes de fichiers dans des fichiers images. La manière classique de procéder a toutefois été
présentée ici pour la bonne compréhension du mécanisme de gestion des fichiers images.

Le montage d’un système de fichiers placé dans l’image disque est ensuite réalisable de manière tout à
fait classique, en utilisant le fichier spécial de périphérique /dev/loopX adéquat dans la commande
mount. Toutefois, cette commande permet de réaliser le montage d’une image de manière simplifiée
grâce à son option loop. Celle-ci permet de configurer le périphérique virtuel image de manière
automatique avant de réaliser le montage. Elle prend donc en paramètre le fichier spécial de périphérique
virtuel à utiliser, ainsi que le chemin sur le fichier image contenant le système de fichiers. Ainsi, pour
monter une image de CD-ROM, vous pouvez utiliser la commande suivante :

mount -t iso9660 -o ro,loop=/dev/loop0 image /mnt/cdrom

Lorsque l’on n’a plus besoin du périphérique de type bloc virtuel, il est possible de supprimer
l’association avec le support de données simplement avec la commande suivante :

losetup -d /dev/loopX

où X est toujours le numéro du fichier spécial de périphérique virtuel. Lorsque l’on utilise l’option loop
de la commande mount, cette opération est réalisée automatiquement par la commande umount et ne
doit plus être effectuée manuellement.

Agrégation de volumes
Les agrégats de volumes de Linux permettent de construire un périphérique virtuel constitué d’un certain
nombre de volumes de données. Ceux-ci peuvent être regroupés pour réaliser un volume de grande taille,
ou mis en parallèle afin de répliquer les données sur plusieurs disques par exemple. Il est donc possible,
grâce à cette fonctionnalité, de regrouper plusieurs disques durs ou plusieurs partitions en une seule
partition logique, ou au contraire de subdiviser de manière fine des partitions ou des disques existants.
De même, il est possible de prendre en charge au niveau logiciel les fonctionnalités RAID normalement
disponibles uniquement avec du matériel spécialisé. Nous ne présenterons toutefois pas ces
fonctionnalités ici.
La réalisation des agrégats de volumes se fait à l’aide de l’outil dmsetup. Cet outil peut être récupéré sur
le site de Redhat ([Link] s’il n’est pas fourni avec votre distribution. Son

147
 Chapitre 6. Administration du système de base

installation se fait par compilation des sources, par exécution des commandes suivantes dans le répertoire
des sources :

./configure
make
make install

La principale commande de dmsetup est celle qui permet de créer un nouvel agrégat. Cela se fait
simplement grâce à l’option create :

dmsetup create agrégat définition

où agrégat est le nom de l’agrégat et définition est le nom d’un fichier contenant la définition de cet
agrégat. Si vous ne fournissez pas ce paramètre, dmsetup attendra que vous le définissiez en ligne de
commande.
La définition d’un agrégat se fait de manière générale à l’aide de plusieurs lignes, à raison d’une ligne
par composante de l’agrégat. Chaque ligne a la forme suivante :

début taille méthode arguments

début est le secteur de début de la plage de secteurs de l’agrégat qui seront stockés dans la composante.
taille est le nombre de secteurs de cette plage. méthode est la méthode d’agrégation utilisée, elle est
suivie par des options qui lui sont spécifiques. La méthode la plus classique est sans doute linear, qui
permet de stocker des données de l’agrégat dans les secteurs correspondants de la composante. Dans le
cas de la méthode linéaire, ces secteurs sont spécifiés simplement avec le nom du fichier spécial de
périphérique contenant les secteurs, et le numéro du premier secteur à partir duquel la composante sera
stockée.
Par exemple, pour créer un agrégat des deux partitions /dev/hda2 et /dev/hdb1, respectivement de
tailles 16579080 et 59665410 secteurs, il suffit d’utiliser les deux lignes suivantes :

0 16579080 linear /dev/hda2 0

16579080 59665410 linear /dev/hdb1 0

On constatera que le secteur de départ dans l’agrégat de la deuxième composante est le secteur suivant le
dernier secteur défini par la première composante. De manière générale, il n’est pas possible de définir
des trous dans un agrégat. La totalité des deux partitions est utilisée dans cet exemple, pour créer un
volume de taille totale 40 Go environ (pour rappel, un secteur de disque dur fait 512 octets, les deux
partitions de cet exemple font donc environ 8 et 32 Go).
Une fois l’agrégat créé, un fichier spécial de périphérique portant le nom de l’agrégat doit apparaître
dans le répertoire /dev/mapper/. Ce fichier spécial de périphérique peut être utilisé comme n’importe
quel fichier spécial de périphérique, pour y créer un système de fichiers, pour le monter et pour le
démonter. Par exemple, pour créer un agrégat group0 avec les définitions précédentes, il suffit
d’exécuter la commande suivante :

dmsetup create group0 [Link]

où [Link] est le fichier contenant les deux lignes définissant les composantes vues ci-dessus. La
création et le montage du système de fichiers se font ensuite avec les commandes suivantes :

148
 Chapitre 6. Administration du système de base

mke2fs /dev/mapper/group0
mount /dev/mapper/group0 /mnt/group

où /mnt/group/ est le nom du répertoire où le système de fichiers agrégé doit être monté.
Lorsqu’un agrégat n’est plus utilisé, il peut être supprimé à l’aide de l’option remove de dmsetup

dmsetup remove agrégat

Cela ne supprime bien entendu pas les données, mais détruit l’association entre les composantes de cet
agrégat.

Note : Les fonctionnalités d’agrégation de volumes ne sont disponibles que si les options
« Multiple devices driver support (RAID and LVM) », « Device mapper support » et
« Crypt target support » du noyau ont été activées dans le menu « Multi-device support (RAID
and LVM) » du programme de configuration du noyau.
dmsetup utilise le fichier spécial de périphérique /dev/mapper/control pour communiquer avec le
noyau. Vous devrez donc créer ce fichier si votre distribution ne le fournit pas. Pour cela, vous
pouvez exécuter le script devmap_mknot.sh fourni dans le répertoire scripts/ des sources de
dmsetup. Ce script permet également de créer le répertoire /dev/mapper/ si celui-ci n’existe pas.

Chiffrement des systèmes de fichiers

Il est possible de créer des systèmes de fichiers chiffrés afin de garantir la confidentialité des données qui
y sont stockées. Ces systèmes de fichiers sont chiffrés à la volée par le noyau avec des algorithmes de
chiffrement très puissants, que l’on paramètre avec une clef de chiffrement. Cette clef doit bien entendu
rester secrète, faute de quoi tout ce travail de chiffrement devient inutile. Le chiffrement et le
déchiffrement sont réalisés de manière complètement transparente par le noyau lors des accès aux
répertoires et aux fichiers du système de fichiers, qui apparaît donc en clair lorsqu’on l’utilise. La
différence est donc que le système de fichiers reste illisible pour tous les autres ordinateurs, ou pour tous
les autres utilisateurs s’ils n’ont pas la clef de décryptage et que le système de fichiers n’est pas monté
(rappelons que le mécanisme des droits Unix permet à un utilisateur d’interdire aux autres utilisateurs de
consulter ses données).
Pour créer un tel système de fichiers, il est nécessaire de créer un volume agrégé, et d’utiliser un
algorithme de chiffrement comme algorithme d’agrégation. Ceci se fait simplement en indiquant que les
composantes de l’agrégat utilisent la technique d’agrégation crypt. Cette technique est semblable à la
technique linear, à ceci près qu’elles permettent de chiffrer les données à la volée. L’algorithme de
chiffrement utilisé peut alors être spécifié et prendre en paramètre une clef privée, qui doit être fournie à
chaque fois que l’agrégat est redéfini, faute de quoi les données resteront indéchiffrables. Pour des
raisons de sécurité, un vecteur d’initialisation peut être utilisé afin de rendre plus difficiles les tentatives
de décryptage par la force brute. Ce vecteur d’initialisation est ajouté à la clef de chiffrement et permet
ainsi d’obtenir des données chiffrées différentes pour deux systèmes de fichiers même si les clefs
utilisées sont identiques. Dans l’implémentation actuelle, le vecteur d’initialisation utilisé est le numéro
du secteur chiffré, ce qui n’est pas la panacée étant donné que ce numéro est prédictible, mais c’est déjà
mieux que rien.

149
 Chapitre 6. Administration du système de base

La technique d’agrégation crypt prend en paramètre l’algorithme de chiffrement à utiliser, la clef privée
à utiliser pour chiffrer le volume agrégé, un décalage à ajouter au numéro du secteur pour déterminer le
vecteur d’initialisation, le fichier spécial de périphérique sur lequel les données chiffrées seront écrites, et
le numéro du secteur de ce périphérique à partir duquel les données seront écrites. Les décalages fournis
permettent de n’utiliser qu’une partie d’un périphérique de type bloc pour stocker les données chiffrées.
En général, ces valeurs seront nulles, car les données sont souvent stockées sur la totalité du périphérique
hôte.
Ainsi, la définition d’une composante de l’agrégat chiffré se fait selon la syntaxe suivante :

début taille crypt algorithme clef décalage périphérique origine

où début et taille définissent la composante dans l’agrégat, algorithme et clef l’algorithme de

chiffrement et la clef privée utilisée, décalage le décalage pour le vecteur d’initialisation,
périphérique le fichier spécial de périphérique dans lequel les données chiffrées devront être écrites,
et origine le secteur de départ dans ce périphérique à partir duquel les données seront écrites.
Les algorithmes utilisables sont les algorithmes de chiffrement inclus dans la configuration du noyau,
dont vous pourrez trouver la liste et les paramètres dans le fichier /proc/crypto. Pour chaque
algorithme de chiffrement, vous pouvez indiquer si vous désirez utiliser un vecteur d’initialisation ou
non en ajoutant un suffixe à leur nom. Le suffixe ecb signifie qu’il n’y a pas de vecteur d’initialisation, et
le suffixe plain signifie que le vecteur utilisé est le numéro de secteur. Bien entendu, vous devriez
utiliser plain, en attendant qu’une meilleure technique ne soit mise au point. Ainsi, le nom d’algorithme
des-plain indique que l’algorithme DES doit être utilisé avec un vecteur d’initialisation. La clef de cet
algorithme doit faire 64 bits (soit huit octets).
Une fois l’agrégat défini, celui-ci peut être accédé comme un périphérique de type bloc classique, via son
fichier spécial de périphérique dans le répertoire /dev/mapper/. La création du systèmes de fichiers se
fait de la même manière que pour les autres fichiers spéciaux de type bloc. Par exemple, pour chiffrer la
partition /dev/hda2 (dont la taille est supposée être de 10000000 blocs) avec l’algorithme AES, vous
devrez définir l’agrégat suivant :

0 10000000 crypt aes-plain clef 0 /dev/hda2 0

où clef est une clef de taille comprise entre 16 et 32 octets. Si cet agrégat a été nommée cr0, vous
pourrez ensuite créer le système de fichiers simplement avec la commande suivante :

mkfs -t ext2 /dev/mapper/cr0

et le monter dans le répertoire /mnt/secure/ avec une commande telle que celle-ci :

mount /dev/mapper/cr0 /mnt/secure

Enfin, il est possible d’utiliser un fichier en tant que périphérique de stockage des données chiffrées. Pour
cela, il faut associer ce fichier à un fichier de type bloc virtuel à l’aide de la commande losetup. Ce
fichier peut ensuite être utilisé pour définir un agrégat, comme n’importe quel autre fichier spécial de
périphérique.

150
 Chapitre 6. Administration du système de base

Configuration des terminaux virtuels

Un terminal est, comme son nom l’indique, un équipement qui se trouve au bout d’une connexion à un
ordinateur et qui permet de travailler sur l’ordinateur. Un terminal comprend généralement un clavier et
un écran (graphique pour les terminaux X), et parfois une souris. Initialement, les terminaux étaient des
périphériques passifs connectés sur un port série de l’ordinateur. Cette architecture permettait de partager
une même unité centrale avec plusieurs utilisateurs. De nos jours, la plupart des terminaux sont
simplement d’autres ordinateurs du réseau, qui se connectent à l’aide d’un programme que l’on appelle
« émulateur de terminal ». L’émulateur de terminal se contente de simuler un terminal réel et permet de
se connecter à toute machine gérant des terminaux clients. Du point de vue du système, tous les
utilisateurs sont connectés via des terminaux, qu’ils soient physiques ou émulés.
Les connexions locales sont donc réalisées par l’intermédiaire d’un terminal local, la console. La console
est tout simplement le périphérique prenant en charge le clavier et l’écran. Ce périphérique est géré
directement par le noyau, et émule un modèle de terminal standard, le VT102. En fait, la console n’est
utilisée directement en tant que terminal de login qu’en mode monoutilisateur (c’est-à-dire en mode
maintenance). En mode multi-utilisateur, la console est partagée entre plusieurs terminaux dits
« virtuels », parce qu’ils simulent la présence de plusieurs terminaux sur la même console. Ces
terminaux virtuels se partagent le clavier et l’écran, mais seulement un de ces terminaux peut accéder à
la console à chaque instant : celui qui traite les caractères saisis au clavier et qui réalise l’affichage. Pour
pouvoir passer d’un terminal virtuel à un autre, il faut utiliser une séquence de touches spéciale, comme
par exemple ALT+Fn (ou CTRL+ALT+Fn si vous êtes sous XWindow), où Fn est l’une des touches de
fonction du clavier. Si l’on utilise cette combinaison avec la touche F1, on accédera au premier terminal
virtuel. Avec la touche F2, ce sera le deuxième, avec F3, le troisième, etc.
Il est donc possible de simuler la présence de plusieurs écrans et claviers sur une même machine, ce qui
est très pratique lorsqu’on commence à lancer plusieurs programmes en même temps (cela nécessite
évidemment de se connecter plusieurs fois sur des terminaux différents). Bien entendu, la configuration
du clavier et la police de caractères utilisée sont communs à tous les terminaux virtuels, puisqu’ils
utilisent tous la même console.
La plupart des distributions utilisent au moins quatre terminaux virtuels, plus éventuellement un terminal
pour le serveur X. Mais il est possible de définir d’autres terminaux, qu’ils soient graphiques ou non.
Nous allons maintenant voir comment modifier le nombre de terminaux virtuels disponibles. L’utilisation
des terminaux avec XWindow sera traitée dans le chapitre traitant de la configuration de XWindow.
Chaque terminal virtuel utilise un fichier spécial de périphérique du répertoire /dev/. Le nom de ce
fichier commence toujours par « tty » et est complété par le numéro du terminal. Ainsi, le fichier spécial
de périphérique /dev/tty1 correspond au premier terminal virtuel, accessible avec la combinaison de
touches CTRL+ALT+F1, le fichier spécial de périphérique /dev/tty2 correspond au deuxième terminal
virtuel, etc. Linux peut gérer jusqu’à 64 terminaux virtuels, cependant, il est nécessaire de définir
d’autres combinaisons de touches pour accéder aux terminaux 13 et suivants (puisqu’il n’existe que 12
touches de fonctions). Il serait possible d’utiliser les combinaisons de touches ALT+DROITE et
ALT+GAUCHE pour les atteindre, mais d’une part ce ne serait pas très pratique, et d’autre part, vous ne
devriez pas avoir besoin de plus de quatre ou cinq terminaux virtuels. Nous n’utiliserons donc ici que les
douze premiers terminaux virtuels.
Les terminaux virtuels sont créés par le noyau à la demande, dès qu’un processus cherche à y accéder.
Ainsi, le système n’alloue les ressources utilisées pour la gestion de ces terminaux que lorsque cela est
nécessaire. Les terminaux peuvent être créés par différents processus, et leur emploi n’est pas restreint à
la simple connexion des utilisateurs. Par exemple, il est possible d’afficher un message sur un terminal

151
 Chapitre 6. Administration du système de base

simplement en écrivant dans son fichier spécial de périphérique. Ainsi, si vous tapez la commande
suivante sous le compte root :

echo Coucou > /dev/tty11

la chaîne de caractères « Coucou » devrait apparaître sur le terminal virtuel 11.

En général, les terminaux virtuels sont utilisés soit pour afficher les messages du système, soit pour
permettre aux utilisateurs de se connecter, soit pour XWindow. Les terminaux peuvent donc être attribués
à différents programmes, selon l’emploi qu’on leur réserve. Il faudra cependant bien prendre garde au
fait que les terminaux ne sont pas partageables entre tous les processus. Ainsi, on ne devra pas essayer de
lancer un serveur X sur un terminal utilisé par un processus de connexion en mode texte.
Pour créer des terminaux de login, il suffit de demander au système de lancer les processus de connexion
sur chaque terminal désiré. Ce travail est à la charge du processus fondamental du système : init. La
définition des terminaux de login se fait donc dans le fichier de configuration /etc/inittab. Si vous
regardez le contenu de ce fichier, vous trouverez quelques lignes semblables à la suivante :

[Link]respawn:/sbin/getty 9600 tty1 linux

[Link]respawn:/sbin/getty 9600 tty2 linux
etc.

Ces lignes indiquent à init que plusieurs processus getty doivent être lancés sur les différents terminaux
virtuels. Le programme getty est le programme qui vous demande votre nom d’utilisateur sur les
terminaux virtuels. Plus précisément, getty initialise le terminal, demande le nom d’utilisateur et lance le
programme login en lui fournissant le nom saisi, afin que celui-ci demande le mot de passe de cet
utilisateur.
Si vous désirez rajouter des terminaux de login à votre configuration, vous devrez donc rajouter des
lignes de ce genre dans le fichier /etc/inittab. En fait, ces lignes sont constituées de quatre champs :

• le premier champ est le numéro de la ligne. En pratique, ce numéro doit être celui du terminal virtuel
qui sera utilisé par getty ;
• le champ suivant (« 2345 ») contient les numéros des niveaux d’exécution dans lesquels cette ligne est
valide. Ces numéros doivent être spécifiés les uns à la suite des autres, sans séparateur. Dans l’exemple
donné ci-dessus, ces lignes sont valides dans les niveaux d’exécution 2 à 5 compris, c’est-à-dire tous
les niveaux d’exécution classiques ;
• le troisième champ indique à init des options pour le lancement du programme getty. Dans l’exemple
donné ci-dessus, le programme getty doit être relancé immédiatement dès qu’il se termine. Cela est le
comportement désiré, puisque la terminaison de getty correspond à la déconnexion de l’utilisateur
courant, et qu’il faut laisser la possibilité de se reconnecter aux suivants ;
• le dernier champ indique le programme à lancer et ses options de ligne de commande. Dans notre cas,
il s’agit de /sbin/getty. Les options indiquées sont la vitesse de la ligne de communication utilisée,
le nom du terminal sur lequel getty doit travailler et son type (ici, ce sont des terminaux de type
« linux »).
Vous pouvez bien entendu vous baser sur les lignes existantes pour en créer de nouvelles. L’opération est
très simple : il suffit de renuméroter les lignes et les terminaux virtuels utilisés. Prenez garde cependant à

152
 Chapitre 6. Administration du système de base

ne pas affecter à getty un terminal utilisé par XWindow. Il est recommandé d’effectuer ces modifications
dans le niveau d’exécution 2 pour ne pas être gêné par XWindow.
Une fois les modifications ajoutées, vous pourrez demander à init de relire son fichier de configuration
avec la commande suivante :

init Q

Dès lors, les nouveaux terminaux sont prêts à être utilisés.

Configuration de la console
Comme nous venons de le voir, tous les terminaux virtuels utilisent la même console. La suite logique
des opérations est donc de voir comment on réalise la configuration de celle-ci... Nous allons donc voir
dans ce chapitre la manière de paramétrer le clavier et l’affichage du texte à l’écran.
Pour cela, il est nécessaire de bien comprendre les mécanismes mis en œuvre pour le traitement des
codes émis par le clavier d’une part, et pour l’affichage des symboles des lettres à partir de leurs codes
d’autre part. Ces mécanismes sont relativement évolués et complexes, mais permettent de paramétrer
avec précision la disposition des touches du clavier, le comportement des applications et l’allure des
symboles affichés à l’écran.
Le plus simple pour comprendre le fonctionnement de la console est encore de voir les différentes étapes
entrant en ligne de compte de l’appui sur une touche jusqu’à l’action correspondant à cet appui. Notez
bien que cette action n’est pas forcément l’affichage d’une lettre à l’écran : cela dépend de l’application
qui a traité l’événement correspondant à l’appui sur la touche. Il est toutefois nécessaire de présenter
auparavant quelques notions sur la manière dont les caractères sont représentés dans les programmes.

Pages de codes et Unicode

De par leur nature de calculateurs, les ordinateurs n’ont jamais été conçus pour manipuler nativement du
texte. Cela signifie qu’ils n’ont aucune notion de caractère ou de symbole : pour eux, tout est numérique.
Par conséquent, il a fallu trouver le moyen de représenter les caractères humains sous une forme
numérique afin de pouvoir réaliser des programmes de manipulation de texte. Cette représentation est
effectuée en associant à chaque caractère un numéro donné, t en travaillant directement sur ces numéros.
Par exemple, le caractère ’A’ est classiquement représenté par le nombre 65, la lettre ’B’ par le nombre
66, etc. L’opération consistant à effectuer cette association sur chaque caractère d’un texte constitue ce
que l’on appelle l’encodage du texte. Plusieurs manière de réaliser cet encodage ont été inventées, mais
l’un des standards les plus utilisés est l’encodage ASCII. Lorsqu’il a été créé, l’encodage ASCII codait
les caractères sur 7 bits. Depuis, il a été étendu pour utiliser 8 bits, ce qui fait que chaque caractère est
dorénavant codé sur un octet. Ainsi, il est possible de représenter 256 caractères différents avec un octet,
ce qui est suffisant pour toutes les langues occidentales.
Cependant, le standard ASCII initial ne spécifiait que l’encodage des caractères utilisés en anglais, tout
simplement parce que les Américains parlent anglais. Évidemment, cela ne convenait pas pour les pays
qui utilisent des lettres accentuées, c’est-à-dire pour quasiment tout le monde. Il a donc fallu définir
d’autres conventions que celle initialement utilisée, afin d’associer des codes numériques aux caractères

153
 Chapitre 6. Administration du système de base

utilisés par les autres pays. Ces conventions constitue ce que l’on appelle une page de codes. Chaque
pays est donc susceptible d’utiliser une page de codes qui lui est spécifique. Par exemple, la page de
codes 437 représente l’encodage utilisé aux États-Unis, et la 850 celle utilisée en France.
Historiquement, les pages de codes n’ont pas été immédiatement standardisées, ce qui a conduit à la
prolifération de pages différentes et parfois incompatibles. Ainsi, les pages de codes utilisées en France
sont les pages de codes 850 sous DOS, 1252 sous Windows, ISO 8859-1 et ISO 8859-15 sous Unix. Ces
deux dernières constituent la norme actuelle, et sont celles qui doivent être utilisées de préférence. La
norme ISO 8859-1 est également connue sous le nom latin-1, et la norme ISO 8859-15 sous le nom
latin-0. La norme latin-0 est une extension de la latin-1, qui ne prévoyait pas le codage de certains
caractères européens (comme le o e dans l’o français) et le symbole de l’Euro.
Le défaut majeur de l’ASCII et de ses dérivés est de travailler sur des nombres à 8 bits. Si le nombre de
256 caractères différents convient pour la plupart des pays occidentaux, ce n’est pas le cas de quelques
autres pays, qui utilisent un nombre de symboles de très loin supérieur à 256. C’est notamment le cas du
Japon et de la Chine, qui ne peuvent pas encoder tous leurs idéogrammes sur des nombres à 8 bits. Il a
donc fallu introduire d’autres types d’encodages, plus riches, permettant de satisfaire aux besoins de tout
le monde.
Après des tentatives infructueuses d’encodages à taille variable (un ou plusieurs octets selon le caractère
codé), Unicode a été introduit et normalisé sous le nom ISO 10646. Unicode est une convention de
codage universelle des caractères, qui utilise pour cela des nombres 32 bits (il existe également une
version plus ancienne qui n’utilise que 16 bits). Chaque caractère est représenté par un nombre et un
seul, comme pour l’ASCII. Cependant, avec ses 16 ou 32 bits, le jeu de caractères Unicode est
suffisamment large pour coder tous les caractères de toutes les langues du monde. Bien entendu, tous les
codes ne sont pas utilisés, et le jeu de caractère Unicode est discontinu. Pour des raisons de
compatibilité, les 256 premiers caractères Unicode sont les mêmes que ceux définis dans la norme ISO
8859-1 (ce qui rend malheureusement non compatible la norme ISO 8859-15, plus complète). Les autres
caractères sont affectés à d’autres plages de codes, qui sont parfaitement définies. Ainsi, l’utilisation
d’Unicode permettra, à terme, de n’avoir plus qu’une seule page de codes pour tous les pays.
Malheureusement, Unicode est une évolution relativement récente, et la plupart des programmes
travaillent encore avec des caractères 8 bits, ce qui rend l’utilisation d’Unicode prématurée. Linux, quant
à lui, est capable de gérer l’Unicode. Cependant, pour des raisons d’économie de place, il ne l’utilise pas
directement. Il préfère en effet utiliser l’encodage UTF-8 (abréviation de l’anglais « Unicode Tranfer
Format »). Cet encodage est un encodage à taille variable, qui permet d’encoder les caractères Unicode
avec de un à six octets selon leur emplacement dans la page de codes Unicode.

Principe de fonctionnement du clavier

En général, les claviers envoient une série de codes à l’unité centrale lorsqu’on appuie sur une touche.
Certaines touches génèrent un seul code, d’autres peuvent en produire jusqu’à une dizaine. Ces codes,
que l’on appelle scancode, sont récupérés par le pilote du clavier dans le noyau de Linux, et constituent
le début du traitement des saisies clavier. Les scancodes permettent normalement de déterminer avec
certitude l’événement qui s’est produit, pour peu que l’on connaisse parfaitement le type de clavier
utilisé. Malheureusement, ils sont spécifiques à chaque modèle de clavier, et il est difficilement
concevable pour un programme de prendre en charge les particularités de tous les claviers existants. De
plus, qui peut prévoir aujourd’hui combien de touches les claviers du futur auront, et quels scancodes
ceux-ci utiliseront ?

154
 Chapitre 6. Administration du système de base

Linux effectue donc un travail d’uniformisation en interprétant les scancodes et en les traduisant en
d’autre codes, les keycodes. Ces codes sont toujours les mêmes, quel que soit le clavier utilisé. Les
keycodes simplifient le traitement des données provenant du clavier en définissant un code de touche
unique à chacune des touches du clavier. Les keycodes sont également souvent appelés les codes de
touches virtuelles, car ils correspondent aux scancodes d’un clavier virtuel uniforme et commun à toutes
les plates-formes. La gestion des événements clavier par l’intermédiaire des keycodes est donc beaucoup
plus aisée, car il n’y a plus à se soucier ici que de ce clavier virtuel. La correspondance entre les
scancodes, donc les touches physiques, et les keycodes, ou codes de touches virtuelles, est définie dans le
pilote du clavier. La plupart des claviers courants sont pris en charge et, en général, peu de personnes ont
besoin de modifier ce type d’information. Toutefois, afin de permettre l’intégration des claviers futurs, il
est possible de compléter la table de conversion des scancodes en codes de touches virtuelles.
L’interprétation des keycodes est une opération relativement compliquée et peu commode à cause du
grand nombre de dispositions de clavier existantes et, pour chaque type de clavier, des différentes
déclinaisons existantes en fonction des langages des divers pays qui les utilisent. C’est pour cela qu’une
autre association, qui permet de définir le comportement à obtenir pour chaque combinaison de codes de
touches virtuelles, a été introduite. Cette correspondance est décrite dans un fichier que l’on appelle
couramment le plan de clavier (ou keymap en anglais). Les keymaps contiennent donc, pour chaque
touche ou combinaison de touches virtuelles utilisée, la définition d’une action à effectuer ou d’un code
de caractère à renvoyer. Ces codes sont renvoyés en ASCII, codés selon la page de codes définie dans le
plan de clavier. Cependant, certaines touches ne sont pas associées à une lettre ASCII et ne peuvent donc
pas être représentées par des codes simples. C’est le cas, par exemple, des touches du curseur et des
touches de suppression du clavier. Ces touches sont donc signalées aux programmes à l’aide de
séquences de codes appelées les codes d’échappement. Les codes d’échappement sont en réalité des
séquences de codes ASCII dont le premier est le code du caractère d’échappement Escape (dont le
numéro est 27, quelle que soit la page de codes utilisée). Ces séquences sont donc utilisées typiquement
pour signaler aux programmes qui les lisent qu’un traitement particulier doit être effectué, comme par
exemple le déplacement du curseur.

Figure 6-1. Traitements des entrées clavier

155
 Chapitre 6. Administration du système de base

Les programmes peuvent peuvent travailler à n’importe lequel des trois niveaux de traitement que l’on
vient de décrire. Les programmes qui récupèrent directement les scancodes travaillent en mode raw (ce
qui signifie en anglais que les données sont « brutes »). Ils n’utilisent donc pas la traduction en codes de
touches virtuelles et doivent nécessairement connaître les caractéristiques physiques des claviers qu’ils
veulent supporter. C’est le cas par exemple des serveurs X. Les programmes qui utilisent les keycodes
travaillent dans le mode nommé medium raw ou keycode. Cependant, la plupart des programmes
travaillent avec les codes issus du plan de clavier, qui sont normalisés et font bénéficier d’une plus
grande portabilité (y compris avec d’autres systèmes Unix que Linux). Dans ce cas, on dit qu’ils
travaillent en mode ASCII, ou xlate (abréviation de l’anglais « translate », ce qui signifie « traduction »).

Note : En fait, la console peut également travailler en Unicode, dans le mode UTF-8. Ce mode
permet de travailler directement en Unicode, si vous le désirez. Cependant, vous devrez vous
assurer dans ce cas que tous les programmes que vous utilisez sont capables de fonctionner avec
un encodage à taille variable.

Dans tous les cas, les programmes lisent les données provenant du clavier sur la console, par
l’intermédiaire du fichier spécial de périphérique /dev/console. En fait, ces programmes ne savent pas
qu’ils lisent les données du clavier local. Pour eux, ces données semblent provenir d’un terminal VT102,
et ils traitent ces données comme celles provenant de n’importe quel terminal. Cela signifie que ces
données semblent provenir d’une ligne de communication, à laquelle le terminal local est connecté. Et
qui dit ligne de communication, dit paramètres de transmission des informations sur la ligne ! Les
caractères issus de la keymap peuvent donc subir un traitement supplémentaire, en fonction des
paramètres de la ligne de communication (virtuelle) utilisée par la console. Cependant, il n’est en général
pas nécessaire de modifier ces paramètres, puisque la ligne de communication utilisée est bien entendue
idéale (quitte à être virtuelle, autant être idéale, non ?).
Gloups !? Que c’est compliqué ! C’est effectivement la réflexion que vous êtes en droit de vous faire.
Cependant, si l’on prend un peu de distance par rapport à ce mécanisme en trois passes, on comprend son
intérêt. Premièrement, la contrainte initiale est la complexité des scancodes. Sur ce point, il n’y a rien à
dire. Grâce aux keycodes, il n’est plus nécessaire de se soucier du modèle de clavier utilisé. Ensuite,
grâce aux keymaps, il est possible de faire l’association entre les keycodes et les lettres écrites sur les
touches du clavier. Ainsi, la disposition du clavier, ainsi que les raccourcis claviers, peuvent être
complètement paramétrés. Enfin, les applications qui gèrent les touches spéciales du clavier peuvent
interpréter les codes d’échappement, qui sont ceux renvoyés par le terminal de la console. Dans tous les
cas, les programmes qui lisent les données du clavier considèrent que ces données proviennent d’un
terminal classique. Ils n’ont donc pas besoin de faire des hypothèses sur l’origine des données, et leur
programmation en est d’autant plus simple.
Passons maintenant aux travaux pratiques. La commande kbd_mode permet de déterminer le mode de
fonctionnement du clavier. Si vous l’essayez à partir d’une console, vous verrez que le clavier est en
mode ASCII. Inversement, si vous tapez cette commande à partir d’une session X, vous constaterez que
XWindow utilise le clavier en mode raw, et gère donc les scancodes lui-même. Vous pouvez également
visualiser les codes renvoyés dans les trois modes de fonctionnement du clavier avec la commande
showkey. Lancée avec l’option -s, elle permet d’afficher les scancodes lors de l’appui sur chaque
touche. Vous pourrez constater que toutes les touches ne renvoient pas le même nombre de codes. Vous
pourrez utiliser l’option -k pour visualiser les keycodes renvoyés par le noyau lors de l’appui et du
relâchement des touches. Enfin, si vous utilisez l’option -a, vous verrez les codes de touches ASCII.
Vous pourrez constater que les touches spéciales renvoient des séquences de codes d’échappement.

156
 Chapitre 6. Administration du système de base

Note : Notez également que certaines touches renvoient des caractères de contrôle (notés ^A à ^Z).
Ces caractères correspondent en fait aux codes ASCII allant de 1 à 26 et ne sont pas des
séquences d’échappement. Ils peuvent également être générés avec les combinaisons de touches
CTRL+A à CTRL+Z. Si vous ne me croyez pas, tapez la commande ls dans une console et tapez la
combinaison de touches CTRL+M (celle affectée à la touche Entrée). Vous verrez, c’est comme si
vous aviez tapé Entrée !
Le programme showkey ne peut pas être lancé sous XWindow, parce que celui-ci gère lui-même le
clavier. showkey se termine de lui-même au bout de dix secondes après la dernière frappe, ou lors
de l’appui de la séquence de touches CTRL+D s’il est en mode ASCII.

Principe de fonctionnement de l’écran de la console

Il est temps maintenant de passer au mécanisme d’affichage des caractères sur l’écran. Comme vous avez
pu le voir dans les paragraphes précédent, le fait d’appuyer sur une touche ne fait rien d’autre que de
fournir des codes numériques aux programmes. Contrairement à ce que vous pourriez penser, les codes
de ces touches ne sont pas forcément transmis directement à l’écran (heureusement, comment
taperiez-vous votre mot de passe à l’abri des regards indiscrets sinon ?). En fait, l’affichage des
caractères à l’écran est un des paramètres de la ligne du terminal, que l’on nomme echo. Pour la plupart
des programmes, l’écho automatique est désactivé. Pour d’autres ce sont les applications qui, en fonction
des codes qu’elles lisent sur la console, effectuent une action. Mais la majorité de ces actions nécessitent
effectivement d’afficher des résultats sur le moniteur. Pour réaliser cela, les programmes écrivent les
données à afficher dans le fichier spécial de périphérique de la console.
Comme nous l’avons vu, la console de Linux se comporte comme un terminal local. Cela implique que
les applications qui désirent écrire des données doivent les envoyer par la ligne de communication via
laquelle elles sont connectées à ce terminal. Tout comme les scancodes du clavier, les caractères envoyés
à la console par les applications subissent un traitement imposé par les paramètres de la ligne de
communication virtuelle utilisée. Bien entendu, ce traitement est encore une fois minimal, puisque cette
ligne est idéale. Notez que les programmes n’en savent absolument rien car, pour eux, tout se passe
comme s’ils écrivaient sur un terminal réel. Quoi qu’il en soit, le flux de caractères arrive au niveau du
gestionnaire de la console après ce traitement de base.
Comme nous l’avons déjà dit plus haut, la console Linux émule un terminal VT102, et recherche donc
les codes de contrôle et les séquences d’échappement de ces consoles. Ces codes d’échappement sont
classiquement utilisés pour effectuer des opérations sur la console, comme par exemple le déplacement
du curseur, la prise en compte de la couleur et des attributs des caractères affichés, l’effacement de
l’écran, etc. Pour information, tous les codes de la console sont décrits dans la page de manuel
console_codes.

Les codes qui ne sont pas reconnus comme étant des codes d’échappement sont traités en tant que
caractères normaux. Le gestionnaire de la console doit donc déterminer quel caractère doit être imprimé
à l’écran pour chaque code fourni par l’application. Cela n’est pas une opération facile, parce que les
polices de caractères, qui contiennent la définition de la représentation graphique des caractères,
n’utilisent pas forcément la page de codes active dans le système. Cela signifie que les caractères définis
dans la police n’apparaissent pas forcément dans le même ordre que celui de la page de codes, et pour
cause : une police peut parfaitement être utilisable dans plusieurs pays différents ! Cela complique donc

157
 Chapitre 6. Administration du système de base

un peu plus les choses, puisqu’il faut utiliser une table de conversion entre la page de codes du texte à
afficher et l’encodage propre de la police.
Afin de réaliser cette conversion, le gestionnaire de la console Linux commence par convertir tous les
caractères qu’il reçoit en « Unicode ». Si la console est en mode UTF-8, cette opération est immédiate,
car l’UTF-8 est un encodage Unicode. En revanche, si la console est en mode ASCII, cette opération
nécessite l’emploi d’une table de conversion. Linux dispose de quatre tables de conversion :

• la première table permet de faire la conversion entre la page de codes ISO 8859-1 et Unicode (cette
conversion est, par définition, immédiate) ;
• la deuxième table permet de faire la conversion entre les codes graphiques des terminaux VT100 et
Unicode ;
• la troisième table permet d’effectuer la conversion entre la page de codes 437 et Unicode ;
• et la quatrième et dernière table est réservée à l’usage personnel de l’utilisateur.

La dernière table est très utile, car elle permet de définir une nouvelle table de conversion si nécessaire.
Par défaut, elle convertit les codes reçus en codes Unicode spéciaux, qui représentent les codes utilisés
par la police de caractères chargée. Ainsi, lorsque cette table est utilisée, les codes reçus par la console
seront utilisés directement pour localiser les caractères dans la police de caractères. Cela ne peut
fonctionner que si les applications utilisent le même encodage que la police de caractères courante.
Linux dispose de deux jeux de caractères, nommés respectivement G0 et G1, qui permettent de
sélectionner la table de conversion à utiliser. Par défaut, ces jeux de caractères pointent respectivement
sur la première et la deuxième table de conversion, mais cela peut être modifié à l’aide de codes
d’échappement. Seul un jeu de caractères est actif à un moment donné. Par défaut, il s’agit du jeu G0, ce
qui implique que la table de conversion utilisée par défaut est la table ISO 8859-1 vers Unicode. Il est
également possible de changer de jeu de caractères, à l’aide d’un code de contrôle. Ce mécanisme ne
sera pas décrit plus en détail ici, car il ne nous sera pas utile.

Note : En fait, la recherche des codes de contrôle est effectuée a posteriori, après la conversion en
Unicode.

Dans tous les cas, les codes envoyés par l’application sont donc convertis en Unicode (16 bits). Ils
peuvent donc être reconvertis aisément dans l’encodage utilisé par la police de caractère chargée en
mémoire vidéo. Par défaut, cette opération est triviale, et l’encodage cible est donc l’encodage ISO
8859-1, sauf si la quatrième table de conversion a été utilisée. Dans ce cas en effet, l’encodage cible est
le même encodage que celui utilisé par l’application (tout se passe donc comme si rien ne s’était passé).
Enfin, la dernière opération est tout simplement l’écriture du code dans la mémoire vidéo. Ce code est
utilisé par la carte graphique comme index dans la police de caractère, et le caractère ainsi localisé est
affiché.

158
 Chapitre 6. Administration du système de base

Figure 6-2. Traitement des caractères pour l’affichage

Gloups !? Que c’est compliqué ! Ça ne va pas recommencer ? Eh si ! Mais, encore une fois, ce
mécanisme permet de rendre indépendant les applications des polices de caractères. Chacun peut utiliser
l’encodage qu’il désire, et grâce à un petit passage en Unicode, tous les caractères finissent par être
représentés par le bon symbole à l’écran... En fait, le passage par Unicode donne la possibilité de définir
les tables de conversion des polices uniquement par rapport à Unicode, et non par rapport à tous les
encodages possibles que les applications peuvent utiliser. Cela permet donc l’utilisation de polices de
caractères diverses et variées, sans avoir à modifier les applications.

Configuration du clavier
Bien que les distributions modernes fournissent les outils nécessaires à la configuration correcte du
clavier, vous aurez peut-être à intervenir pour le personnaliser selon vos propres désirs. La configuration
du clavier comprend la définition des scancodes, la définition du plan de clavier, et le réglage de la
vitesse de répétition et de la touche de verrou numérique.

Définition de scancodes
La définition des scancodes est une opération qui nécessite une bonne connaissance du fonctionnement
du clavier des PC. Heureusement, rares sont les personnes qui disposent de claviers non standards,
c’est-à-dire, en pratique, de claviers disposant de plus de 105 touches. Notez que Linux reconnaît
parfaitement les touches « Windows » qui ont été introduites par Microsoft, et il n’y a donc pas lieu de
définir leurs scancodes. Cependant, les claviers les plus récents disposent de touches « Internet » ou
« Multimedia », qui ne sont pas encore reconnues par Linux en standard. L’utilisation de ces touches se
traduit donc simplement par un message d’erreur dans les traces systèmes. Si vous disposez d’un tel
clavier, et que vous désirez utiliser ces touches, vous allez devoir les définir dans la table des scancodes
du noyau.

159
 Chapitre 6. Administration du système de base

Pour réaliser cette opération, il faut avant tout déterminer les scancodes envoyés par le clavier lors de
l’appui sur la touche à définir. Comme nous l’avons indiqué plus haut, les scancodes peuvent être
visualisés avec l’option -s de showkey :

showkey -s

Les scancodes sont exprimés en hexadécimal, c’est-à-dire en base 16. Dans cette base, les lettres A à F
représentent les chiffres manquants à la base 10, c’est-à-dire les chiffres ayant respectivement pour
valeur 10, 11, 12, 13, 14 et 15.
En général, le clavier envoie un scancode lors de l’appui sur une touche, puis le même scancode
augmenté de 128 lors de son relâchement. Le nombre de 128 provient du fait que le bit de poids fort du
scancode est mis à un lors du relâchement de la touche. Ainsi, la touche ’A’ des claviers français renvoie
le scancode 16 lors de l’appui, soit 0x10 en hexadécimal, et le scancode 144, soit 0x90, lors du
relâchement (notez que la valeur 128 se note 0x80 en hexadécimal, et que l’on a bien 0x90 = 0x10 +
0x80).
Cependant, certaines touches renvoient des scancodes plus complexes. Ces touches sont généralement
des touches qui ont été ajoutées après la définition des premiers claviers PC, et qui ont sensiblement le
même rôle qu’une touche déjà présente. C’est exactement le cas de la touche CTRL de droite par rapport
à la touche CTRL de gauche. Pour cette raison, les scancodes de ces touches sont les mêmes que ceux de
certaines touches « classiques », mais ils sont précédés du préfixe 0xE0, qui indique qu’il s’agit d’une
touche étendue. Par exemple, la touche CTRL de gauche (c’est-à-dire la première touche de contrôle qui
ait été utilisée) utilise le scancode 0x1D à l’appui, et le scancode 0x9D au relâchement. La touche CTRL
de droite renvoie donc la séquence suivante à l’appui :

0xE0 0x1D

et la séquence suivante au relâchement :

0xE0 0x9D

L’intérêt de procéder ainsi est que les vieux programmes, incapables de gérer les codes de touches
étendus, ignoraient purement et simplement le code 0xE0. Ainsi, ils confondaient les deux touches CTRL,
ce qui est le comportement désiré.
D’autres touches étendues utilisent des séquences de scancodes variables. Par exemple, les touches du
curseur (entre la touche Entrée et le pavé numérique) ont été ajoutées pour simplifier le déplacement du
curseur à l’écran. Initialement, on n’utilisait que les touches du pavé numérique, en combinaison de la
touche Majuscule de droite si le verrou numérique était enclenché. Par conséquent, la séquence de
scancodes générée lors de l’utilisation de la touche Flèche Haute du pavé numérique était 0x48 si le
verrou numérique n’était pas enclenché, et 0x2A 0x48 sinon (soit le scancode de la touche Majuscule
de gauche suivi du scancode de la touche 8 du pavé numérique). Lors du relâchement, la séquence était
inversée (et augmentée de 128) : 0xC8 ou 0xC8 0xAA selon l’état du verrou numérique. La touche
Flèche Haute étendue renvoie donc deux séquences de scancodes différents selon l’état du verrou
numérique 0xE0 0x48 ou 0xE0 0x2A 0xE0 0x48.

160
 Chapitre 6. Administration du système de base

Lors du relâchement, la séquence suivante complexe 0xE0 0xC8 ou 0xE0 0xC8 0xE0 0xAA est émise
selon l’état du verrou numérique. Notez que l’état du verrou numérique est maintenu en interne par
l’électronique du clavier, indépendamment de l’état de la diode lumineuse du verrou numérique. Celui-ci
peut en effet être enclenché sans que la diode soit allumée, si le programme de gestion du clavier ne
synchronise pas le clavier et sa diode.
Enfin, pour couronner le tout, certaines touches spéciales utilisent une séquence de scancodes
spécifiques. Par exemple, la touche Pause ne renvoie que la séquence 0xE1 0x1D 0x45 0xE1 0x9D
0xC5 à l’appui. Elle utilise donc le préfixe 0xE1 au lieu de 0xE0, et simule l’appui et le relâchement
immédiat des touches CTRL + Verrou Numérique (ce qui était la manière de provoquer la pause
avant l’introduction de la touche Pause).
Comme vous pouvez le constater, tout cela est très compliqué. Heureusement, le noyau fait le ménage
pour vous et élimine les touches suivantes :

• les touches non étendues sont traitées immédiatement (scancodes 0x01 à 0x58) ;
• la touche Pause est gérée automatiquement ;
• les codes 0x2A et 0xAA de la touche Majuscule de droite sont automatiquement éliminés.
Grâce à ce traitement, les seuls scancodes que vous manipulerez sont les scancodes simples non connus,
et les scancodes précédés du préfixe 0xE0.
L’association d’un scancode inconnu à un keycode se fait à l’aide de l’utilitaire setkeycodes. Sa syntaxe
est la suivante :

setkeycodes scancode keycode

où scancode est le numéro du scancode, exprimé en hexadécimal et sans le préfixe « 0x », et keycode

est bien entendu le numéro de keycode à attribuer à cette touche. Les numéros de scancodes peuvent être
simples (par exemple 48) ou précédés de leur préfixe (par exemple E048). Les numéros de keycodes
doivent être exprimés en décimal, et doivent être compris entre 1 et 127.
Par exemple, mon clavier dispose de 12 touches « Multimédia » supplémentaires, dont les scancodes ne
sont pas reconnues par le noyau. La touche Arrêt du son générant les scancodes suivants à l’appui :

0xE0 0x20

je peux lui associer le keycode 119 avec la commande suivante :

setkeycodes E020 119

Il va de soi qu’il faut s’assurer que chaque keycode n’est utilisé qu’une fois (à moins, bien entendu, de
vouloir que plusieurs touches aient le même comportement). Pour cela, vous aurez sans doute besoin de
voir les correspondances entre scancodes et keycodes. La commande suivante vous donnera la liste de
ces correspondances :

getkeycodes

161
 Chapitre 6. Administration du système de base

Les keycodes sont présentés à raison de huit par ligne. Le scancode de la touche décrite par le premier
élément de chaque ligne est affiché en tête de la ligne. Les autres scancodes peuvent être déduits en
ajoutant le numéro de la colonne dans laquelle se trouve chaque keycode au numéro du scancode du
premier keycode.

Définition d’un plan de clavier

Comme nous l’avons expliqué dans les paragraphes précédents, les plans de clavier définissent les
associations entre les keycodes et les caractères ou les séquences d’échappement renvoyés par le clavier.
Les plans de clavier permettent également de définir des séquences de composition, afin d’obtenir de
nouveaux caractères en composant les actions de plusieurs touches.
La définition d’un plan de clavier est donc constituée de trois parties. La première partie décrit les
symboles accessibles pour certaines touches du clavier. Par exemple, les symboles accessibles pour la
touche A peuvent être les caractères ’a’, ’A’, ’æ’ et ’Æ’, à l’aide des touches de majuscule et AltGr. La
deuxième partie permet d’affecter des chaînes de caractères à certaines touches particulières. Cette partie
peut contenir par exemple la définition de touches de raccourci pour les commandes les plus utilisées. En
pratique cependant, elles sont souvent utilisées pour définir des séquences d’échappement pour les
touches de fonction et les touches du curseur, séquences qui seront interprétées ensuite par les
applications. Enfin, la dernière partie permet de définir les compositions de touches pour obtenir des
caractères qui n’auraient été accessibles autrement que par des combinaisons de touches compliquées.
Pour chaque touche normale du clavier, il est possible de définir jusqu’à 256 symboles différents. Ces
symboles sont sélectionnés grâce à des touches de modification du comportement de base des autres
touches, comme par exemple la touche Ctrl ou la touche Alt Gr. Linux est capable de gérer des
combinaisons de touches faisant intervenir jusqu’à huit touches de modification différentes en plus de la
touche affectée (remarquez qu’avec dix doigts, on peut encore y parvenir !). Ces touches sont
récapitulées dans le tableau suivant :

Touche de Valeur Description

modification
Shift 1 Touches de passage en majuscule (situées au dessus des touches
Ctrl sur les claviers français).
altgr 2 Touche Alt Gr, située à droite de la barre d’espacement.
control 4 Touches Ctrl, situées aux extrémités inférieures du clavier.
alt 8 Touche Alt, située à gauche de la barre d’espacement.
shiftl 16 Touche de majuscule de gauche.
shiftr 32 Touche de majuscule de droite.
ctrll 64 Touche Ctrl de gauche.
ctrlr 128 Touche Ctrl de droite.

Chaque touche dispose d’un code numérique qui est une puissance de deux. Lorsqu’elles sont utilisées
dans une combinaison avec une touche donnée, la somme de ces valeurs est calculée pour déterminer le
numéro du symbole dans la liste des symboles associés à la touche. Comme on peut le voir, toutes les
valeurs possibles allant de 0 à 255 sont réalisables selon la combinaison de touches utilisée, ce qui
permet donc de définir effectivement 256 symboles différents pour chaque touche du clavier.

162
 Chapitre 6. Administration du système de base

Cependant, les touches Shift et Ctrl sont utilisées plusieurs fois dans le tableau, précisément trois fois,
la première ne faisant pas de distinction entre la touche de droite et la touche de gauche. En pratique
donc, toutes les combinaisons ne sont pas réalisables. Mais en réalité, les touches de contrôle du clavier
sont des touches comme les autres, et peuvent être placées n’importe où dans le plan de clavier. Il est
donc parfaitement possible de réaliser une distinction entre les touches Majuscule, Majuscule
Droite et Majuscule Gauche (et de même pour les touches Ctrl). Par exemple, on peut associer la
touche Majuscule à la touche Echap, ce qui permet de faire la distinction entre les trois variantes de
touches de majuscules... Heureusement, il n’est pas nécessaire d’aller jusque là. Les plans de clavier
n’utilisent en pratique que les quatre premières touches de contrôle, qui sont celles que vous connaissez.
La définition des symboles accessibles pour une touche utilise la syntaxe suivant :

keycode = symbole symbole symbole ...

où keycode est le keycode qui identifie la touche en question, et symbole est un des symboles acceptés
dans les plans de clavier. Vous pourrez obtenir la liste des symboles utilisés grâce à la commande
suivante :

dumpkeys --long-info

Vous pourrez voir par exemple les symboles A, B, C, etc. qui représentent les lettres classiques, ainsi que
des symboles spéciaux comme exclamdown, hyphen, cedilla, etc. pour les lettres non alphabétiques.
Il existe également des symboles pour les touches spéciales comme Backspace, Delete, Escape.
Enfin, le symbole VoidSymbol permet de signaler l’absence de symbole pour la combinaison de touches
considérée.
En théorie, il faut définir la liste des 256 symboles accessibles pour chaque touche. Le premier symbole
est donc le symbole obtenu par appui direct de la touche, le deuxième est celui obtenu par la
combinaison Majuscule + Touche, le troisième celui de la combinaison AltGr + Touche, le
quatrième par Majuscule + AltGr + Touche, etc. Évidemment, il est très fastidieux de définir ces
256 possibilités. Pour simplifier le format des plans de clavier, il est possible de ne spécifier que les
combinaisons utilisées, ce qui réduit en pratique à quatre colonnes de symboles un plan de clavier
français. De plus, les derniers symboles sont facultatifs s’ils sont tous VoidSymbol. Vous pouvez
indiquer au début du plan de clavier les valeurs des combinaisons de touches de modifications qui seront
effectivement utilisées avec la syntaxe suivante :

keymaps valeurs

où valeurs est la liste des valeurs ou des plages de valeurs des combinaisons de touches utilisées. Les
éléments de cette liste sont séparés par des virgules, et les plages de valeurs sont indiquées par leurs
première et dernière valeurs, séparées par un tiret.
Vous pouvez également utiliser une autre syntaxe, qui permet de ne modifier que les symboles associés à
certaines combinaisons de touches. Cette syntaxe est très utile lorsque vous ne désirez modifier que
quelques affectations de touches :

modificateur keycode = symbole

163
 Chapitre 6. Administration du système de base

Dans cette syntaxe, modificateur est la liste des modificateurs devant intervenir dans la combinaison
de touches, et keycode et symbole sont toujours le keycode de la touche et le symbole à générer. Les
modificateurs autorisés sont les noms des touches de modification indiquées dans le tableau ci-dessus,
plus le modificateur plain, qui signifie qu’aucune touche de modification n’est utilisée. Par exemple, la
ligne suivante :

plain keycode 16 = q

permet d’affecter le symbole q à la touche A de votre clavier, et la ligne :

alt keycode 30 = a

permet d’affecter le symbole a à la combinaison de touches Alt + Q (n’essayez surtout pas ces deux
exemples, vous deviendriez fou).

Note : Par défaut, les symboles utilisables dans les plans de clavier sont les symboles du jeu de
caractères ISO 8859-1. D’autres encodages sont utilisables, mais celui-ci convient parfaitement pour
un clavier français.

Comme nous l’avons dit plus haut, la deuxième partie d’un plan de clavier permet d’affecter des chaînes
de caractères à certaines touches. Cela est facilement réalisable, avec la syntaxe suivante :

string symbole = "chaîne"

où symbole est le nom d’un des symboles affecté précédemment à une touche, et chaîne est une chaîne
de caractères. Les chaînes de caractères étant délimitées par des guillemets anglais (« " »), ceux-ci ne
peuvent pas être utilisés en tant que caractères de ces chaînes. Pour résoudre ce problème, on peut utiliser
un antislash comme caractère d’échappement :

\"

Vous pouvez également spécifier des caractères directement à l’aide de leur valeur en base huit, à l’aide
de la syntaxe suivante :

\0valeur

où valeur est la valeur du caractère. Bien entendu, l’antislash étant utilisé comme caractère
d’échappement, il doit lui-même être précédé d’un caractère d’échappement si l’on désire l’utiliser dans
une chaîne de caractères :

\\

Ainsi, si l’on veut faire en sorte que la touche F4 affiche la chaîne de caractères « Coucou », il suffit
d’utiliser la ligne suivante dans le plan de clavier :

164
 Chapitre 6. Administration du système de base

string F4 = "Coucou"

Bien entendu, les chaînes de caractères les plus utiles sont celles qui définissent les séquences
d’échappement pour les touches spéciales. Par exemple, la définition de la touche Page Haut est la
suivante :

string PageUp = "\033[5~"

Vous pouvez reconnaître ces séquences d’échappement à la présence du caractère octal 033, soit 27 en
décimal, qui n’est rien d’autre que le caractère Escape dans le jeu de caractères ISO 8859-1. Ne vous
inquiétez par pour l’instant de la forme apparemment compliquée de ces séquences d’échappement, nous
verrons plus loin comment elles sont utilisées.
Enfin, les plans de clavier contiennent la définition des compositions. Les compositions de touches sont
accessibles à l’aide d’une touche spéciale dite de composition, dont le symbole est Compose dans le plan
de clavier (il est donc nécessaire que ce symbole soit affecté à l’une des touches du clavier pour utiliser
les compositions). Lorsqu’on appuie sur la touche de composition, le clavier attend deux autres touches,
dont les caractères serviront de base au caractère composé. Par exemple, les caractères ’^’ et ’a’ donne le
caractère composé ’â’.
Les compositions utilisent la syntaxe suivante :

compose ’caractère’ ’caractère’ to ’résultat’

où caractère est un des deux caractères à composer et résultat est le caractère résultant de la
composition. Notez bien que les compositions se font sur les caractères, et pas sur les touches. Elles sont
donc actives quel que soit la méthode obtenue pour générer ces caractères (combinaison de touches ou
touches simples).

Note : Le noyau définit la plupart des compositions nécessaires pour le jeu de caractères ISO
8859-1. Ne les cherchez donc pas en vain dans votre plan de clavier, vous ne les trouverez pas
forcément...
D’une manière générale, vous pourrez trouver de plus amples renseignements concernant les plans
de clavier dans la page de man keymaps.

Il est long et difficile de créer un plan de clavier de toutes pièces. Heureusement, encore une fois, cette
description n’était que didactique. Vous n’aurez certainement même pas à modifier votre plan de clavier
(sauf si vous voulez faire des expériences), car des plans de claviers prédéfinis sont fournis avec toutes
les distributions. Ces plans de clavier sont en général stockés dans le répertoire
/usr/lib/kbd/keymap. Pour les claviers de PC français, je vous conseille tout particulièrement le plan
de clavier [Link] du sous-répertoire i386/azerty. Ce plan de clavier permet d’accéder à
toutes les touches utilisées par le français, plus la plupart des touches utilisées en Europe. Il utilise
l’encodage ISO 8859-15, afin d’avoir accès aux rares caractères manquants dans l’encodage ISO 8859-1.
Le chargement d’un plan de clavier est très simple. Il suffit de taper la commande suivante sous le
compte root :

165
 Chapitre 6. Administration du système de base

loadkeys keymap

où keymap est le nom du fichier contenant le plan de clavier à utiliser. Si l’on ne spécifie pas de fichier,
loadkey attend que vous tapiez la spécification des touches directement. Vous pourrez valider en
générant le caractère EOF (abréviation de « End Of File », ce qui signifie « Fin de fichier ») à l’aide de la
combinaison de touche CTRL + D, ou abandonner avec le classique CTRL + C.
En général, les distributions utilisent la commande loadkey dans les fichiers d’initialisation du système,
pour charger le plan de clavier que vous avez choisi à l’installation dès le démarrage. Il est recommandé
de ne modifier le plan de clavier courant que par l’intermédiaire du programme de configuration du
système fourni avec votre distribution.

Modification des paramètres du clavier

Il nous faut encore voir deux petits utilitaires permettant de fixer quelques paramètres du clavier pour
finir notre tour d’horizon de ce périphérique. Le premier de ces outils permet de manipuler l’état des
diodes lumineuses qui indiquent si le verrou numérique, le verrou des majuscules ou l’arrêt défilement
sont actifs. Cet utilitaire se nomme logiquement setleds, et il permet non seulement de fixer l’état de ces
diodes, mais également l’état du clavier. Rappelons en effet que les diodes peuvent être désynchronisées
par rapport à l’état réel du clavier. Ce cas de figure peut se produire si l’on passe d’un terminal X à un
terminal en mode console, tout simplement parce que les serveurs X ne savent pas comment déterminer
l’état du clavier sur une console afin de le restaurer.
La syntaxe de setleds est la suivante :

setleds -D num | caps | scroll

où num, caps et scroll sont des options permettant de préciser respectivement l’état des verrous
numériques, majuscules et défilement. Ces options sont de la forme +num, -num pour le verrou
numérique, et de forme similaire pour les autres verrous. Comme leur syntaxe l’indique, elles permettent
d’enclencher ou de désenclencher l’état des verrous correspondants du clavier.
L’état des verrous du clavier est conservé par chaque terminal virtuel, indépendamment les uns des
autres. Cette commande devra donc être répétée pour tous les terminaux virtuels utilisés. L’option -D
permet de rendre les changements permanents pour le terminal sélectionné. Ainsi, si ce terminal est
réinitialisé, la modification sera conservée. C’est en général l’effet désiré. Sachez qu’il est également
possible d’effectuer une modification temporaire, et de ne modifier que l’affichage des diodes (sans
changer l’état des verrous).
Il est recommandé de placer les quelques lignes suivantes dans les fichiers d’initialisation de votre
système afin d’activer le verrou numérique pour tous les terminaux, si votre distribution ne vous permet
pas de le faire par l’intermédiaire de son programme de configuration :

INITTTY=‘ls /dev/tty[1-9] /dev/tty1[0-2]‘

for tty in $INITTTY; do
setleds -D +num < $tty
done

Ces lignes appellent la commande setleds sur les terminaux virtuels 1 à 12.

166
 Chapitre 6. Administration du système de base

Le deuxième utilitaire est kbdrate. Sa fonction est de fixer les paramètres de délai d’attente avant
répétition lorsqu’on maintient une touche enfoncée, ainsi que la vitesse de répétition utilisée une fois que
ce délai d’attente est dépassé. Sa syntaxe est elle aussi très simple :

kbdrate -s -r taux -d délai

où taux est le taux de répétition, et délai est le délai d’attente avant le début des répétitions de la
touche enfoncée. L’option -s indique à kbdrate de ne pas afficher de messages pendant l’exécution de la
commande. Les délais d’attente spécifiés peuvent être de 250, 500, 750 ou 1000 millisecondes. Les taux
de répétition utilisables vont de 2 à 30 caractères par seconde. Toutefois, les claviers ne peuvent pas
accepter toutes les valeurs intermédiaires pour le taux de répétition. Vous trouverez la liste exhaustive
des valeurs admissibles dans la page de manuel kbdrate.

Choix de la police de caractères

Par défaut, la police de caractères utilisée par Linux est la police enregistrée dans la carte graphique.
Cette police convient pour l’affichage des textes anglais, car elle utilise la page de codes 437. Il est donc
souhaitable, sinon recommandé, de changer de police de caractères à la fois pour bénéficier d’un
encodage adapté à la langue française, et pour bénéficier d’améliorations esthétiques éventuelles.
Linux est fourni avec un certain nombre de fichiers de polices, qui sont normalement installées dans le
répertoire /usr/lib/kbd/consolefonts. Comme vous pourrez le constater si vous y jetez un coup
d’œil, ce répertoire contient un grand nombre de polices, utilisant divers encodages. Les polices les plus
utiles pour un ordinateur situé en France sont sans doute les polices iso01*, lat1-* et lat0-*. Cette
dernière police utilise l’encodage ISO 8859-15, et contient donc tous les symboles utilisés en Europe. Il
est recommandé, mais non nécessaire, d’utiliser une des polices encodées en ISO 8859-1 ou en ISO
8859-15, avec un plan de clavier approprié. Par exemple, le plan de clavier [Link] pourra
être utilisé avec la police de caractères [Link].
Les polices de caractères sont chargées aisément avec l’utilitaire setfont. La syntaxe de ce programme
est très simple :

setfont police

où police est le fichier de police à charger. Si vous ne spécifiez aucun fichier de police, la police par
défaut sera chargée.
Notez que les fichiers de polices peuvent utiliser un encodage particulier spécifique, qui ne correspond à
aucune des tables de conversion prédéfinies du noyau. Pour ces polices, il est nécessaire de spécifier des
tables de conversion qui leurs sont propres. Ces tables permettent de convertir les codes des caractères
reçus par la console en codes Unicode spéciaux. Tous ces codes appartiennent à une plage de codes
Unicode réservée au système, et que Linux utilise pour définir les codes qui permettront d’accéder
directement aux caractères de la police. L’association entre les codes de caractères de l’application et
leurs descriptions dans la police de caractères est donc réalisée grâce à ces tables de conversion.
Vous pouvez charger une table de conversion spécifique à l’aide de l’utilitaire mapscrn. Cet utilitaire
prend en ligne de commande un fichier contenant la table de conversion, et charge cette dernière dans la
quatrième table de conversion du noyau (c’est-à-dire la table réservée à l’utilisateur) :

mapscrn fichier

167
 Chapitre 6. Administration du système de base

(où fichier est le fichier contenant la description de la table de conversion).

Notez que l’utilitaire mapscrn charge la table de conversion, mais ne s’assure pas que le jeu de
caractères courant utilise cette table. Par conséquent, vous aurez sans doute à utiliser les codes
d’échappement \033(K et \033)K pour faire pointer respectivement les jeux de caractères G0 et G1 sur
la quatrième table. Ces codes d’échappement peuvent être saisis à l’aide de la commande cat :

cat

Il vous faudra alors taper sur la touche Echap, puis saisir « (K » ou « )K », et enfin signaler la fin de
fichier avec un CTRL + D. Faites bien attention à ce que vous faîtes : en cas d’erreur, le jeu de caractères
utilisé peut rendre l’écran totalement illisible. Si cela devait se produire, vous devrez taper à l’aveugle la
commande reset. Cette table s’assure que le jeu de caractères actif est le jeu de caractères G0, et que
celui-ci utilise la première table de conversion. Vous pourrez également recharger la police par défaut à
l’aide de setfont.
Heureusement, la plupart des polices de caractères contiennent également la table de conversion à
utiliser, et setfont effectue tout le travaille en une seule passe. Il charge la police de caractères dans la
carte graphique, puis sa table de conversion dans le noyau, et s’assure enfin que le jeux de caractères G0
soit actif et utilise cette table. Ainsi, l’utilisation de mapscrn est devenue facultative.
La dernière étape dans la configuration de la police de caractères est le chargement de la table de
conversion Unicode vers les indices des caractères dans la police. Cette table est essentielle, puisque
c’est elle qui indique l’emplacement des caractères de la police à utiliser pour chaque code Unicode. Ces
tables dépendent donc de l’encodage utilisé par la police de caractères.
Le chargement des tables de conversion est réalisée par le programme loadunimap. La syntaxe de ce
dernier est la même que celle de mapscrn :

loadunimap fichier

où fichier est un fichier de conversion approprié. Vous trouverez de tels fichiers dans le répertoire
/usr/lib/kbd/consoletrans. Les fichiers proposés permettent d’utiliser les polices de caractères
encodées selon les encodages les plus courants.
Bien entendu, certaines polices disposent de leur propre table d’encodage. Encore une fois, l’utilisation
de loadunimap est rendue facultative par setfont, qui se charge d’effectuer tout le travail. C’est
notamment le cas pour les polices [Link] et [Link], dont le « u » en fin
d’extension indique la présence de la table de conversion Unicode.

Configuration des paramètres du terminal

La configuration du gestionnaire de la console ne concerne à proprement parler que les plans de clavier
et les polices de caractères. Pour les applications, tout se passe comme si elles accédaient à un terminal
comme les autres, donc par l’intermédiaire d’une ligne de communication. En général, les lignes de
communication utilisées pour les terminaux sont des lignes série, c’est-à-dire des lignes sur lesquelles les
données sont envoyées sous la forme de petits paquets de 5 à 8 bits, et contrôlées par d’autres bits
éventuellement facultatifs (bit de stop et bit de parité). Il va de soi que tous les terminaux ne sont pas

168
 Chapitre 6. Administration du système de base

identiques, et qu’un certain nombre de paramètres doivent être définis tant au niveau des terminaux qu’au
niveau des lignes de communication utilisées.
Ces paramètres peuvent être fixés avec la commande stty. Leur nombre interdit ici une description
exhaustive, d’autant plus que pour un terminal local, ils sont tous initialisés à des valeurs par défaut
correctes, et vous n’aurez pas à les modifier. Vous pouvez toutefois consulter la page de manuel de stty
pour de plus amples renseignements à ce sujet.
Si vous êtes curieux, vous pourrez obtenir à tout moment la liste des paramètres de la ligne de
communication d’un terminal avec l’option -a de stty :

stty -a

Comme vous pourrez le constater, le nombre des options utilisées est assez impressionnant. Sont définis,
entre autres, les paramètres de vitesse de communication de la ligne (option speed), le format des
données transférées sur la ligne (option parodd pour la parité impaire, option cs8 pour des paquets 8
bits, etc.), la géométrie du terminal (options rows et columns), les caractères de contrôle affectés à un
certain nombre d’actions (comme, par exemple, le caractère « ^Z », accessible par la combinaison de
touches CTRL + Z, qui permet de suspendre l’exécution du programme utilisant la ligne, et le caractère
« ^C », qui permet de le tuer) et des options de gestion des caractères transférés (par exemple, echo fait
en sorte que tout caractère entrant est immédiatement ré-émis sur la console, ce qui permet de voir ce que
l’on tape).
Parmi ces paramètres, les plus intéressants sont sans doute ceux définissant les actions associées aux
différentes touches de contrôle. Vous pourrez modifier ces paramètres avec la syntaxe suivante :

stty action caractère

où action est l’une des actions gérées par stty, comme par exemple susp pour suspendre le processus
en cours, intr pour le tuer, etc. Remarquez que l’action kill n’a rien à voir avec la gestion des signaux
des processus. Elle permet simplement d’effacer la ligne courante du terminal.

Description des terminaux

Le dernier maillon de la chaîne de gestion des caractères est bien entendu les applications. La plupart des
applications sont capables de traiter les caractères simples comme les lettres de l’alphabet, les chiffres et
la ponctuation. Cependant, il n’en va pas de même pour les codes d’échappement des terminaux. Comme
nous l’avons vu, certaines touches sont programmées pour renvoyer des codes d’échappement dans le
plan de clavier. Mais le gestionnaire de la console est également capable d’interpréter certains codes
d’échappements, afin d’effectuer des actions spécifiques. Par exemple, les touches du curseur émettent
des codes d’échappement spéciaux, et il est du ressort de chaque programme de reconnaître ces codes et
d’agir en conséquence. De même, les programmes peuvent envoyer des codes d’échappement à la
console pour déplacer le curseur affiché, effacer l’écran, effectuer un défilement, etc.
Le malheur, c’est que les codes d’échappement utilisables diffèrent selon les terminaux utilisés. Les
terminaux les plus standards sont les terminaux VT100 et VT102 (la console Linux en fait partie).
Cependant, les programmes ne peuvent pas savoir, a priori, quels codes d’échappement doivent être
utilisés pour effectuer telle ou telle action.

169
 Chapitre 6. Administration du système de base

C’est pour ces diverses raisons que les systèmes Unix disposent d’une base de donnée de définition des
terminaux. Cette base de donnée contient tous les codes d’échappement que chaque type de terminal est
capable de gérer, décrits d’une manière uniforme. Ainsi, les programmes désirant gérer correctement les
terminaux n’ont qu’à consulter cette base de données pour interpréter et récupérer les codes
d’échappement utilisés par le terminal. Historiquement, la définition des terminaux était réalisée dans le
fichier de configuration /etc/termcap. Ce fichier est obsolète et a été remplacé par la base de données
terminfo, que tous les programmes modernes doivent à présent utiliser. Cependant, le fichier de
configuration /etc/termcap a été conservé par compatibilité avec les vieux programmes qui l’utilisent
encore.
Le fichier termcap comprend une ligne pour chaque type de terminal décrit. Cette ligne est constituée
d’un certain nombre de champs, séparés par le caractère ’:’. Le premier champ de chaque ligne contient
la description du terminal que cette ligne décrit. Les champs suivants sont des définitions des variables
contenant les séquences d’échappement du terminal.
Les informations descriptives du terminal sont les suivantes :

• le nom abrégé du terminal ;

• le nom complet du terminal ;
• les autres noms sous lesquels le terminal est également connu ;
• la description détaillée du terminal (toujours en dernier).
Ces informations sont séparées les unes des autres par une barre verticale (’|’).
Viennent ensuite les définitions des variables. Chaque variable est définie selon la syntaxe suivante :

variable=séquence

où variable est le nom de la variable, et séquence est la séquence d’échappement associée à cette
variable. Notez que certaines variables ne prennent pas de paramètres, et que leur présence dans la
description du terminal signale simplement un comportement particulier de celui-ci. Notez également
que pour les variables numériques, le caractère d’égalité est remplacé par un caractère dièse (’#’).
Un certain nombre de variables peuvent être définies pour chaque terminal. Ce sont ces variables qui sont
utilisées par les programmes pour retrouver les séquences d’échappement du terminal. Par conséquent,
les noms de ces variables sont fixés une fois pour toutes, et elles représentent toujours la même
fonctionnalité. La liste des fonctionnalités est, encore une fois, très grande, et les variables utilisables
sont listées exhaustivement dans la page de manuel termcap.

Note : Il est évident que les lignes du fichier /etc/termcap peuvent devenir très longues. Il est donc
possible de les étaler sur plusieurs lignes physiques, en insérant le caractère de continuation de
ligne antislash (’\’). Après chaque retour à la ligne, il faut utiliser une indentation à l’aide du caractère
de tabulation.

Vous trouverez ci-dessous un exemple de définition de terminal :

lx|linux|Console Linux:\
:do=^J:co#80:li#25:cl=\E[H\E[J:sf=\ED:sb=\EM:\
:le=^H:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\

170
 Chapitre 6. Administration du système de base

:ce=\E[K:cd=\E[J:so=\E[7m:se=\E[27m:us=\E[36m:ue=\E[m:\
:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:is=\E[1;25r\E[25;1H:\
:ll=\E[1;25r\E[25;1H:al=\E[L:dc=\E[P:dl=\E[M:\
:it#8:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=^H:ti=\E[r\E[H:\
:ho=\E[H:kP=\E[5~:kN=\E[6~:kH=\E[4~:kh=\E[1~:kD=\E[3~:kI=\E[2~:\
:k1=\E[[A:k2=\E[[B:k3=\E[[C:k4=\E[[D:k5=\E[[E:k6=\E[17~:\
:k7=\E[18~:k8=\E[19~:k9=\E[20~:k0=\E[21~:K1=\E[1~:K2=\E[5~:\
:K4=\E[4~:K5=\E[6~:\
:pt:sr=\EM:vt#3:xn:km:bl=^G:vi=\E[?25l:ve=\E[?25h:vs=\E[?25h:\
:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:\
:r1=\Ec:r2=\Ec:r3=\Ec:

Cette ligne permet de définir le terminal associé à la console Linux. Vous pourrez par exemple
reconnaître le nombre de colonnes et de lignes (variables co et li), ainsi que les codes d’échappement
associés aux touches du curseur (variable ku, kd, kr et kl respectivement pour les touches haut, bas,
droite et gauche). Par exemple, la variable cl donne la séquence d’échappement utilisable pour effacer
l’écran et faire revenir le curseur en haut à gauche (séquence d’échappement « Esc [ H Esc [ J »).
Comme il l’a déjà été dit plus haut, la liste complète des variables peut être obtenue en consultant la page
de manuel termcap, et ce fichier ne sera pas décrit plus en détail ici.
La base de données terminfo a été introduite pour combler certaines limitations du fichier termcap. Si
le principe de fonctionnement est presque le même, les informations fournies tiennent compte des
terminaux plus récents et de nouvelles fonctionnalités. Cela signifie en pratique que de nouvelles
variables ont été définies pour décrire les nouveaux terminaux. Inversement, certaines variables de
termcap ont disparu parce qu’elles devenaient obsolètes, et ont été remplacées par des variables
équivalentes de terminfo.
La principale différence entre terminfo et termcap est que la description des terminaux n’est plus
stockée dans un fichier de configuration en mode texte. Toutes les données sont désormais stockées dans
des fichiers binaires, qui peuvent être générés à l’aide du programme tic. Ces fichiers binaires sont
usuellement placés dans les sous-répertoires du répertoire /usr/share/terminfo/. En fait, le nombre
de fichiers de description est tellement grand qu’ils ont été regroupés par ordre alphabétique. Ainsi, le
répertoire /usr/share/terminfo contient des sous-répertoires dont les noms sont les premières lettres
des fichiers de description, et chaque fichier de description est situé dans le répertoire correspondant. Par
exemple, le fichier de description des terminaux Linux se nomme tout simplement linux. Comme la
première lettre de son nom est ’l’, il est stocké dans le répertoire /usr/share/terminfo/l/, avec les
descriptions de tous les autres terminaux dont le nom commence par ’l’.

Note : En fait, les fichiers de description de terminaux peuvent être placés à un autre emplacement
que l’emplacement par défaut. Les bibliothèques de programme utilisant les informations de
terminfo cherchent en effet en premier dans le chemin référencé par la variable d’environnement
TERMINFO, puis dans le répertoire .terminfo du répertoire de l’utilisateur. Ce n’est que si ces
deux recherches échouent qu’elles utilisent les informations du répertoire par défaut.

Comme nous l’avons dit, les fichiers de description sont des fichiers binaires, qui ont été compilés à
l’aide du compilateur tic. Cependant, vous pouvez parfaitement visualiser le contenu de ces fichiers ou
comparer deux fichiers à l’aide de l’utilitaire infocmp. Par exemple, vous pouvez visualiser sous une

171
 Chapitre 6. Administration du système de base

forme lisible les informations du fichier de description des terminaux Linux avec la commande suivante :

infocmp linux

Vous obtiendrez certainement un résultat semblable à ceci :

#Reconstructed via infocmp from file: /usr/lib/terminfo/l/linux

linux|linux console,
am, bce, eo, mir, msgr, xenl, xon,
colors#8, it#8, pairs#64,
acsc=+\020\,\021-\030.^Y0\333‘\004a\261f\370g\361h\260i\316j\\
331k\277l\32m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\\
363z\362{\343|\330}\234~\376,
bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
clear=\E[H\E[J, cnorm=\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub1=^H, cud1=^J, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, cvvis=\E[?25h,
dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM,
dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
flash=\E[?5h\E[?5l$<200/>, home=\E[H, hpa=\E[%i%p1%dG,
ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL,
il1=\E[L, ind=^J, invis=\E[8m, kb2=\E[G, kbs=\177, kcbt=\E[Z,
kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
kdch1=\E[3~, kend=\E[4~, kf1=\E[[A, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
kf19=\E[33~, kf2=\E[[B, kf20=\E[34~, kf3=\E[[C, kf4=\E[[D,
kf5=\E[[E, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
khome=\E[1~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~, kspd=^Z,
nel=^M^J, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
rmacs=\E[10m, rmir=\E[4l, rmpch=\E[10m, rmso=\E[27m,
rmul=\E[24m, rs1=\Ec, sc=\E7, setab=\E[4%p1%dm,
setaf=\E[3%p1%dm,
sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;\
%?%p5%t;2%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m,
sgr0=\E[m, smacs=\E[11m, smir=\E[4h, smpch=\E[11m,
smso=\E[7m, smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR,
u7=\E[6n, u8=\E[?6c, u9=\E[c, vpa=\E[%i%p1%dd,

Comme vous pouvez le constater, le format de ces informations est similaire à celui de celles qui sont
enregistrées dans le fichier /etc/termcap. Les principales différences sont que les différents champs
sont séparés par des virgules (’,’) au lieu du caractère deux points (’:’), et qu’il est possible de les
répartir sur plusieurs lignes physiques (il est donc inutile d’utiliser le caractère antislash en fin de ligne
physique pour indiquer la continuation de la ligne logique). De plus, le nom des variables utilisées dans
les fichiers terminfo n’est pas le même a priori. Cependant, le principe d’utilisation de ces variables reste
le même, chacune d’entre elles permet de définir une des fonctionnalités gérées par le terminal et de
définir la séquence d’échappement nécessaire à l’obtention de cette fonctionnalité si nécessaire. Vous

172
 Chapitre 6. Administration du système de base

pourrez trouver la liste exhaustive des variables utilisables dans la page de manuel terminfo. Le format
des fichiers de configuration de terminfo ne sera donc pas décrit plus en détail dans ce document.
Qu’ils utilisent des bibliothèques basées sur termcap ou terminfo, les programmes doivent tous
connaître le nom du terminal courant pour récupérer les informations qui permettent de l’utiliser dans ces
bases de données. C’est précisément ce à quoi sert la variable d’environnement TERM. Cette variable
contient en permanence le nom du terminal courant, que les programmes peuvent utiliser comme index
dans les bases de données termcap ou terminfo. Ainsi, si vous désirez travailler sur un terminal
Linux, vous pourrez fixer le type de terminal correct avec la commande suivante :

export TERM=linux

La liste des noms de terminaux utilisables peut être obtenue en lisant directement le fichier termcap.
Cette liste peut être obtenue plus facilement pour terminfo, à l’aide de l’utilitaire toe (abréviation de
l’anglais « Table Of terminfo Entry »).
Bien entendu, vous n’aurez à définir la valeur de TERM que si cette variable d’environnement n’est pas
correctement définie, ce qui est très rare. En fait, cela ne peut se produire que lors d’une connexion à
distance sur un autre ordinateur, dont les terminaux ne sont pas de type Linux.

Paramétrage des applications

En théorie, la description du terminal courant fournie par les bases de données termcap ou terminfo
est suffisante pour faire fonctionner correctement la plupart des applications. En particulier, les
programmes qui utilisent les bibliothèques de fonctions de manipulation des terminaux sont capables
d’utiliser ces informations. C’est le cas par exemple de tous les programmes qui utilisent les
bibliothèques « curses » ou « ncurses », car celles-ci s’appuient sur la base de données terminfo.
Cependant, certaines applications utilisent un mécanisme plus simple (mais moins souple) pour gérer les
terminaux. Pour ces applications, une configuration spécifique doit être effectuée, souvent pour chaque
terminal, en précisant les codes d’échappement à utiliser dans leurs fichiers de configuration. On
remarquera la présence du shell « bash », de l’éditeur « vi » et du programme de pagination « less » dans
cette catégorie de logiciels. Comme ce sont les logiciels les plus couramment utilisés, il est indispensable
d’indiquer comment les configurer pour une utilisation correcte.

Configuration du clavier pour la bibliothèque readline

Un certain nombre d’applications, dont le shell « bash », utilisent la libraire GNU « readline » pour
obtenir les lignes de commandes saisies par l’utilisateur. Tous ces programmes peuvent donc être
configurés de la même manière, grâce au fichier de configuration de la bibliothèque readline.
Cette bibliothèque recherche son fichier de configuration en premier à l’emplacement indiqué par la
variable d’environnement INPUTRC. Si cette variable d’environnement n’est pas définie, le fichier de
configuration ~/.inputrc est lu pour déterminer les séquences d’échappement à utiliser. Il est donc
recommandé de créer un fichier de configuration général /etc/inputrc et de définir la variable
d’environnement INPUTRC afin de définir des paramètres communs à tous les utilisateurs. Vous pouvez
également recopier ce fichier dans les répertoires personnels de tous les utilisateurs sous le nom
.inputrc.

173
 Chapitre 6. Administration du système de base

Ainsi, si vous voulez gérer correctement le clavier français sous le shell bash, vous devrez vous assurer
que les lignes suivantes sont placées dans votre fichier inputrc :

# Active la gestion du huitième bit des caractères

# (par exemple pour les caractères accentués) :
set meta-flag on
set input-meta on
set output-meta on
set convert-meta off

# Définit les codes d’échappement associés aux touches du curseur :

"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[2~": overwrite-mode
"\e[3~": delete-char
"\e[5~": history-search-backward
"\e[6~": history-search-forward
"\e[C": forward-char
"\e[D": backward-char
"\e[A": previous-history
"\e[B": next-history

# Redéfinit les codes d’échappement pour l’émulateur de terminal xterm :

$if term=xterm
"\e[H": beginning-of-line
"\e[F": end-of-line
$endif

Ce fichier commence par autoriser le traitement des caractères dont le bit « meta », c’est-à-dire le
huitième bit, est positionné. C’est en particulier le cas de tous les caractères accentués dans les
principales pages de codes ; ces options sont donc nécessaires pour pouvoir utiliser ces caractères dans le
shell. La suite du fichier définit les actions associées à chaque code d’échappement du terminal. Le
caractère d’échappement est représenté ici par la chaîne de caractères « \e ». Comme les codes
d’échappement sont différents pour la console et pour les émulateurs de terminaux de XWindow, il est
nécessaire de les redéfinir en fonction de la nature du terminal. Ce fichier présente un exemple
d’expression conditionnelle sur le nom du terminal, tel qu’indiqué dans la variable d’environnement
TERM, afin de ne redéfinir ces codes que pour ces terminaux.

Configuration du clavier pour vi

L’éditeur en ligne de commande vi n’est pas réputé pour être agréable à utiliser. Cela provient
essentiellement de sa distinction entre les mode de commande, d’édition et de visualisation. Mais cela
n’est pas suffisant pour le rendre haïssable : la torture psychologique imposée par la mauvaise gestion du
curseur vient souvent à bout des plus résistants. Heureusement, Linux fournit un clone nettement plus
puissant et qui permet de résoudre ces problèmes : vim.
L’éditeur vim peut bien entendu être parfaitement compatible avec vi afin ne pas dérouter les habitués de
vi. Mais il dispose en plus de fonctionnalités avancées qui en font un outil extrêmement configurable, et
il est possible de le rendre nettement plus ergonomique que son ancêtre. Malheureusement, il faut

174
 Chapitre 6. Administration du système de base

reconnaître que la plupart des distributions fournissent un vim « brut de fonderie », ce qui fait que seuls
ceux qui se lancent dans la lecture de son aide peuvent parvenir à l’utiliser correctement. Les options qui
sont proposées ici sont donc données simplement à titre indicatif, mais permettront peut-être de rendre
vim un peu plus ergonomique.
Les options de configuration de vim sont stockées dans deux fichiers. Le premier fichier est le fichier de
configuration commun à tous les utilisateurs, vimrc. Ce fichier peut être placé soit dans le répertoire
/etc/, soit dans le répertoire /usr/share/vim/, selon votre distribution. Le deuxième fichier est le
fichier de préférences personnelles de chaque utilisateur, et se nomme .vimrc. Il est normalement placé
dans le répertoire personnel de l’utilisateur.
Plusieurs types d’options peuvent être indiquées dans ces fichiers de configuration. Les premières
associent les actions à effectuer aux codes d’échappement générés par les touches du curseur. Les autres
spécifient simplement le comportement de l’éditeur et le paramétrage de ses principales fonctionnalités.
Vous trouverez ci-dessous les principales options que vous pourrez ajouter à votre fichier de
configuration vimrc. Ces options rendront sans doute l’utilisation de vim beaucoup plus agréable.

" Exemple d’options de configuration pour vim.

" Notez que les commentaires sont introduits ici
" par des guillemets anglais (") et non
" par des dièses (’#’), contrairement aux fichiers de configuration
" de la plupart des autres applications.

" Éviter à tout pris la compatibilité avec vi, qui est insupportable :
set nocompatible

" Définir les touches du clavier :

" Gestion du curseur en mode de visualisation :

map ^[OA k
map ^[[A k
map ^[OB j
map ^[[B j
map ^[OD h
map ^[[D h
map ^? h
map ^H h
map ^[OC l
map ^[[C l
map ^[[2~ i
map ^[[3~ x
map ^[[1~ 0
map ^[OH 0
map ^[[H 0
map ^[[4~ $
map ^[OF $
map ^[[F $
map ^[[5~ ^B
map ^[[6~ ^F
map ^[[E ""
map ^[[G ""

175
 Chapitre 6. Administration du système de base

map ^[OE ""

" Gestion du pavé numérique en mode de visualisation :

map ^[Oo :
map ^[Oj *
map ^[Om -
map ^[Ok +
map ^[Ol +
map ^[OM ^M
map ^[Ow 7
map ^[Ox 8
map ^[Oy 9
map ^[Ot 4
map ^[Ou 5
map ^[Ov 6
map ^[Oq 1
map ^[Or 2
map ^[Os 3
map ^[Op 0
map ^[On .

" Gestion du pavé numérique en mode insertion :

map! ^[Oo :
map! ^[Oj *
map! ^[Om -
map! ^[Ok +
map! ^[Ol +
map! ^[OM ^M
map! ^[Ow 7
map! ^[Ox 8
map! ^[Oy 9
map! ^[Ot 4
map! ^[Ou 5
map! ^[Ov 6
map! ^[Oq 1
map! ^[Or 2
map! ^[Os 3
map! ^[Op 0
map! ^[On .

" Gestion du curseur dans les modes d’insertion et de commande :

map! ^[[H <Home>
map! ^[OH <Home>
map! ^[[F <End>
map! ^[OF <End>
map! ^[OA <Up>
map! ^[OB <Down>
map! ^[OC <Right>
map! ^[OD <Left>
map! ^[[3~ <Delete>
map! ^[OE <Space>

176
 Chapitre 6. Administration du système de base

" Définir les autres options globales :

" Paramétrage des touches Backspace et Delete :

set t_kb=^?
set t_kD=ESC[3~

" Faire en sorte que le "backspace" efface même les sauts de lignes :
set bs=2

" Utiliser l’indentation automatique dans les fichiers C et C++

" (pour les programmeurs) :
set cindent

" Utiliser la coloration syntaxique pour les principaux langages

" de programmation :
set background=dark
if &t_Co > 1
syntax on
endif

" Signaler les correspondances de parenthèses, accolades et crochets :

set showmatch

" Rappeler le mode de fonctionnement courant :

set showmode

Vous constaterez que certains caractères de contrôle sont utilisés dans ce fichier de configuration, dont le
caractère de contrôle « ^[ », qui représente le caractère d’échappement. Ces caractères sont représentés
avec la notation classique « ^C », où « C » est la lettre à utiliser avec la touche CTRL pour obtenir ce
caractère. Ces notations ne font que représenter les caractères de contrôle, et doivent être remplacées par
les caractères qu’elles représentent dans le fichier de configuration. Pour saisir ces caractères spéciaux,
vous devrez passer en mode insertion dans vi, puis utiliser la combinaison de touches CTRL+V. Ce
raccourci permet d’indiquer à vi qu’il doit insérer les codes d’échappement directement issus du clavier,
sans les interpréter. Vous pourrez alors taper la séquence de touches générant le caractère de contrôle ou
la séquence d’échappement désirée. Par exemple, vous pourrez obtenir le caractère « ^H » en tapant la
combinaison de touches CTRL+H, et le caractère « ^? » en appuyant sur la touche Backspace (retour
arrière). Les caractères d’échappement peuvent être générés par la touche Echap ou directement par les
touches du curseur.

Note : En fait, vous pouvez également utiliser les chaînes de caractères « \e » et « <Esc> » pour
représenter le caractère d’échappement. Mais certaines options ne fonctionnent pas avec ces
notations, et je vous les déconseille.

Vous pouvez bien entendu ajouter d’autres options dans ce fichier de configuration. En pratique, toutes
les options utilisables dans le mode de commande de vim peuvent être fixées définitivement dans ce
fichier. Vous obtiendrez de l’aide sur ces options grâce à la commande « :help » de vim.

177
 Chapitre 6. Administration du système de base

Configuration du clavier pour less

Le programme de pagination less est naturellement bien plus agréable à utiliser que son ancêtre more,
puisqu’il permet de revenir sur les pages déjà consultées. Cependant, il peut le devenir encore plus si l’on
s’arrange pour qu’il reconnaisse les touches du curseur.
Le programme less lit ses informations de configuration dans un fichier binaire dont l’emplacement est
spécifié par la variable d’environnement LESSKEY. Si cette variable d’environnement n’est pas définie,
less utilise le fichier de configuration .less du répertoire personnel de l’utilisateur. Ce fichier binaire
contient les associations entre les séquences d’échappement du terminal et les actions effectuées par less.
Il est généré par le compilateur lesskey, à partir d’un fichier de configuration textuel classique.
Ce fichier de configuration comprend plusieurs sections, qui permettent de définir les touches utilisées en
mode de commande, les touches utilisées en mode d’édition de lignes (par exemple dans une commande
de recherche), et enfin les variables d’environnement utilisées par less. Vous trouverez ci-dessous un
exemple de fichier de configuration pour less. Vous trouverez de plus amples renseignements sur les
actions qui peuvent être associées aux séquences d’échappement et aux caractères de contrôle dans la
page de manuel lesskey.

# Exemple de fichier de configuration pour less

# Première section :

#command
\e[B forw-line
\e[A back-line
\e[6~ forw-scroll
\e[5~ back-scroll
\177 back-screen
^H back-screen
\e[3~ back-screen
\e[2~ visual
\e[1~ goto-line
\eOH goto-line
\e[4~ goto-end
\eOF goto-end
\eOM forw-line

# Deuxième section :

#line-edit
\177 backspace
^H backspace
\e[3~ delete
\e[1~ home
\e[H~ home
\eOH home
\e[4~ end
\e[F~ end
\eOF end
\e[5~ up
\e[6~ down

178
 Chapitre 6. Administration du système de base

\e[2~ insert
\e[E insert
\e[G insert
\eOE insert
\eOo insert :
\eOj insert *
\eOm insert -
\eOk insert +
\eOl insert +
\eOM insert
\eOw insert 7
\eOx insert 8
\eOy insert 9
\eOt insert 4
\eOu insert 5
\eOv insert 6
\eOq insert 1
\eOr insert 2
\eOs insert 3
\eOp insert 0
\eOn insert .

# Troisième section :

#env
LESSCHARSET=latin1

Conformément à un usage courant, les commentaires sont introduits par le caractère dièse (’#’) dans ce
fichier de configuration. Cependant, certains commentaires sont utilisés pour identifier le début des trois
sections du fichier. Il s’agit des commentaires « #command », « #line-edit » et « #env ». Il ne faut
donc surtout pas supprimer ces commentaires dans votre fichier de configuration.
Encore une fois, le caractère d’échappement est symbolisé par la chaîne de caractère « \e ». De même,
les caractères de contrôle sont représentés par la notation classique « ^C », où C est la touche utilisée en
combinaison avec CTRL pour générer ce caractère de contrôle. Notez que, contrairement au fichier de
configuration /etc/vimrc, ces notations peuvent être utilisées directement dans le fichier de
configuration de less.
Ce fichier de configuration pourra être compilé avec le programme lesskey afin de générer le fichier
binaire utilisé par less. Pour cela, il faudra simplement utiliser la syntaxe suivante :

lesskey fichier

où fichier est le nom du fichier de configuration à compiler. Le fichier binaire généré est par défaut
celui référencé par la variable d’environnement LESSKEY. Si cette variable n’est pas définie, un fichier
.less sera créé dans le répertoire personnel de l’utilisateur.

179
 Chapitre 6. Administration du système de base

Configuration de la souris
L’installation de la souris est une opération très simple à réaliser. La seule chose importante est de bien
connaître les différents types de souris et de ne pas les confondre. Autrefois, la plupart des souris étaient
des souris connectées sur le port série (souris sérielles). Aujourd’hui, ces souris se font de plus en plus
rares, et le port de prédilection est le port PS/2. Ce port a été introduit par IBM dans ses ordinateurs PS/2
et est quelque peu plus pratique que le port série, car il définit une interface standard pour toutes les
souris. De plus, il permet de dégager un des ports série, ce qui simplifie la configuration des modems. Le
port PS/2 ressemble au port clavier du même type, et en fait on peut se tromper et brancher la souris à la
place du clavier et inversement. Il ne faut surtout pas confondre les souris PS/2 avec les souris Bus, qui
ont été vendues autrefois et que l’on ne trouve quasiment plus à présent. Ces souris pouvaient se
connecter sur des cartes spéciales voire, parfois, sur la carte graphique.
Pour que l’installation de la souris se fasse correctement, il faut s’assurer que les options concernant la
souris ait bien été définies dans la configuration du noyau de Linux. Cela n’est pas nécessaire pour les
souris série. Vous pouvez consulter la la section intitulée Compilation du noyau Linux dans Chapitre 7
pour plus de détails sur la configuration du noyau. Lorsque cette étape est faite, il ne reste plus qu’à
indiquer au programme de gestion de la souris à quel type de souris il a affaire. Ce programme, nommé
gpm, permet d’utiliser la souris en mode texte. La configuration de la souris pour XWindow sera vue
dans le Chapitre 10.
La configuration de gpm se fait normalement par l’intermédiaire du programme de configuration de votre
distribution. Lorsqu’on n’utilise pas XWindow, gpm est lancé automatiquement au démarrage. Il se peut
que votre programme de configuration vous demande le type de souris à utiliser. Dans ce cas, il faut
choisir le bon type, faute de quoi gpm ne fonctionnera pas correctement. Attention, si vous désirez
utiliser une souris à molette (souris disposant d’une petite roue entre les deux boutons, et permettant de
faire défiler le contenu des fenêtres), le type de souris à utiliser est « imps2 » et non simplement « ps2 ».
Pour avoir la liste des types de souris gérés par gpm, il suffit de le lui demander avec la ligne de
commande suivante :

gpm -t help

Normalement, vous aurez à utiliser gpm avec la ligne de commande suivante :

gpm -t type -m /dev/mouse

où type est le type de la souris que gpm doit utiliser et /dev/mouse est un lien vers le fichier spécial de
périphérique gérant votre souris.

Configuration de l’imprimante
Il existe deux systèmes d’impression concurrents sous Linux : LPRng (« Line Printer Next Generation »)
et CUPS (« Common Unix Printing System »). LPRng est une évolution du système initial, LPR, qui est
devenu très vite obsolète en raison de l’évolution des technologies d’impression. En effet, celui-ci a été
conçu à l’époque où les imprimantes étaient encore des imprimantes matricielles et ne pouvaient
imprimer qu’en noir et blanc. CUPS, quant à lui, a été créé pour fournir une infrastructure complètement

180
 Chapitre 6. Administration du système de base

nouvelle et pour s’affranchir des limitations de LPRng. C’est donc la solution d’avenir, mais il n’est pas
rare de trouver encore des systèmes basés sur LPRng. D’autre part, la compatibilité au niveau des
commandes d’impression est assurée par CUPS, ce qui fait que la présentation de LPRng n’est pas
superflue.
Quelle que soit la technologie d’impression utilisée, l’imprimante reste généralement accessible par un
port local. En effet, la plupart des imprimantes sont connectées sur le port parallèle ou sur un port USB
(les imprimantes professionnelles mises à part, celles-ci disposant généralement d’une interface réseau).
Nous supposerons donc dans la suite de ce document que l’imprimante est connectée soit sur le port
parallèle (accessible via le fichier spécial de périphérique /dev/lp0), soit sur un port USB (accessible
via le fichier /dev/usb/lp0).

Concepts de base de l’impression sous Unix

La principale difficulté lors de l’impression d’un document est de le convertir de son propre format de
fichier vers un format de données que l’imprimante est capable de comprendre. Le problème ici est qu’il
existe une multitude de formats de documents et une multitude d’applications qui peuvent les générer,
d’une part, et, d’autre part, que chaque fabricant d’imprimantes a développé ses propres jeux de
commandes pour ses imprimantes. Il existe bien un standard pour les imprimantes laser avec le langage
PostScript développé par Adobe, mais ce langage n’est pas utilisable avec la majorité des imprimantes à
jet d’encre. De fait, la plupart des applications sont capables de générer un fichier PostScript lors d’une
impression, mais ce fichier doit encore être traduit dans le langage spécifique de l’imprimante
effectivement installée.
Il est donc toujours possible d’envoyer directement un fichier à imprimer à l’imprimante, en le recopiant
directement sur le fichier spécial de périphérique de l’imprimante, mais cette technique suppose que ce
fichier soit généré directement dans le langage de l’imprimante. Ceci ne peut que compliquer les
applications qui permettent l’impression, et les empêcher de fonctionner ultérieurement avec de
nouvelles imprimantes dont le langage leur sera inconnu. Cette technique ne convient donc, en général,
que pour des fichiers textes simples. De plus, cette solution ne convient pas dans un système multitâche et
multi-utilisateur, puisque un seul programme seulement peut accéder à l’imprimante à un instant donné.
Les systèmes d’impression ont donc pour principal but de résoudre ces problèmes. La multiplicité des
formats de fichiers et des langages d’imprimante est prise en charge par tout un jeu de programmes de
conversion que l’on appelle les filtres. Les filtres ne sont en fait rien d’autre que des programmes qui
reçoivent un fichier en entrée et qui fournissent la traduction de ce fichier dans un autre format en sortie.
Les systèmes d’impression LPRNG et CUPS fournissent un certains nombres de filtres, qui peuvent être
agencés afin de permettre l’impression de n’importe quel fichier sur l’importe quelle imprimante.
Enfin, en ce qui concerne le partage des ressources d’impression, les systèmes d’impression utilisent
généralement un mécanisme de files d’attente (« spool » en anglais). Tous les travaux d’impression
soumis sont placés dans une file d’attente, et attendent leur tour pour être envoyés à l’imprimante
associée à cette file. Une fois que l’impression est terminée, les travaux sont supprimés de la file. Ainsi,
un seul programme accède à l’imprimante : le sous-système d’impression. Notez qu’il est généralement
possible de définir plusieurs files d’attentes sur une même imprimante, selon la nature du travail à
effectuer. Par exemple, une file peut se charger des documents textes, et une autre des documents
graphiques en couleur. Bien entendu, le sous-système d’impression contrôle tous les accès à
l’imprimante et assure qu’un seul document est en cours d’impression à chaque instant.

181
 Chapitre 6. Administration du système de base

Le système d’impression LPRng

Le système d’impression LPRng est constitué d’un démon nommé « lpd » et d’un jeu de commandes
permettant de communiquer avec lui pour soumettre les travaux d’impression, visualiser ceux qui sont en
attente ou en cours d’impression et les annuler.

Le mécanisme des filtres APSFILTER

Sous Linux, le mécanisme de filtres de LPRng est généralement APSFILTER. Ce mécanisme est
profondément orienté vers le langage de description de pages PostScript, initialement inventé par Adobe
et que nombre d’imprimantes laser comprennent. En fait, il s’agit d’un véritable langage de
programmation, qui permet de programmer les périphériques dont la vocation est d’afficher ou
d’imprimer des documents. Techniquement parlant, PostScript permet d’obtenir une qualité d’impression
irréprochable, car c’est l’imprimante elle-même qui « dessine » la page à imprimer.
APSFILTER utilise donc un premier jeu de filtres pour convertir les fichiers à imprimer en PostScript
s’ils ne sont pas déjà dans ce format. Le langage PostScript apparaît donc comme le langage
d’impression universel, que toutes les imprimantes sont supposées comprendre...
Le problème, c’est que ce n’est pas le cas. En particulier, les imprimantes à jet d’encre ne comprennent
généralement pas le PostScript. Aussi APSFILTER utilise-t-il un second jeu de filtres, capables de
convertir le PostScript dans le langage graphique de l’imprimante (si l’imprimante n’est pas une
imprimante PostScript, bien entendu). APSFILTER utilise pour cela un « interpréteur PostScript ». Un
interpréteur PostScript est un programme capable de comprendre les fichiers PostScript et de les
convertir dans le format compris par l’imprimante. L’interpréteur couramment utilisé sous Linux est
GhostScript, parce que c’est un logiciel libre (cependant, la version courante est toujours commerciale).
Il est également capable d’afficher les fichiers PostScript sous XWindow, et de gérer la plupart des
imprimantes du marché.
L’avantage de cette technique est que toutes les imprimantes apparaissent comme étant des imprimantes
PostScript pour les programmes désirant imprimer. Ainsi, leur programmation est beaucoup plus simple,
puisqu’ils n’ont qu’un seul format à gérer. Bon nombre d’applications génèrent directement des fichiers
PostScript, qui sont donc envoyés directement à GhostScript pour l’impression définitive.

182
 Chapitre 6. Administration du système de base

Figure 6-3. Filtres d’impression et imprimantes PostScript

Comme on le voit, avec APSFILTER, le langage d’impression universel est le langage PostScript. Bien
entendu, cela est idéal si l’on dispose effectivement d’une imprimante PostScript, mais même dans le cas
contraire, les impressions se font parfaitement grâce à GhostScript.

Installation des filtres et configuration des files d’impression

Les distributions modernes fournissent toutes un outil permettant d’effectuer la configuration du
sous-système d’impression. Il est évidemment recommandé d’utiliser ces outils, car le résultat est assuré
et la vie en est d’autant plus facile. De plus, les distributions peuvent fournir des filtres complémentaires
que seuls ces outils connaissent et sont capables d’installer.
Si le jeu de filtres utilisé de votre distribution est APSFILTER, vous pourrez installer votre imprimante
manuellement en exécutant le programme SETUP du répertoire /usr/share/apsfilter/.
Ce programme est réellement affreux à utiliser car il s’agit en réalité d’un script, mais il effectue
correctement son travail. Dès son démarrage, il vous demande d’accepter la licence logicielle (la licence
GPL avec une forte invitation à envoyer une carte postale à l’auteur, qui les collectionne). La question
suivante est donc si vous désirez obtenir l’adresse postale de l’auteur. Une fois ces deux questions
passées, le programme d’installation commence réellement.
Le programme vous demande de confirmer les droits sur le répertoire des fichiers d’impression en cours,
puis, si vous le faites effectivement, si vous désirez compléter le fichier de configuration de LPRNG
/etc/printcap ou en créer un complètement nouveau. Vient ensuite le menu de configuration des
imprimantes :

183
 Chapitre 6. Administration du système de base

Figure 6-4. Filtres d’impression et imprimantes PostScript

La première option vous permet de choisir le pilote de l’imprimante, qui donc en général est un des
pilotes fournis avec l’interpréteur GhostScript. Vous devez sélectionner le pilote de votre imprimante ou,
à défaut, celui de l’imprimante qui s’en rapproche le plus. La deuxième option vous permet de
sélectionner l’interface de l’imprimante. Vous pourrez indiquer le port de l’imprimante ou, s’il s’agit
d’une imprimante réseau, la manière d’y accéder. Les autres options du menu quant à elles sont
relativement simples, et vous permettront respectivement de sélectionner le format du papier, la qualité et
le mode d’impression, ainsi que la résolution de l’imprimante.
Vous pourrez (et devriez) tester la configuration ainsi définie avec l’option ’T’. Si le résultat vous
convient, installez l’imprimante avec l’option ’I’. Vous pouvez installer plusieurs imprimantes ou
plusieurs files d’impression pour la même imprimante en répétant les étapes précédentes. Au final,
terminez l’installation avec l’option ’Q’, et envoyez une carte postale à l’auteur du logiciel.

Commandes d’impression
La commande d’impression de LPRng est la classique commande lpr (abréviation de l’anglais « off Line
PRint », ce qui signifie « impression différée »). Cette commande est très simple à utiliser, comme le
montre la syntaxe suivante :

lpr fichier

où fichier est le nom du fichier à imprimer. Cette commande se contente de placer le fichier à
imprimer dans un répertoire affecté à la file d’attente des travaux d’impression. Le travail d’impression
est ensuite effectué par le démon lpd, qui fait passer chaque fichier à imprimer à travers la série de filtres
pour le convertir dans le langage de l’imprimante, puis qui alimente l’imprimante.
La liste des travaux d’impression en attente peut être consultée avec la commande lpq. Chaque travail en
attente porte un numéro, grâce auquel on peut le manipuler. Entre autres opérations, il est possible de
l’abandonner à l’aide de la commande lprm.

184
 Chapitre 6. Administration du système de base

Enfin, pour consulter et contrôler l’état des files d’impression, on peut utiliser la commande lpc. Cette
commande peut prendre des options en ligne de commande afin de préciser l’opération à effectuer. Par
exemple, l’option status permet d’obtenir l’état de chacune des files d’impression. Les autres options
permettent d’arrêter le travail en cours, de le suspendre, de désactiver l’imprimante pour les travaux
suivants, et inversement de relancer les travaux d’impression sur cette file.

Description du fichier /etc/printcap

Le démon lpd utilise le fichier de configuration /etc/printcap pour déterminer l’ensemble des files
d’impression existantes et quels filtres doivent être utilisés. Ce fichier est généré automatiquement par les
utilitaires des distributions ou, à défaut, par le script d’installation d’APSFILTER. Toutefois, comme il
est bon de savoir ce qui se passe lorsqu’une commande d’impression est envoyée au démon lpd, une
brève description de ce fichier sera faite dans cette section.
Chaque file est décrite par une ligne du fichier /etc/printcap et une seule. Ces lignes sont constituées
de divers champs, séparés par des deux points (’:’). Comme ces lignes peuvent être relativement
longues, elles peuvent être réparties sur plusieurs lignes physiques en plaçant le caractère d’échappement
’\’ à la fin de chaque ligne, sauf la dernière.
Le premier champ de la description d’une file d’attente est une liste des noms sous lesquels cette file sera
connue. Les différents noms sont écrits les uns à la suite des autres, séparés par une barre verticale
(caractère ’|’).
Les champs suivants décrivent l’imprimante à utiliser, ainsi que les options générales de la file d’attente.
Ces champs utilisent tous la même syntaxe :

option = valeur

Il existe un grand nombre d’options, nombre d’entre elles sont facultatives. Cependant, il est impératif
que le démon lpd puisse trouver l’imprimante à utiliser. Par conséquent, il faut lui fournir au moins l’une
des deux options suivantes :

• l’option lp permet de spécifier le fichier spécial de périphérique auquel l’imprimante est connectée ;
• les options rm et rp permettent de spécifier respectivement le nom d’un serveur d’impression distant
(« remote » en anglais) et de l’imprimante à utiliser sur ce serveur (« remote printer »).
Le démon lpd doit également connaître le répertoire dans lequel les travaux en attente seront stockés
(répertoire dit de « spool »). Ce répertoire peut être défini avec l’option sd.
D’autres options peuvent être utiles, comme sh (cette option ne prend pas de valeur), qui permet de
supprimer la page de garde au début de chaque impression, et mx, qui permet de spécifier la taille
maximale des travaux d’impression soumis. Cette dernière option permet de fixer des quotas
d’impression selon la taille des documents, afin de donner la possibilité aux autres documents d’être
imprimés. Cette option utilise une syntaxe particulière :

mx#taille

où taille est la taille maximale autorisée, exprimée en kilo-octets. Le fait de spécifier une taille nulle
permet de supprimer ce contrôle.

185
 Chapitre 6. Administration du système de base

L’exemple ci-dessous correspond à la définition d’une file d’attente locale élémentaire :

ascii|lp:lp=/dev/lp:sd=/var/spool/lpd/ascii:mx#0:sh

Comme vous pouvez le constater, il n’y a aucune spécification des filtres d’impression à utiliser dans cet
exemple. Les travaux sont donc directement envoyés à l’impression, sans traduction préalable. Il est donc
nécessaire qu’ils soient déjà au format de l’imprimante. Si l’on veut utiliser des filtres d’impression, il
faut utiliser l’une des options if, cf, df, gf, nf, rf, tf ou vf. Chacune de ces options permet de
spécifier la ligne de commande d’un filtre d’impression spécifique. Le choix du filtre utilisé pour un
travail d’impression est effectué lors de l’appel à la commande lpr, à l’aide d’une option en ligne de
commande. Le filtre if est le filtre par défaut, il n’y a donc besoin d’aucune option pour l’utiliser. Les
autres filtres peuvent être sélectionnés respectivement avec les options -c, -d, -g, -n, -f, -t et -v.
Comme on le voit, le sous-système d’impression ne reconnaît pas automatiquement le format de fichier
utilisé. D’autre part, le nombre de filtres utilisables est limité à 8, ce qui peut ne pas suffire étant donné la
prolifération des formats de fichiers. Pour résoudre ce problème, APSFILTER utilise un filtre générique
(utilisé en tant que filtre par défaut) qui, lui, est capable de reconnaître le format du fichier à imprimer et
de le diriger vers un autre filtre ou une série de filtres. Comme on l’a vu ci-dessus, l’ultime filtre utilisé
est en général l’interpréteur GhostScript. Ainsi, il n’y a plus de limite sur le nombre de filtres utilisables,
et les filtres sont sélectionnés automatiquement en fonction de la nature du document à imprimer.

Le système d’impression CUPS

Le système d’impression CUPS a pour but de remplacer LPRng et d’offrir de nouvelles fonctionnalités.
En particulier, il est plus facile de configurer et d’ajuster les paramètres avancés des imprimantes. CUPS
permet une meilleure intégration dans un réseau hétérogène, car il implémente le protocole d’impression
réseau IPP (« Internet Printing Protocol »), qui est devenu un standard de fait pour tous les systèmes
d’exploitation. Couplé au logiciel Samba, il permet également d’accéder aux imprimantes des postes
Windows.
CUPS est constitué du démon cupsd, qui gère à la fois les requêtes d’impression effectuées via le
protocole d’impression IPP, qui est un protocole d’impression encapsulé dans des requêtes HTML (le
langage de description de pages Web utilisé sur Internet). Le démon cupsd étend même ce protocole
d’impression pour prendre en charge des pages Web de configuration, ce qui permet de réaliser
l’administration du système d’impression très simplement par l’intermédiaire d’une interface Web. Il est
ainsi possible de réaliser la configuration et la gestion des imprimantes, ainsi que des groupes
d’imprimantes sur lesquelles les travaux d’impression peuvent être répartis. Enfin, CUPS fournit les
fonctionnalités de base du système d’impression LPRng, en définissant automatiquement un fichier
/etc/printcap correspondant à sa propre configuration, et en fournissant un jeu de commandes lp
classiques redirigeant tous les traveaux d’impression vers lui.
CUPS utilise également un nouveau système de filtres, qui permettent d’éviter de passer
systématiquement par le format d’impression PostScript. Plusieurs filtres peuvent être utilisés pour
passer par différents formats intermédiaires. Le choix de ces filtres est déterminé en fonction du coût de
chaque conversion dans la chaîne de transformations du document vers le format final utilisé par
l’imprimante. On peut donc dire que CUPS est à la fois plus facile à configurer et plus performant que
LPRng, tout en restant compatible avec lui pour les applications.

186
 Chapitre 6. Administration du système de base

Le mécanisme des filtres de CUPS

CUPS utilise une architecture légèrement différente de celle de LPRng. Son système de filtres est plus
complexe et plus puissant, et ne nécessite pas un passage obligé par le langage d’impression PostScript.
En réalité, CUPS fournit utilise tout un jeu de filtres élémentaires capables de transformer un document
d’un format dans un autre. Tous ces filtres sont agencés pour effectuer la traduction complète du
document à imprimer dans le langage d’impression utilisé par l’imprimante. Contrairement à LPRng, les
formats intermédiaires ne cette fois sont ni uniques, ni forcément du PostScript.
Il est parfois possible de trouver plusieurs jeux de filtres distincts qui réalisent la conversion du document
dans le langage d’impression destination, en passant par différents formats intermédiaires. CUPS doit
donc effectuer un choix entre les différents jeux de filtres. Pour cela, il attribue un coût à chaque
conversion, et calcule le coût total de chaque jeu de filtres utilisable pour imprimer le document. Il
choisit ensuite le jeu de filtres qui a le coût total minimal, et garantit ainsi les performances du système
d’impression.
Bien entendu, certains de ces filtres utilisent le bon vieux GhostScript, et la plupart des gestionnaires
d’imprimantes sont en réalité des drivers créés pour GhostScript ou pour le logiciel de retouche d’images
The Gimp. CUPS requiert donc une version modifiée de l’interpréteur GhostScript, mais les distributions
l’installent automatiquement et cela ne pose pas de problème. Au final, l’impression des documents est
une opération très facile, et l’utilisateur ne voit rien de toutes les transformations effectuées sur les
documents par le mécanisme des filtres.
Enfin, contrairement à LPRng, CUPS donne la possibilité de fournir des paramètres complémentaires sur
les filtres d’impression, ce qui confère une grande souplesse au système d’impression. C’est pour cette
raison qu’il est recommandé d’utiliser CUPS si l’on désire faire des impressions couleur ou contrôler
finement les paramètres d’impression.

Configuration d’une imprimante CUPS

La manière la plus simple de configurer CUPS est d’utiliser son interface Web. Celle-ci est accessible à
l’aide de n’importe quel navigateur Internet, en utilisant l’adresse [Link] Lorsque
l’on désire se connecter au serveur Web de CUPS via cette interface, celui-ci exige une authentification
de l’administrateur. Vous devrez donc vous identifier en tant que root pour effectuer la configuration du
système d’impression.
La page Web affichée présente trois zones permettant de réaliser les principales opérations de
configuration du système d’impression.
L’ajout d’une imprimante se fait en cliquant sur le bouton « Add Printer ». Ce bouton ouvre une autre
page, dans laquelle il est possible de donner le nom de l’imprimante (champ « Name »), son
emplacement sur le réseau (champ « Location ») et sa description (champ « Description/ »). La
description permet de détailler la nature de l’imprimante et peut contenir n’importe quel texte. Le bouton
« Continue » permet de passer à l’écran suivant, qui fournit la liste des périphériques disponibles. Cette
liste contient tous les fichiers spéciaux de périphériques de votre système, ainsi que les protocoles
d’impression en réseau supportés par CUPS. La page suivante permet de sélectionner la marque de
l’imprimante, et la suivante son modèle. Le bonton « Continue » permet alors de terminer l’installation
de l’imprimante.
La configuration des imprimantes installées se fait en cliquant sur le bouton « Manage Printers ».
L’écran qui s’affiche contient les boutons « Print Test Page » (impression d’une page de test),

187
 Chapitre 6. Administration du système de base

« Stop Printer » (suspension des impressions), « Reject Jobs » (interdiction de soumettre de

nouveaux travaux d’impression), « Modify Printer » (modification de la définition de l’imprimante),
« Configure Printer » (configuration avancée de l’imprimante) et « Delete Printer »
(suppression de l’imprimante). La fonctionnalité de configuration avancée des imprimantes permet de
fixer les valeurs des paramètres du pilote d’impression, comme la résolution, la taille et le type de papier,
ainsi que les paramètres de correction des couleurs.
L’ajout d’un groupe d’imprimantes se fait en cliquant sur le bouton « Add Class ». Comme pour la
définition des imprimantes, le formulaire qui apparaît vous permet de décrire le groupe d’imprimantes.
L’écran suivant donne ensuite la possibilité d’indiquer les imprimantes qui font partie du groupe. Une
fois un groupe d’imprimantes défini, il est possible d’effectuer les tâches d’administration le concernant
à l’aide du bouton « Manage Classes ».

Les fichiers de configuration de CUPS

Les fichiers de configuration de CUPS sont généralement placés dans le répertoire /etc/cups/. Le
fichier le plus important est sans doute le fichier [Link], qui contient tous les paramètres de
configuration du démon cupsd. Ces paramètres sont nombreux et bien décrits dans la documentation de
cups, que l’on peut obtenir simplement en ouvrant un navigateur sur l’adresse
[Link] De plus, ce fichier est très bien commenté, aussi seules les
options les plus importantes seront-elles décrites ici.
Les principales options concernent la sécurité du système d’impression. Normalement, le démon
d’impression cupsd ne doit pas fonctionner sous le compte root, pour éviter de lui donner tous les droits.
Pour cela, il change d’identité lorsqu’il démarre et se place dans le compte utilisateur spécifié par
l’option User. De même, il se place dans le groupe utilisateur spécifié par l’option Group.
Généralement, les valeurs utilisées pour ces deux options sont l’utilisateur lp et le groupe sys, ce sont
donc leurs valeurs implicites.
Un autre option particulièrement importante est l’option Listen. Cette option permet d’indiquer au
démon cupsd sur quelles interfaces réseau il doit se mettre en écoute pour les clients désirant s’y
connecter. Il n’est généralement pas conseillé de laisser ouvert un port non utilisé lorsqu’on se connecte
à Internet, aussi est-il recommandé de configurer le démon cupsd pour qu’il n’écoute pas les requêtes
provenant d’autres machines que la machine locale. Pour cela, on utilisera la ligne suivante dans le
fichier de configuration [Link] :

Listen [Link]:631

Cette commande permet de ne répondre qu’aux requêtes provenant de la machine locale, sur le port
dédié au protocole d’impression IPP, à savoir le port 631. Bien entendu, vous pourrez ajouter d’autres
machines si vous disposez d’un réseau local, simplement en ajoutant d’autres options Listen. Notez
que l’usage de cette option est incompatible avec l’option Port, qu’il faut donc commenter au préalable,
faute de quoi cupsd ne répondra à aucune requête.

Note : Comme on le verra dans le chapitre sur la configuration réseau, l’adresse réseau [Link]
représente soi-même dans les communications réseau. Cela signifie ici que seuls les clients de la
machine locale pourront utiliser le système d’impression.

188
 Chapitre 6. Administration du système de base

Il est également possible de fixer des droits sur les différents répertoires de configuration de l’interface
Web, ainsi que sur les répertoires virtuels utilisés par le protocole IPP lorsque des requêtes sont faites par
les clients. Ainsi, il est possible de ne permettre l’impression que pour des clients qui vérifient certains
critères. Les règles définissant les droits d’accès aux répertoires sont indiquées dans des sections
Location, dont la syntaxe est similaire à celle des balises du langage XML. Par exemple, la section qui
décrit les droits d’accès au répertoire de configuration /admin est typiquement de la forme suivante :

<Location /admin>
AuthType Basic
AuthClass System
Order Deny,Allow
Deny From All
Allow From [Link]
</Location>

Vous constaterez que plusieurs informations sont données dans ce type de section. Premièrement, le type
d’authentification utilisé est spécifié à l’aide de l’option AuthType. Les différentes valeurs possibles
pour cette option sont décrites dans le tableau suivant :

Valeur Signification
None Aucune identification n’est faite.
Basic L’identification est réalisée via les mécanismes d’authentification HTML classique.
cupsd attend ici un nom d’utilisateur et un mot de passe Unix classiques, qui
doivent donc exister dans le fichier /etc/passwd. Notez qu’avec ce mode
d’authentification, le mot de passe est envoyé en clair du navigateur Internet utilisé
pour réaliser la connexion vers le serveur Web du démon cupsd. Cela signifie que
si la communication ne se fait pas en local, une tierce personne pourrait voir le nom
d’utilisateur et le mot de passe en écoutant les communications résau. Ce mode
d’authentification est donc extrêmement dangereux.
Digest L’identification se fait de la même manière que pour le mode Basic, mais le nom
de l’utilisateur et le mot de passe ne sont pas transmis en clair. Au lieu de cela,
seules les signatures de ces informations, obtenues à l’aide d’une fonction de
chiffrement à sens unique, sont transmises sur le réseau. Il n’est donc plus possible
de déterminer le nom de l’utilisateur et son mot de passe en clair. De plus, les mots
de passe utilisés ne sont pas forcément les mêmes que ceux du système, et ils sont
stockés de manière indépendante dans le fichier passwd.md5 du répertoire
/etc/cups/. Ces mots de passe peuvent être ajoutés avec la commande
lppasswd. Ce mode d’authentification est donc plus sûr, notez toutefois qu’il reste
possible pour un attaquant de se connecter avec le nom de l’utilisateur et son mot
de passe chiffré une fois ceux-ci capturés.

Pour chaque méthode d’authentification, il est possible de préciser le critère utilisé pour vérifier les droits
d’accès du client. Ce critère est fixé par l’option AuthClass. Celle-ci peut prendre les valeurs
suivantes :

189
 Chapitre 6. Administration du système de base

Valeur Signification
Anonymous Aucune critère n’est utilisé, tout le monde peut accéder à la page spécifiée dans la
directive Location. Il va de soi que l’utilisation de ce critère avec les autres modes
d’authentification que None est absurde.
User L’utilisateur authentifié doit être un utilisateur du système Unix sous-jacent.
System L’utilisateur authentifié doit être membre du groupe système. Ce groupe est, par
défaut, le groupe sys, mais il peut être modifié à l’aide de l’option SystemGroup
du fichier de configuration [Link].
Group L’utilisateur authentifié doit être membre du groupe spécifié par l’option
AuthGroupName du fichier de configuration [Link]. Ce groupe doit être un
des groupes du système Unix sous-jacent, sauf si le mode d’authentification
Digest est utilisé. En effet, dans ce cas, le groupe de l’utilisateur doit être celui
stocké avec son mot de passe dans le fichier de mots de passe de CUPS
(c’est-à-dire le fichier /etc/cups/passwd.md5).

Les mots de passe cups utilisés pour l’authentification dans le mode d’authentification Digest peuvent
être ajoutés à l’aide de la commande lppasswd. Cette commande permet également de fixer le groupe de
l’utilisateur lorsque le critère d’accès utilisé est le critère Group. La syntaxe générale de cette commande
est la suivante :

lppasswd [-g groupe] -a utilisateur

où groupe est le nom de groupe de l’utilisateur (uniquement utilisé pour le mode d’authentification
Digest) et utilisateur est son nom d’utilisateur. À l’issue de cette commande, lppasswd demande
deux fois le mot de passe de l’utilisateur et met à jour le fichier passwd.md5.
La deuxième série d’informations fournie dans les sections Location sont les droits sur les machines
capables d’accéder à la page Web. L’option Order indique l’ordre d’évaluation des directives suivantes.
Il est recommandé d’interdire en premier, et de regarder ensuite si la machine cliente a le droit de se
connecter. C’est ce qui est fait dans l’exemple précédent, avec les options « Deny From All » et
« Allow From [Link] », qui indiquent que seule la machine locale a le droit de se connecter au
serveur d’impression.

Configuration du lancement automatique des tâches

Il est possible de déclencher l’exécution de certaines opérations à intervalles réguliers sous Linux. Ces
opérations sont définies pour le système et pour chaque utilisateur. Elles sont enregistrées dans des
fichiers de configuration indiquant le moment où elles doivent être déclenchées, et quelle action elles
doivent réaliser. Les opérations définies pour le système sont stockées dans le fichier de configuration
/etc/crontab. Des commandes additionnelles peuvent être définies dans les répertoires
/etc/cron.d/, /etc/[Link]/, /etc/[Link]/ et /etc/[Link]/. Par ailleurs,
les fichiers de configuration des utilisateurs sont stockés dans le répertoire /var/cron/tab/, sous le
nom de chaque utilisateur. Il est bien entendu possible d’éditer ces fichiers en tant que root, mais ce n’est

190
 Chapitre 6. Administration du système de base

pas recommandé. En effet, la commande crontab permet d’installer, de supprimer et de consulter les
fichiers crontab de chaque utilisateur, et ce de manière sûre.
La commande crontab peut être utilisée pour afficher le contenu du fichier de configuration de
l’utilisateur qui l’appelle, à l’aide de l’option -l :

crontab -l

Elle permet également de supprimer ce fichier, à l’aide de l’option -r :

crontab -r

Enfin, l’option -e permet d’éditer le fichier crontab, à l’aide de l’éditeur spécifié dans la variable
d’environnement VISUAL ou EDITOR. Par défaut, l’éditeur vi sera utilisé.
En tant qu’administrateur du système, il est possible de modifier les paramètres pour n’importe quel
utilisateur. Pour cela, il faut préciser le login de l’utilisateur avec l’option -u. Il est recommandé
d’utiliser également l’option -u si l’on a effectué un su, car la commande crontab peut ne pas pouvoir
déterminer l’utilisateur qui l’a appelé dans ce cas.
Le format des fichiers crontab est suffisamment riche pour permettre de spécifier avec finesse les
conditions d’exécution des opérations programmées. En général, le début du fichier contient la définition
de variables d’environnement utilisées par crontab. La suite du fichier est réservée aux commandes
programmées. Chaque programmation est réalisée sur une ligne du fichier crontab. Les lignes
contiennent 5 champs spécifiant la date et l’heure à laquelle la commande doit être exécutée, un nom
d’utilisateur éventuel et la commande elle-même. Le nom d’utilisateur ne doit être spécifié que dans le
fichier /etc/crontab, qui définit les commandes du système. Il spécifie alors au nom de quel
utilisateur la commande doit être exécutée. Pour les fichiers crontab propres à chaque utilisateur, il n’est
bien entendu pas nécessaire d’indiquer ce nom.
Les 5 champs de la partie décrivant la date d’exécution de la commande fournissent respectivement les
informations suivantes :

• les minutes (comprises entre 0 et 59) ;

• les heures (comprises entre 0 et 23) ;
• le jour dans le mois (compris entre 0 et 31) ;
• le mois (compris entre 0 et 12, ou indiqué par les trois premières lettres du nom du mois en anglais) ;
• le jour dans la semaine (compris entre 0 et 7, ou indiqué par les trois premières lettres du nom du jour
en anglais).
Les numéros de mois 0 et 12 correspondent à Janvier, et les numéros de jours 0 et 7 correspondent au
Dimanche.
La commande sera exécutée à chaque fois que le jour, le mois, l’heure et les minutes du système
correspondront avec ces 5 champs. Il suffit que l’une des spécifications du jour corresponde pour que la
commande soit exécutée (c’est-à-dire qu’elle est exécutée une fois pour le jour du mois et une fois pour
le jour de la semaine si ces deux champs sont spécifiés).

191
 Chapitre 6. Administration du système de base

Il est possible d’utiliser un intervalle de valeurs pour chacun de ces champs, en indiquant la première et
la deuxième valeur, séparées d’un tiret. Il est également possible de faire une liste de valeurs et
d’intervalles, en séparant chaque donnée par une virgule. Si l’on veut spécifier toutes les valeurs
possibles pour un champ, on peut utiliser le caractère ’*’. Enfin, il est possible d’indiquer que la
commande doit être exécutée toutes les n valeurs pour chaque champ. Pour cela, il suffit de faire suivre le
champ d’une barre oblique de division (’/’) et du nombre n. Ainsi, si l’on trouve l’expression « */3 »
pour les heures, la commande sera exécutée toutes les trois heures.
La spécification de la commande doit être faite sur une seule ligne. Le caractère de pourcentage (’%’) a
une signification spéciale, sauf s’il est précédé d’un antislash (’\’). Les données qui suivent le premier
pourcentage sont passées telles quelles dans l’entrée standard de la commande. Les caractères
pourcentages suivants sont interprétés comme des saut de lignes (donc une validation). Ainsi, la
commande suivante :

rm -i [Link]%y%

permet de supprimer le fichier [Link] et de répondre ’y’ à la commande rm. Le caractère ’y’ est
passé ici dans le flux d’entrée standard de rm.
Comme vous pouvez le voir, le fichier /etc/crontab du système permet de programmer des opérations
périodiques, comme les sauvegardes, la destruction des fichiers temporaires, ou toute autre tâche de
maintenance. Ne vous étonnez donc pas si votre ordinateur semble s’activer tout seul régulièrement, à
heure fixe (par exemple, sur le coup de 11 heures ou minuit). C’est le fonctionnement normal de votre
système, qui s’occupe de toutes les tâches ménagères qu’il s’est réservé pour une heure où normalement
tout le monde dort...
Les utilisateurs peuvent également définir leur propre crontab pour effectuer les opérations périodiques
qu’il désirent. Par exemple, ils peuvent programmer une commande qui leur rappellera un rendez-vous.

Gestion de l’énergie

Généralités sur la gestion de l’énergie

La gestion de l’énergie sur les ordinateurs se fait classiquement via l’une des interfaces APM ou ACPI.
APM (abréviation de « Advanced Power Management ») est la plus vieille, et s’appuyait essentiellement
sur le BIOS pour prendre en charge la gestion de l’énergie. Elle peut encore n’être que la seule
possibilité fonctionnelle sur la plupart des vieilles machines, mais est destinée à être remplacé par
l’interface ACPI (abréviation de « Advanced Configuration and Power Interface »), développée par Intel.
Cette nouvelle interface, bien que souffrant manifestement encore de quelques défauts de jeunesse, est
nettement plus souple. En effet, elle se base sur un tout autre principe qu’APM, puisqu’elle permet cette
fois de laisser le système prendre en charge la gestion de l’énergie. Étant donné que l’interface APM est
vouée à disparaître, et sachant qu’on ne peut utiliser qu’une seule de ces interfaces, seule l’interface
ACPI sera présentée dans ce document.
Le principe de fonctionnement de l’ACPI est le suivant. Le BIOS contient une table définie par le
fabricant de l’ordinateur qui décrit le matériel fourni, et définit les opérations de base permettant de gérer
l’énergie. Ces opérations sont définies dans un langage standard spécifié par Intel. Le système

192
 Chapitre 6. Administration du système de base

d’exploitation est en charge de lire ces informations et d’interpréter les opérations définies dans la table
ACPI. Ainsi, c’est bien le système d’exploitation qui se charge de la gestion de l’ordinateur.
L’implémentation de l’interpréteur ACPI de Linux est l’implémentation de référence réalisée par Intel.
Dans le meilleur des mondes, il ne devrait donc y avoir aucun problème pour utiliser l’ACPI sous Linux.
Malheureusement, bon nombre de BIOS fournis par les fabricants sont bogués et ne respectent pas la
norme ACPI. En effet, l’implémentation ACPI de Microsoft est incorrecte et son interpréteur accepte des
erreurs de syntaxe que leur compilateur ACPI laisse passer (ce qui somme toute est cohérent, ils ne
pouvaient pas faire moins sans que le résultat ne cesse de fonctionner). Ce n’est pas le cas de
l’interpréteur ACPI de Linux puisque, par définition, elle ne peut se conformer à celle de Microsoft et
être compatible bogue à bogue.
Le résultat est, hélas, catastrophique, puisque les fonctionnalités ACPI de ces machines ne peuvent pas
être utilisées totalement sous Linux. Microsoft aurait voulu exploiter sa position dominante et corrompre
le standard d’Intel pour isoler les concurrents qu’il n’aurait pas fait mieux (avis personnel). La seule
solution est de récupérer la table ACPI du BIOS, de la désassembler pour en obtenir le code source, et de
tenter de la recompiler avec le compilateur d’Intel (pas celui de Microsoft). Les erreurs apparaissent
donc et peuvent ainsi être corrigées. Une fois la table ACPI corrigée, il faut soit convaincre le fabricant
de l’ordinateur de mettre un nouveau BIOS à disposition, soit paramétrer le noyau pour qu’il charge cette
table au lieu de prendre celle du BIOS pour argent comptant. Corriger une table ACPI boguée est une
opéraiton extrêmement technique et absolument hors sujet, et faire en sorte que le noyau l’utilise
nécessitait de patcher les sources du noyau jusqu’à la version 2.6.9. À présent, cela est faisable
directement à partir du programme de configuration du noyau, mais je n’en parlerais pas plus ici. Vous
pouvez consulter le site web de l’ACPI ([Link] pour plus de détails à ce sujet. Si
vous rencontrez des problèmes de ce type, je vous suggère de trouver un Linuxien confirmé, ou de faire
une croix sur les fonctionnalités ACPI qui ne sont pas opérationnelles sous Linux.

Configuration de la gestion de l’énergie

La prise en charge des fonctionnalités de gestion d’énergie au niveau du noyau se fait simplement en
activant les options correspondantes dans la configuration du noyau. Elles sont regroupées dans le menu
« Power management options (ACPI, APM) ». Seules les plus intéressantes sont listées ci-dessous :

• l’option « Power Management support » permet d’activer les fonctionnalités de mise en veille du
système sur disque. Il est possible ainsi de sauvegarder l’ensemble du système sur la partition
d’échange du système, et de le redémarrer et le restaurer (options « Suspend-to-Disk Support »
et « Default resume partition »). Cette option permet également d’activer le menu de gestion
de l’énergie par APM.
• le menu « ACPI (Advanced Configuration and Power Interface) Support » permet d’activer les
fonctionnalités ACPI. Il donne accès à l’option « ACPI Support », qui elle-même donne accès à de
nombreuses options pour les différents composants gérant l’ACPI.
• le menu « CPU Frequency scaling » donne accès à l’option « CPU Frequency scaling ». Cette
option permet d’activer la gestion des fonctions d’économie d’énergie des processeurs pour les
portables. Ces processeurs sont en effet capables de changer de fréquence d’exécution pour, lorsque
l’ordinateur est utilisé pour des tâches peu consommatrices de ressources, abaisser la consommation de
l’ordinateur et augmenter l’autonomie du système lorsqu’il fonctionne sur batterie. Les sous-options
permettent de spécifier les politiques de gestion de l’énergie ainsi que le type de processeur utilisé.

193
 Chapitre 6. Administration du système de base

Les fonctionnalités ACPI prises en charge par le noyau sont exposées à l’utilisateur au travers des
systèmes de fichiers virtuels /proc/ et /sys/.
Le répertoire /proc/acpi/ contient essentiellement un sous-répertoire pour chaque composant ACPI
pris en charge par le noyau. Dans chacun de ces sous-répertoires, vous trouverez des fichiers contenant
les informations courantes sur ces différents sous-systèmes.
Le sous-répertoire /sys/power/ vous permettra quant à lui de modifier le niveau d’économie d’énergie
utilisé par votre ordinateur. En particulier, le fichier state vous permettra de le suspendre ou de le
mettre en veille. Pour cela, il vous faut simplement écrire le mode désiré dans ce fichier avec la
commande echo :

echo -n mode > /sys/power/state

où mode est le mode désiré. Vous obtiendrez la liste des modes acceptés par Linux en lisant ce fichier
avec la commande cat :

cat /sys/power/state

En général, les modes standby, mem et disk sont disponibles. standby correspond à la mise en veille
simple de l’ordinateur. mem permet de réaliser une suspension du système en mémoire, et correspond
donc à un niveau d’économie d’énergie supérieur. Enfin, disk permet d’éteindre complètement
l’ordinateur après avoir stocké son état dans la partition d’échange. Cette commande correspond au
niveau maximum d’économie d’énergie.

Note : Ces fonctionnalités sont relativement expérimentales et peuvent ne pas toutes fonctionner.
Généralement, seul la suspension sur disque semble fonctionner, souvent sous condition que
certains gestionnaires de périphériques soient déchargés avant la mise en veille.

Si vous disposez d’un portable, il est probable que votre processeur soit capable de fonctionner à
différentes fréquences. Il est possible de lire la fréquence courante et de la modifier par l’intermédiaire
des fichiers du répertoire /sys/devices/system/cpu/cpu0/cpufreq/. La fréquence courante peut
être lue via le fichier cpuinfo_cur_freq. Il n’est pas possible de modifier directement cette valeur.
Toutefois, le noyau donne la possibilité de la modifier via la politique de gestion d’énergie via le fichier
scaling_governor. Les valeurs possibles pour ce fichier peuvent être lues dans le fichier
scaling_available_governors.

Généralement, les politiques disponibles sont powersave et performance. Ces politiques permettent
respectivement de changer la fréquence du processeur vers les fréquences indiquées dans les fichiers
scaling_min_freq et scaling_max_freq. Ce sont donc dans ces fichiers que l’on pourra définir les
fréquences utilisables. La liste des fréquences accessibles est fournie par le fichier
scaling_available_frequencies.

194
 Chapitre 6. Administration du système de base

Le démon ACPI
Le noyau expose les fonctionnalités de surveillance de l’ordinateur de l’interface ACPI via le fichier
spécial de périphérique /proc/acpi/event. Dès qu’un événement se produit (passage de
l’alimentation sur batterie pour un portable, hausse anormale de la température du processeur, appui sur
le bouton de mise en marche / arrêt, etc.), une ligne signalant cet événement est ajoutée à ce fichier
virtuel.
Les applications ne doivent pas lire ce fichier directement, cette tâche étant normalement attribuée au
démon acpid. Ce démon surveille le fichier d’événement du noyau et fournit un mécanisme de
notification plus générique (c’est à dire moins spécifique à Linux) aux applications. Ainsi, les
applications peuvent se connecter au démon ACPI et être prévenue des événements que le noyau émet.
Le démon ACPI permet aussi de programmer des actions en réponse aux événements ACPI. Pour cela, il
consulte les fichiers de configuration placés dans le répertoire /etc/acpi/events/ et exécute les
actions qui y sont enregistrées.
Ces actions sont définies par des paires de lignes evénément / action permettant de renseigner, pour
chaque type d’événement, l’action à effectuer. Les lignes de définition des événements utilisent des
expressions rationnelles pour sélectionner les événements ou les groupes d’événements associés à
l’action. Les lignes d’action quant à elles permettent d’indiquer la ligne de commande à exécuter en cas
d’apparition de ces événements.
Par exemple, le fichier de configuration par défaut capte l’ensemble des événements ACPI et les passe
aux script /etc/acpi/acpi_handler.sh à l’aide de ces deux simples lignes :

event=.*
action=/etc/acpi/acpi_handler.sh %e

L’expression rationnelle utilisée dans la ligne de définition des événements signale que toute chaîne de
caractères doit correspondre. L’action en réponse est l’exécution du script acpi_handler.sh. La chaîne de
caractères complète définissant l’événement est passée en premier paramètre et est représentée par le
symbole %e.
Si les événements intéressants étaient tous les événements concernant le bouton d’alimentation de
l’ordinateur, l’expression rationnelle utilisée aurait été la suivante :

event=button power.*

Comme vous pouvez le constater, le format utilisé pour les descriptions des événements envoyés par le
noyau doit être connu pour pouvoir écrire les expressions rationnelles devant les sélectionner. Ces
descriptions sont envoyées par le script par défaut acpi_handler.sh dans les fichiers de traces du
système. Vous pourrez donc les y trouver après avoir généré les événements ACPI corresondants.
Pour donner un exemple, voici comment ce script peut être modifié afin de faire en sorte que la fermeture
du couvercle d’un portable le mette en veille immédiatement sur disque :

#!/bin/sh

# Ajoute / à la liste des séparateurs pour le découpage de la ligne de commande :

IFS=${IFS}/
set $@

195
 Chapitre 6. Administration du système de base

case "$1" in
button)
case "$2" in
power) /sbin/init 0
;;
# Traite l’événement de fermeture du couvercle :
lid)
# Vérifie que le couvercle est fermé :
grep -q "close" /proc/acpi/button/lid/LID/state
if [ $? -eq 0 ] ; then
# Met en veille prolongée l’ordinateur :
/usr/sbin/[Link] disk
fi
;;
# Trace les événements de type "bouton" non traités :
*) logger "ACPI action $2 is not defined"
;;
esac
;;
# Trace tous les autres événements non traités :
*)
logger "ACPI group $1 / action $2 is not defined"
;;
esac

Ce script capte l’événement lid (« couvercle » en anglais) et vérifie l’état du capteur de fermeture du
couvercle, accessible via le fichier d’état /proc/acpi/button/lid/LID/state (l’emplacement de ce
fichier peut varier selon les ordinateurs). Si ce fichier indique que le couvercle est fermé, le script
utilitaire [Link] est appelé pour mettre en veille l’ordinateur.
Ce dernier script utilise le fichier /sys/power/state pour effectuer cette mise en veille :

#!/bin/sh

# Stocke l’heure système (pour mise à jour de /etc/adjtime) :

hwclock --systohc

# Suspend le système et sur disque (méthode sûre) :

echo -n $1 > /sys/power/state

# Rétablit l’heure système :

hwclock --hctosys

Comme vous pouvez le constater, il est nécessaire de prendre en compte l’horloge système avant et après
une suspension. En effet, sans cela, l’horloge système reprendrait exactement à la date de la suspension
lors du réveil. Le stockage de l’heure courante avant suspension est également nécessaire, afin de
maintenir le fichier de configuration /etc/adjtime cohérent.

Note : Une autre solution aurait été de faire le test sur l’état du bouton dans le script de suspension
et d’appeler celui-ci directement en réponse à l’événement « button lid ».

196
Chapitre 7. Notions de compilation et
configuration du noyau
Ce chapitre présente les notions de base de compilation et de fichiers sources de programmes. Il est
certain que le lecteur de ce document n’a pas forcément l’intention de programmer sous Linux,
cependant, il est nécessaire de connaître les notions qui vont être décrites ici. En effet, il n’est pas rare,
voire il est même courant, d’avoir à recompiler une application lorsqu’on travaille avec Linux. Cela n’est
pas étonnant, quand on sait que toute bonne installation passe par la recompilation du noyau de Linux !
La raison de cet état de fait provient sans nul doute du fait que la licence GNU impose de fournir les
fichiers sources aux utilisateurs d’une part, et que le langage C et Unix sont historiquement fortement
liés.
Nous allons commencer par donner la définition des notions de base et les étapes intervenant dans le
processus de génération des fichiers binaires des programmes. Nous verrons ensuite comment installer
(et compiler !) la suite de compilateurs GCC du projet GNU, et nous présenterons les étapes intervenant
dans la compilation et l’installation d’un nouveau noyau. Ces informations pourront être utiles pour la
lecture du chapitre traitant de la configuration du matériel puisque, bien souvent, la prise en charge d’un
périphérique nécessite la compilation de ses pilotes au niveau du noyau.

Notions de base

Définition des termes

Le langage naturel est le langage que les êtres humains utilisent pour communiquer, soit oralement, soit
par écrit. Le langage naturel est très riche : il utilise des constructions grammaticales et syntaxiques
complexes, et il dispose d’un vocabulaire très étendu. Il permet donc d’exprimer la plupart des idées
humaines, et c’est bien sa fonction. En revanche, il n’est pas rigoureux, dans le sens où il laisse la porte
ouverte à un grand nombre d’ambiguïtés. Ce qui n’est pas dit est souvent sous-entendu, et c’est donc
pratiquement entre les mots que se trouve le sens du discours. Il n’est ainsi pas rare de pouvoir
interpréter une même phrase différemment, selon le contexte socioculturel, géographique ou temporel
dans lequel elle est dite. Les jeux de mots utilisent cette caractéristique à merveille. La conséquence est
que l’on ne peut pas utiliser facilement le langage naturel pour décrire rigoureusement, voire
mathématiquement, quelque chose.
Un langage formel est, au contraire, un langage restreint, qui ne dispose que de très peu de constructions
syntaxiques et d’un vocabulaire très limité. La caractéristique principale des langages formels est qu’ils
sont rigoureux, une expression ou une phrase donnée peut être validée selon les règles de syntaxe qui
doivent être respectées. Tout texte écrit dans un langage formel est donc soit valide, soit invalide.
En définissant une association entre les constructions d’un langage formel et un jeu de concepts limité, il
est possible de donner une sémantique à un langage formel. Cette sémantique donne la possibilité de
qualifier de « vraie » ou de « fausse » les assertions écrites dans le langage formel (on notera qu’une
expression peut être valide du point de vue de la syntaxe mais sémantiquement fausse).
Un langage formel permet donc d’exprimer avec précision, sans aucune ambiguïté possible, une idée
basée sur les concepts qu’il utilise. Les notations mathématiques constituent un langage formel par

197
 Chapitre 7. Notions de compilation et configuration du noyau

excellence.

Note : Par exemple, l’expression mathématique « x=1 » est toujours valide, c’est une simple
équation. En revanche, elle n’est pas toujours vraie, cela dépend de la valeur de x. En particulier, si
x représente 3, on a « 3 = 1 », ce qui est valide, mais faux. Notez bien la différence.

Un langage de programmation est un langage formel qui permet de définir les tâches qu’un ordinateur
doit effectuer, et de décrire les objets informatiques sur lesquels il doit travailler. Un langage de
programmation est donc un code, et tout programme doit être écrit dans un tel langage. Pratiquement, les
langages de programmation sont des langages très simples, disposant de constructions du type « si ...
alors ... » ou « pour chaque ... fait ... ». Les programmes étant écrits avec de tels
langages, il est clair qu’un programme ne fait que ce qui a été écrit : ni plus, ni moins. Il faut donc tout
dire à l’ordinateur quand on écrit un programme, ce qui en général est relativement fatigant et compliqué.
C’est le prix à payer pour la rigueur de l’informatique : l’ordinateur ne se trompe jamais, parce qu’il ne
fait qu’obéir aux ordres donnés dans un langage formel (donc précis). Celui qui se trompe, c’est en
général le programmeur, et assez couramment l’utilisateur.

Note : Notez qu’un programme est un texte valide s’il vérifie la grammaire du langage formel dans
lequel il est écrit. Cela ne l’empêchera pas de faire n’importe quoi si on l’exécute. Un programme
« vrai » est donc un programme syntaxiquement correctement écrit et qui en plus fait ce que l’on
désire qu’il fasse. Il n’y en a pas beaucoup... surtout que dans bien des cas, on ne s’est jamais posé
clairement la question de savoir ce que doivent faire les programmes que l’on écrit !

Le C est un langage de programmation relativement simple, qui se trouve sur tous les types d’ordinateurs
et de systèmes d’exploitation. Les programmes sont plus difficile à écrire en C que dans d’autres
langages de programmation, mais ils sont plus performants. Le C est très utilisé pour écrire les systèmes
d’exploitation : le noyau Linux lui-même est écrit en C. Le C++ est un langage plus évolué, qui est
dérivé du C. Il est beaucoup plus riche, et il permet d’écrire des programmes plus compliqués et de les
faire évoluer plus facilement. Bien que plus lents que ceux écrits en C, les programmes écrits en C++
sont toujours très performants par rapport à ceux écrits dans d’autres langages.
Les programmes sont en général écrits dans un certain nombre de fichiers. Ces fichiers sont appelés les
fichiers sources, du fait qu’ils sont à l’origine du programme. Le texte de ces fichiers est appelé le code
source, ou plus simplement le code.
Il va de soi que le code source est écrit dans un langage de programmation, qui n’est pas compréhensible
tel quel par le matériel de l’ordinateur. Pour exécuter un programme à partir de son code source, il n’y a
que deux solutions :

• disposer d’un autre programme, nommé interpréteur, capable de lire le code source et d’effectuer les
opérations décrites dans le code source ;
• disposer d’un autre programme, nommé compilateur, capable de traduire le code source en langage
binaire, qui sera alors directement exécutable par l’ordinateur.

Les programmes interprétés sont fatalement relativement lents, puisque l’interpréteur doit analyser en
permanence les fichiers sources pour le traduire en opération à exécuter à la volée.

198
 Chapitre 7. Notions de compilation et configuration du noyau

Figure 7-1. Interprétation d’un programme

En revanche, les programmes compilés sont beaucoup plus rapides à l’exécution, puisque la phase
d’analyse du code source a été réalisée au préalable et se fait en dehors de la phase d’exécution. Ces
programmes peuvent donc s’exécuter nativement, sans être ralenti par l’interpréteur.

Figure 7-2. Compilation et exécution d’un programme

Note : Si vous avez bien suivi, on se trouve face au problème de l’œuf et de la poule. En effet, les
interpréteurs et les compilateurs sont eux-mêmes des programmes écrits dans un langage
informatique. Quel est donc le premier compilateur ou interpréteur ? Ce problème a effectivement dû
être résolu au début de l’informatique, de la manière la plus simple : les premiers programmeurs
entraient directement le langage machine en binaire dans les ordinateurs (via les câblages ou les
cartes perforées...). Quand on sait le travail que cela représentait, et le nombre d’erreurs que cela a
pu générer, on comprend facilement pourquoi les compilateurs et les interpréteurs font partie des
tous premiers programmes qui ont été développés...

Dans les systèmes Unix, les deux types de programmes existent. Les programmes interprétés constituent
ce que l’on appelle des scripts. Le système utilise le shell pour les interpréter. La plupart des opérations
d’administration du système utilisent des scripts, car il est toujours plus facile d’écrire et de tester un
script que d’écrire un programme en C. Les programmes compilés sont notamment le noyau lui-même,

199
 Chapitre 7. Notions de compilation et configuration du noyau

le shell, les commandes de base et les applications. Ce sont eux qui en fin de compte effectuent le travail,
et ils sont souvent appelés à partir de scripts. Nous avons déjà vu des exemples de scripts lors de la
configuration du système. Pour l’instant, nous allons nous intéresser au langage C et au processus de
compilation.
La compilation est l’opération qui consiste à lire un fichier source et à le traduire dans le langage binaire
du processeur. Ce langage est absolument incompréhensible par les êtres humains, cependant, il existe un
langage de programmation qui permet de coder directement le binaire : il s’agit de l’assembleur.
En général, le processus de compilation génère un fichier binaire pour chaque fichier source. Ces fichiers
binaires sont nommés fichiers objets, et porte de ce fait l’extension « .o » (ou « .obj » dans les systèmes
Microsoft). Comme un programme peut être constitué de plusieurs fichiers sources, il faut regrouper les
fichiers objets pour générer le fichier exécutable du programme, fichier que l’on appelle également le
fichier image en raison du fait que c’est le contenu de ce fichier qui sera chargé en mémoire par le
système pour l’exécuter et qu’il contient donc l’image sur disque des instructions des programmes en
cours d’exécution. L’opération de regroupement des fichiers objets pour constituer le fichier image
s’appelle l’édition de liens, et elle est réalisée par un programme nommé le linker (éditeur de liens en
français). Ce programme regarde dans tous les fichiers objets les références partielles aux autres fichiers
objets et, pour chaque « lien » ainsi trouvé, il complète les informations nécessaires pour en faire une
référence complète. Par exemple, un fichier source peut très bien utiliser une fonctionnalité d’un autre
fichier source. Comme cette fonctionnalité n’est pas définie dans le fichier source courant, une référence
partielle est créée dans le fichier objet lors de sa compilation, mais il faudra tout de même la terminer en
indiquant exactement comment accéder à la fonctionnalité externe. C’est le travail de l’éditeur de liens,
lorsqu’il regroupe les deux fichiers objets.
Certains fichiers objets sont nécessaires pour tous les programmes. Ce sont notamment les fichiers objets
définissant les fonctions de base, et les fonctions permettant d’accéder au système d’exploitation. Ces
fichiers objets ont donc été regroupés dans des bibliothèques (également couramment appelées
« librairies »), que l’on peut ainsi utiliser directement lors de la phase d’édition de liens. Les fichiers
objets nécessaires sont alors lus dans la bibliothèque et ajoutés au programme en cours d’édition de liens.
Les bibliothèques portent souvent l’extension « .a » (ou « .lib » dans les systèmes Microsoft).

Figure 7-3. Processus de génération d’un exécutable

Malheureusement, la solution consistant à stocker dans des bibliothèques les fonctions les plus utilisées
souffre de la duplication du code contenu dans ces bibliothèques dans tous les programmes, d’où une

200
 Chapitre 7. Notions de compilation et configuration du noyau

perte de place considérable. De plus, la mise à jour d’une bibliothèque nécessite de refaire l’édition de
liens de tous les programmes qui l’utilisent, ce qui n’est pas réalisable en pratique. C’est pour cela que
les bibliothèques dynamiques ont été crées : une bibliothèque dynamique n’est pas incluse dans les
fichiers des exécutables qui l’utilisent, mais reste dans un fichier séparé. Les bibliothèques sont
regroupés dans un répertoire bien défini du système de fichiers, ce qui permet de les partager entre
différents programmes. Ainsi, la mise à jour d’une bibliothèque peut se faire sans avoir à toucher tous les
programmes qui l’utilisent. Le problème est cependant que l’édition de liens reste incomplète, parce que
les références aux objets des bibliothèques dynamiques sont toujours externes. Il existe donc un
programme spécial, l’éditeur de liens dynamiques (« ld », pour « Link Dynamically »), qui résout les
dernières références incomplètes lors du chargement de chaque programme. Les bibliothèques
dynamiques portent l’extension « .so » (pour « Shared Object »), ou « .dll » dans les systèmes Microsoft
(pour « Dynamic Link Library »).
Évidemment, le chargement des programmes est un peu plus lent avec les bibliothèques dynamiques,
puisqu’il faut réaliser l’édition de liens dynamiques lors de leur lancement. Cependant, ce processus a été
optimisé, et les formats de fichiers binaires utilisés contiennent toutes les informations précalculées pour
faciliter la tâche de l’éditeur de liens dynamiques. Ainsi, la différence de performance est devenue à
peine décelable.

Processus de génération
Classiquement, les fichiers sources C et C++ se divisent en deux grande catégories :

• les fichiers d’en-tête, qui contiennent les déclarations des symboles du programme ;
• les fichiers C (ou C++), qui contiennent leurs définitions.
Le fait de faire cette distinction entre la déclaration (qui consiste à dire : « telle chose existe ») et la
définition (qui consiste à décrire la chose précédemment déclarée) permet de faire en sorte que l’on peut
utiliser les fichiers objets sans avoir les fichiers sources. En effet, la déclaration permet de réaliser les
références partielles dans les programmes, tandis que les fichiers objets contiennent bien entendu la
définition binaire de ce qui a été déclaré.
Pour compiler un programme, on n’a donc réellement besoin que de trois types de fichiers :

• les fichiers de déclaration du système et des bibliothèques de base ;

• les fichiers des bibliothèques de base eux-mêmes ;
• les fichiers source (de déclaration et de définition) du programme à compiler.

En C et C++, les fichiers sources de déclaration portent l’extension « .h » (plus rarement « .hpp » pour
les fichiers de déclaration C++), et les fichiers de définition portent l’extension « .c » pour les
programmes écrits en C et « .C » (ou « .cpp », ou encore « .c++ ») pour les programmes écrits en C++.
Il va de soi que la réalisation d’un programme peut nécessiter la création d’un grand nombre de fichiers,
tous plus ou moins dépendants les uns des autres. Pour pouvoir s’y retrouver plus facilement, les
programmeurs utilisent un programme spécial : make. Ce programme est capable de réaliser toutes les
opérations nécessaires à la création des fichiers exécutables d’un programme à partir de ses fichiers

201
 Chapitre 7. Notions de compilation et configuration du noyau

sources. Pour cela, il utilise un fichier contenant la définition des opérations à réaliser, ainsi que la
description des dépendances entre les différents fichiers sources. Ce fichier est appelé le fichier makefile.
Grâce à make, l’utilisateur de base que vous êtes va pouvoir compiler la plupart des programmes sans
avoir la moindre notion de programmation.
En général, la compilation d’un programme passe par les étapes suivantes :

• récupération des fichiers sources du programme ;

• configuration du programme pour l’environnement courant ;
• appel à make pour la compilation ;
• appel à make pour l’installation.

La première étape est élémentaire et va de soi.

La deuxième étape se fait souvent en appelant un script dans le répertoire d’installation des fichiers
sources. Ce script se nomme souvent configure, et peut être appelé avec la ligne de commande suivante :

./configure

à partir du répertoire où se trouvent les fichiers sources. Ce script effectue tous les tests sur le système et
l’environnement de développement, et génère le fichier makefile. Le programme configure est en général
fourni avec les logiciels GNU. Il permet de déterminer l’environnement logiciel et système et de générer
le fichier makefile et des fichiers d’en-têtes contenant la définition de quelques options du programme.
Dans quelques cas particuliers, vous aurez à utiliser des options de configure afin de préciser certains
paramètres. L’option --host permet d’indiquer le type de la machine cible, dans le cas où configure ne
parvient pas à le déterminer automatiquement :

--host=machine

où machine est la description de votre machine. Pour les PC fonctionnant sous Linux, cette description
est de la forme « ix86-pc-linux-gnu », où le ’x’ représente le numéro de la génération du processeur
du PC. Par exemple, pour un Pentium ou un AMD K6, la description sera « i586-pc-linux-gnu ».
L’option --enable-shared permet de générer des bibliothèques dynamiques lors de la compilation.
Cela procure un gain de place évident. Enfin, l’option --prefix permet de préciser le répertoire de base
dans lequel le programme sera installé a priori. Cette option s’utilise de la manière suivante :

--prefix=répertoire

où répertoire est le répertoire de base de l’installation. La connaissance de ce répertoire est utile aux
autres programmes pour localiser les composants qui vont être installés. Dans la plupart des cas, la
valeur par défaut du préfixe convient, mais il est parfois nécessaire de le modifier. C’est en particulier le
cas lorsque vous désirez mettre à jour un programme déjà installé et que votre distribution n’utilise pas le
répertoire par défaut. Dans ce cas, il convient d’indiquer le répertoire de base dans lequel ce programme
a été installé, afin de le remplacer au lieu de le dupliquer d’une part, et afin que les autres programmes
puissent trouver la nouvelle version à la place de l’ancienne d’autre part.
La troisième étape est très simple aussi. Il suffit de taper la commande suivante :

202
 Chapitre 7. Notions de compilation et configuration du noyau

make

toujours dans le répertoire où se trouvent les fichiers sources.

Enfin, la dernière étape se fait en tapant la commande suivante :

make install

Bien entendu, ces différentes étapes varient parfois avec le logiciel à installer. Cependant, il existe
quasiment toujours un fichier texte indiquant comment effectuer ces opérations dans le répertoire des
fichiers sources. Ce fichier porte souvent le nom de « readme », « install », ou quelque chose de
similaire.
Avec les notions que vous venez de voir, vous devriez pouvoir compiler quasiment tous les programmes
que vous pourrez récupérer sous la forme de fichiers sources. Un dernier détail cependant : la
compilation est une opération très gourmande en ressources. Cela signifie qu’elle peut consommer
beaucoup de ressources processeur, de mémoire, de disque et de temps. Pour des gros programmes, il
n’est pas rare de passer jusqu’à une heure de compilation, même sur une machine récente. Notez
également que les facteurs limitants dans les compilations sont souvent la rapidité du processeur et du
disque dur, ainsi que la quantité de mémoire vive disponible.

Compilation de GCC
La clef de voûte du processus de compilation est bien entendu la suite de compilateurs GCC du projet
GNU. Cette suite comprend un compilateur pour les languages C, C++, Objective C, Fortran, Java et
Ada. La plupart des distributions fournissent ces outils sur leur CD d’installation, mais ne les installent
pas par défaut. Il est toutefois recommandé d’installer au moins le compilateur C/C++ et les outils de
développement associés, ainsi que les fichiers d’en-tête des bibliothèques de base du système
(bibliothèque C, en-têtes de XWindow, des bibliothèques utilitaires et des bibliothèques de base des
environnements graphiques Gnome et KDE).
Le choix de la version de GCC utilisée est extrêmement important, car la stabilité et les performances du
système en dépendront directement. De plus, certains programmes exigeront une version spécifique du
compilateur pour être compilés, soit parce qu’ils n’ont été testés qu’avec cette version par les
développeurs, soit parce qu’ils utilisent une fonctionnalité qui n’est disponible que dans les versions
récentes de GCC.
La version stable de GCC la plus utilisée est sans doute la version 3.4.4. Cette version conviendra dans la
majorité des cas, et est fortement recommandée pour les possesseurs de machines dont le processeur
n’est pas de type x86 ou qui sont en 64 bits. De toutes les versions antérieures, seule la version 2.95.3 et
les versions 3.2.x et 3.3.x sont réellement utilisables. Les versions 3.0.x et 3.1.x ont toutes souffert de
bugs graves et ne doivent donc pas être utilisés. En pratique, on utilisera de préférence la version 3.4.4,
pour les raisons suivantes :

• elle permet de compiler de programmes pour les processeurs les plus récents, tels que les IA-64
d’Intel, les x86-64 d’AMD et les PowerPC d’IBM ;

203
 Chapitre 7. Notions de compilation et configuration du noyau

• elle permet d’utiliser les instructions spécifiques des processeurs les plus récents, même d’architecture
x86 ;
• la bibliothèque standard C++ fournie avec cette version respecte nettement mieux la norme C++ que
les versions antérieures, et elle permet d’utiliser les caractères Unicode dans les programmes C++ ;
• elle dispose des dernières optimisations ajoutées à GCC.

On prendra garde au fait que certaines distributions utilisent régulièrement des versions non stabilisées
des programmes de base tels que GCC, la bibliothèque C ou le noyau. C’est en particulier le cas de la
Redhat et de toutes ses dérivées, telle la Mandrake par exemple. Tout cela est fort dommageable, car les
paquetages binaires de ces distributions sont systématiquement incompatibles avec ceux des autres d’une
part, et il est quasiment impossible d’envisager une compilation correcte d’un programme avec ces
distributions d’autre part. En pratique, les possesseurs de distributions Redhat et dérivées s’abstiendront
donc de faire une mise à jour manuelle de GCC, de la bibliothèque C ou même du noyau, car les
programmes installés sur leur machine risqueraient de ne plus fonctionner. Les utilisateurs de ces
distributions devraient faire une mise à jour complète de leur distribution dans ce cas.

Note : En ce qui concerne les numéros de version, il faut savoir que le dernier chiffre caractérise
souvent le numéro de correctif. Plus ce chiffre est élevé, moins le programme a de chances de
comporter de bogues. En pratique, on évitera généralement d’installer systématiquement les
dernières versions des logiciels lorsque ces versions sont les premières d’une nouvelle série. Ainsi,
un programme de version x.y.0 est certainement peu fiable. Il faudra attendre au moins la version
x.y.1 ou mieux la x.y.2, pour pouvoir l’utiliser sereinement. Sachez également que le numéro
intermédiaire sert, pour certains logiciels, à indiquer les versions de développement. C’est par
exemple le cas du noyau Linux, pour lequel les numéros de version impairs correspondent aux
versions de développement et les numéros pairs aux versions stables. Ce n’est pas le cas pour la
bibliothèque C ou GCC. De plus, certains logiciels utilisent un schéma de version à quatre chiffres, le
dernier chiffre correspondant généralement aux correctifs mineurs n’entraînant théoriquement
aucune régression. C’est également le cas du noyau Linux depuis la version 2.6.8. Ainsi, dans un
numéro de version x.y.z.t, x représente généralement la version majeure du logiciel (et n’est
changée qu’en cas d’incompatibilité majeure ou de refonte complète), y est le numéro de la branche
(une convention permettant de distinguer les branches de développement des branches stables y
est parfois appliquée), z est le numéro de version dans la branche, et t le numéro du patch
regroupant les corrections de sécurité ou de petite taille.

Prérequis
À moins que vous ne réussissiez à mettre la main sur une version de GCC déjà compilée pour Linux,
vous ne disposerez que des sources. Les sources de GCC peuvent être récupérées sur Internet sur le site
de GCC ([Link] Ces sources sont fournies sous la forme d’une archive au format tar-gzip.
Le nom de cette archive est « [Link] ».
Un autre prérequis est bien entendu que vous disposiez également d’un compilateur C sur votre système.
Ce compilateur peut très bien être une ancienne version de GCC, mais il est impératif de disposer d’un
compilateur C correct. Le code de GCC a été écrit pour pouvoir être compilé de manière minimale avec
la plupart des compilateurs C existants. Il faut également que ce compilateur porte le nom de « cc » ou

204
 Chapitre 7. Notions de compilation et configuration du noyau

« gcc » et soit dans l’un des répertoires de la variable d’environnement PATH, ou que la variable CC ait
été définie avec le chemin absolu du compilateur.

Installation des sources

Lorsque vous aurez installé le compilateur C natif de votre système, vous devrez décompresser les
sources de GCC. Cela doit se faire avec la commande suivante :

tar xvfz archive

où archive est le nom de l’archive compressée contenant ces sources. Dans notre cas, ce doit être
[Link]. Cette commande a pour conséquence de créer l’arborescence des répertoires des
sources de GCC dans le répertoire où elle a été exécutée.
Une fois cette opération effectuée, il est conseillé de créer un autre répertoire, ailleurs que dans le
répertoire des sources de GCC, dans lequel la compilation aura lieu. Dans toute la suite, nous
supposerons que le répertoire des sources se nomme srcdir, et que le répertoire de compilation se
nomme objdir.

Configuration
L’étape suivante est d’aller dans le répertoire de compilation et de lancer le programme de configuration
de GCC dans ce répertoire. Cela peut être réalisé avec les commandes suivantes :

cd objdir
srcdir/configure [options]

Comme on l’a vu ci-dessus, le programme de configuration configure peut recevoir des options en ligne
de commande. Il est recommandé de fournir l’option --enable-__cxa_atexit, qui permet de rendre
GCC compatible avec la version 3 de la norme inter-vendeurs spécifiant le format des interfaces binaires
pour les compilateurs C++, et donc de garantir la compatibilité binaire ascendante avec les versions
futures de GCC. Cela vous permettra d’éviter d’avoir à recompiler toutes les bibliothèques C++ lors des
mises à jours ultérieures de GCC. Il est également recommandé d’utiliser l’option
--enable-long-long, qui ajoute le support du type de données « long long, » qui permet de
manipuler des données 64 bits sur les machines 32 bits comme les PC, ainsi que l’option
--enable-threads, qui permet d’ajouter le support des threads aux langages.

Normalement, le programme de configuration détecte le type de machine et le système utilisé.

Cependant, cette détection peut échouer si les types de machines indiqués pour les différents composants
du système ne sont pas identiques. Dans ce cas, il vous faudra spécifier la machine hôte à l’aide de
l’option --host. La ligne de commande pour la configuration sera alors la suivante :

srcdir/configure --enable-__cxa_atexit \
--enable-long-long --enable-threads --host=configuration

où condiguration est un triplet de la forme i686-pc-linux-gnu.

205
 Chapitre 7. Notions de compilation et configuration du noyau

Le nombre de compilateurs fournis avec la suite de compilateurs GCC est impressionnant. Cependant,
seuls les compilateurs C et C++ sont réellement essentiels. Aussi est-il possible de ne prendre en charge
que certains langages à l’aide de l’option --enable-languages. Cette option doit être suivie des noms
des langages pour lesquels le compilateur doit être créé, séparés par des virgules. Ainsi, on peut
n’installer que les compilateurs C/C++ et Java en ajoutant l’option suivante à la ligne de commande :

--enable-languages=c,c++,java

Enfin, si votre distribution utilise le compilateur GCC comme compilateur de base du système, et que
vous désirez remplacer la version de votre distribution par la version que vous allez compiler, il faut
changer le répertoire d’installation de GCC. Normalement, GCC s’installe dans le répertoire
/usr/local/ ce qui fait qu’il ne remplace pas la version de votre distribution. Vous devez donc
spécifier les répertoires de base pour l’installation. Pour cela, il suffit d’ajouter les options suivantes :

--prefix=/usr

à la ligne de commande de configure.

Compilation
La compilation de GCC peut ensuite être réalisée. Autant vous prévenir tout de suite : c’est une opération
très longue, qui de plus demande beaucoup d’espace disque. Il faut au moins prévoir 800 Mo d’espace
disque, et presque trois heures sur une machine à 500 Mhz. Cela est dû au nombre de langages supportés
par les versions récentes de GCC, à la technique employée lors de sa compilation. La plupart des
compilateurs C ne sont en effet pas capables de compiler GCC avec toutes ses fonctionnalités, aussi la
compilation se déroule-t-elle en trois étapes :

• une version allégée de GCC est compilée avec le compilateur natif du système dans une première
passe ;
• cette version est utilisée pour compiler la version complète de GCC ;
• la version complète est utilisée pour se recompiler, afin de tester les différences entre les deux versions
complètes.
Ainsi, GCC se compile lui-même !
Ces trois opérations peuvent être exécutées à l’aide d’une seule commande :

make bootstrap

Cette commande doit être exécutée à partir du répertoire de compilation objdir.

Installation de GCC
Lorsque la compilation s’est terminée, vous pouvez installer GCC. Il est recommandé de supprimer le
compilateur que vous avec utilisé pour compiler GCC, sauf si, bien entendu, il s’agissait déjà de GCC.

206
 Chapitre 7. Notions de compilation et configuration du noyau

En effet, il n’est pas nécessaire de le conserver, puisque vous utiliserez désormais GCC. L’installation de
GCC est, encore une fois, très simple :

make install

Cette commande installe GCC ainsi que la bibliothèque standard C++.

Compilation du noyau Linux

La compilation du noyau est une spécificité des systèmes libres, qui n’est possible que parce que l’on
dispose des sources du noyau. Cependant, même pour certains Unix commerciaux, il est possible
d’effectuer une édition de liens, les modules du noyau étant fournis sous la forme de fichiers objets. La
compilation ou l’édition de liens du noyau est une opération technique qui peut surprendre un habitué
des systèmes fermés que sont par exemple Windows ou OS/2. Cependant, elle permet d’obtenir un noyau
très petit, optimisé pour la machine sur laquelle il tourne, et donc à la fois économe en mémoire et
performant. Il est donc recommandé d’effectuer cette compilation : pourquoi conserver un monstre
capable de gérer des périphériques qui ne sont pas et ne seront jamais installés sur votre système ?
La compilation du noyau de Linux nécessite de disposer des dernières sources du noyau (version
[Link] au 16/03/2004) et d’un compilateur. Le noyau utilise des constructions spécifiques à gcc et ne
peut donc, de manière fiable, n’être compilé que par ce compilateur (même si d’autres compilateurs
compatibles avec GCC sont utilisables moyennant quelques efforts). La documentation du noyau indique
que la version de gcc à utiliser pour le compiler est la version 2.95.3. La raison en est que cette version
est plus légère, plus rapide, et génère du code plus concis d’une part, et que, d’autre part, le noyau étant
déjà bien optimisé, il n’a pas besoin des dernières optimisations des versions récentes du compilateur. Il
est également parfois argumenté que les développeurs du noyau eux-même n’utilisent que cette version,
ce qui est certainement faux à présent. Quoi qu’il en soit, il n’y a généralement aucun problème à
compiler le noyau avec les versions récentes de GCC, et en pratique on pourra utiliser la version installée
dans le système sans inquiétude.
La compilation du noyau n’est pas très difficile. Elle nécessite cependant de répondre correctement aux
questions de configuration. Les erreurs peuvent être multiples, et souvent fatales. Il est donc fortement
conseillé de disposer d’une disquette de démarrage afin de réparer le système en cas d’erreur. Par
ailleurs, il faut toujours conserver le dernier noyau utilisable en sauvegarde dans le répertoire /boot/. Il
faut également ajouter une entrée spécifiant ce noyau dans le programme de démarrage (lilo), afin de
pouvoir sélectionner l’ancien noyau en cas d’erreur. Ces opérations seront décrites en détail plus loin.
La compilation du noyau se passe en quatre étapes :

• installation des fichiers sources ;

• réponse aux questions de configuration ;
• compilation et installation du noyau ;
• compilation et installation des modules.

207
 Chapitre 7. Notions de compilation et configuration du noyau

Installation des sources de Linux

Les sources du noyau peuvent être trouvées sur le site [Link] ([Link] Il est possible
de récupérer les sources complètes, sous la forme d’une archive compressée d’environ 33 Mo. Toutefois,
si l’on dispose déjà d’une version complète des fichiers sources, il est envisageable de ne télécharger que
les fichiers différentiels de cette version à la version courante (ce que l’on appelle classiquement des
« patches »).

Note : Les utilisateurs des distributions Redhat dérivées (telle que la Mandrake par exemple) doivent
impérativement utiliser les sources fournies par leur distribution. En effet, les noyaux de ces
distributions sont patchés à mort pour utiliser des fonctionnalité non stabilisées de la version de
développement du noyau de Linux, et sans lesquelles la plupart des programmes et la bibliothèque
C elle-même ne fonctionneraient plus. Je déconseille aux utilisateurs de ces distributions de se
lancer dans l’aventure d’une quelconque compilation d’un des composants système.

Il est recommandé d’installer les sources du noyau dans un autre répertoire que celui où se trouvent les
fichiers sources de votre distribution, car ceux-ci contiennent les fichiers d’en-tête C qui ont été utilisés
pour générer la bibliothèque C du système et sont donc nécessaires à la compilation des programmes. Le
remplacement des fichiers sources du noyau imposerait donc, en toute rigueur, de recompiler la
bibliothèque C du système (en pratique cependant, il est rare que les en-têtes du noyau soient modifiés au
point de générer des incompatibilités, du moins dans une même série de noyaux). Cette opération est
extrêmement technique, risquée et longue, il est donc logique que l’on s’en dispense. Les plus motivés
trouveront en annexe la manière de procéder pour recompiler la bibliothèque C.
Généralement, les fichiers sources de Linux sont installés dans le répertoire /usr/src/linux/.
Certaines distributions font une copie des fichiers d’en-tête du noyau qui ont servi pour la génération de
la bibliothèque C dans les répertoires /usr/include/linux/, /usr/include/asm/
/usr/include/asm-generic. Si ce n’est pas le cas, il faudra renommer temporairement le répertoire
/usr/src/linux/ avant d’installer les sources du nouveau noyau, ou au moins en faire une
sauvegarde. Une autre solution est d’installer les fichiers du noyau dans un répertoire
/usr/src/linux<version>/ et d’utiliser un lien symbolique /usr/src/linux/ pour sélectionner
la version que l’on veut compiler. Cela permet de conserver plusieurs jeux de sources de versions
différentes, et de travailler sur la version courante dans le répertoire /usr/src/linux/ facilement. Les
commandes suivantes permettront d’extraire les sources dans le répertoire dédié au sources de Linux.
Elles supposent qu’il existe déjà un lien symbolique /usr/src/linux/ vers le répertoire devant
accueillir ces fichiers sources :

cd /usr/src
rm linux
tar xvfz linux-[Link].[Link]
ln -s linux-[Link] linux

Une fois le nouveau noyau compilé et installé, on pourra rétablir la dépendance de la bibliothèque C sur
les fichiers d’en-tête de l’ancien noyau en rétablissant le lien symbolique à sa valeur initiale.
Si l’on dispose déjà d’une version complète des fichiers sources, et que l’on désire appliquer un patch, il
faut décompresser le fichier de patch avec la commande suivante :

gunzip [Link]

208
 Chapitre 7. Notions de compilation et configuration du noyau

où [Link] représente le fichier de patch compressé (en supposant qu’il ait été compressé à l’aide
de gzip). L’application du patch se fait de la manière suivante :

patch -p0 < fichier

Cette commande doit être lancée à partir du répertoire /usr/src/. Elle suppose que les fichiers sources
de Linux pourront être trouvées dans le répertoire ./linux/. Dans cette ligne de commande, fichier
représente le nom du fichier de patch précédemment décompressé, et l’option -p0 indique au programme
patch d’utiliser les noms de répertoires relatifs au répertoire courant (à savoir ./linux/). Si les sources
sont installées dans un autre répertoire, il faudra modifier l’option -px passée en paramètre au
programme patch, où x est le nombre de niveaux de répertoires à ignorer pour l’application du patch.
Consultez la page de manuel patch pour plus de détails sur cette option.
Il est recommandé de télécharger au moins une fois l’ensemble des sources du noyau, et de ne pas
utiliser les sources fournies avec la distribution que vous utilisez. En effet, certaines distributions
modifient les sources et on ne peut donc pas leur appliquer les patches standards. Toutefois, les fichiers
sources fournis avec les distributions contiennent souvent d’autres patches non encore intégrés
officiellement dans le noyau. Si l’une des fonctionnalités apportées par ces patches est utilisée, on devra
se contenter des sources de la distribution.

Choix des options de configuration du noyau

La configuration du noyau peut se faire à l’ancienne avec la commande suivante :

make config

Cette commande pose une série de questions auxquelles il faut pouvoir répondre correctement du
premier coup. On n’a pas le droit à l’erreur ici, faute de quoi il faut tout reprendre à zéro.
Il est nettement préférable d’utiliser la version texte, qui fournit les options de configuration sous la
forme de menus. Cela peut être réalisé avec la commande suivante :

make menuconfig

Certains préféreront l’une des versions X11 du programme de configuration, que l’on peut obtenir avec
les commandes

make xconfig

ou

make gconfig

Sachez cependant que certaines options ne sont toutefois pas correctement proposées dans ce mode, et
que la version textuelle du programme de configuration reste recommandée.

209
 Chapitre 7. Notions de compilation et configuration du noyau

Quelle que soit la méthode utilisée, il faut répondre par ’Y’ (pour « Yes »), ’N’ (pour « No ») ou ’M’ (pour
« Module ») lorsque c’est possible. ’Y’ et ’M’ incluent la fonctionnalité courante dans le noyau, ’N’ la
supprime. ’M’ permet d’utiliser la fonctionnalité en tant que module du noyau. En général, l’utilisation
des modules permet d’alléger le noyau car les fonctionnalités sont chargées et déchargées
dynamiquement. Cependant, les fonctionnalités nécessaires au démarrage de Linux, comme les
gestionnaires de disques et systèmes de fichiers par exemple, ne doivent en aucun cas être placées dans
des modules, car le système ne pourrait alors pas démarrer.
Le choix des options de configuration est réellement très large, car celles-ci couvrent un ensemble de
fonctionnalités très large. La description exhaustive de ces options est à la fois fastidieuse et inutile, car
vous n’utiliserez pas tous les gestionnaires de périphériques et toutes les fonctionnalités de Linux avec
un même ordinateur. Il s’agit donc de répondre aux questions appropriées pour votre configuration, mais
de le faire avec rigueur : la moindre erreur de configuration peut empêcher votre système de fonctionner
correctement, voire l’empêcher de démarrer tout simplement. Vous trouverez une description rapide des
principales options de configuration dans l’Annexe A. Les options les plus utiles seront également
décrites lorsque cela sera nécessaire dans le chapitre de configuration du matériel.

Compilation et installation du noyau

Une fois la configuration du noyau réalisée, la compilation peut être lancée. Pour cela, il suffit de lancer
la simple commande make dans le répertoire /usr/src/linux.
Une fois la compilation achevée, il faut installer le nouveau noyau. Cette opération nécessite beaucoup
de prudence, car si le noyau nouvellement créé n’est pas bon, le système ne redémarrera pas. C’est pour
cela qu’il est conseillé de conserver toujours deux versions du noyau, dont on est sûr que l’une d’entre
elle fonctionne parfaitement. En pratique, cela revient à conserver la version originale du noyau installé
par votre distribution. Pour cela, il faut en faire une copie de sauvegarde.
En général, le noyau est installé dans le répertoire /boot/ (ou dans le répertoire racine pour les
anciennes versions de Linux). Il porte souvent le nom de vmlinuz. Pour le sauvegarder, il suffit donc de
taper par exemple la commande suivante :

cp vmlinuz [Link]

Il faut également indiquer au gestionnaire d’amorçage qu’il faut qu’il donne maintenant la possibilité de
démarrer l’ancienne version du noyau sous ce nouveau nom. Pour LILO, il suffit d’éditer le fichier
/etc/[Link] et d’y ajouter une nouvelle configuration. En pratique, cela revient à dupliquer la
configuration du noyau actuel et à changer simplement le nom du noyau à charger (paramètre « image »
de la configuration dans /etc/[Link]) et le nom de la configuration (paramètre « label »). Vous
devrez aussi rajouter l’option « prompt » si elle n’y est pas déjà, afin que LILO vous demande la
configuration à lancer à chaque démarrage. Dans notre exemple, le nom du noyau à utiliser pour la
configuration de sauvegarde sera [Link]. De même, si la configuration initiale de Linux porte le
nom « linux », vous pouvez utiliser le nom « oldlinux » pour la configuration de sauvegarde.
Une fois le fichier [Link] mis à jour, il faut vérifier que l’on peut bien charger l’ancien système.
Pour cela, il faut réinstaller LILO et redémarrer la machine. La réinstallation de LILO se fait exactement
de la même manière que son installation, simplement en l’invoquant en ligne de commande :

210
 Chapitre 7. Notions de compilation et configuration du noyau

lilo

Si LILO signale une erreur, vous devez corriger immédiatement votre fichier [Link] et le réinstaller.
Pour le GRUB, la définition d’une nouvelle configuration se fait également en dupliquant la
configuration initiale et en changeant le nom de l’option de menu du GRUB et le chemin sur le fichier du
noyau sauvegardé. Veillez également à bien ajouter une option timeout pour avoir la moindre chance de
sélectionner la configuration à lancer. Tout cela doit être effectué dans le fichier de configuration
/boot/grub/[Link]. Contrairement à LILO, il n’est pas nécessaire de réinstaller le GRUB pour que
les modifications de ce fichier soient prises en compte au démarrage suivant.
Vous pourrez alors redémarrer redémarrer la machine avec la commande suivante :

reboot

Le gestionnaire d’amorçage utilisé vous propose alors de choisir le système d’exploitation à lancer. Il
faut ici sélectionner la configuration de sauvegarde pour vérifier qu’elle est accessible et fonctionne bien.
Le système doit alors démarrer en utilisant la copie sauvegardée du noyau. Si cela ne fonctionne pas, on
peut toujours utiliser le noyau actuel en sélectionnant le noyau initial et en corrigeant la configuration du
gestionnaire d’amorçage.
Lorsque vous vous serez assuré que le système peut démarrer avec la sauvegarde du noyau, vous pourrez
installer le nouveau noyau. Son image a été créée par make dans le répertoire
/usr/src/linux/arch/i386/boot/, sous le nom bzImage. L’installation se fait donc simplement
par une copie dans /boot/ en écrasant le noyau actuel vmlinuz :

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz

Il faut également copier le fichier [Link] du répertoire /usr/src/linux/ dans le répertoire

/boot/ :

cp [Link] /boot

Ce fichier contient la liste de tous les symboles du nouveau noyau, il est utilisé par quelques utilitaires
systèmes.
Si vous utiliser LILO, il vous faudra le réinstaller à nouveau pour qu’il prennent en compte le nouveau
noyau. Cela se fait avec la même commande que celle utilisée précédemment :

lilo

Cette opération n’est en revanche pas nécessaire avec le GRUB.

Encore une fois, il faut redémarrer la machine avec la commande suivante :

reboot

211
 Chapitre 7. Notions de compilation et configuration du noyau

et vérifier que le nouveau noyau fonctionne bien. S’il ne se charge pas correctement, c’est que les options
de configuration choisies ne sont pas correctes. Il faut donc utiliser le noyau sauvegardé, vérifier ses
choix et tout recommencer. Attention cependant, cette fois, il ne faut pas recommencer la sauvegarde du
noyau puisque cette opération écraserait le bon noyau avec un noyau défectueux.
Si le nouveau noyau démarre correctement, il ne reste plus qu’à installer les modules.

Compilation et installation des modules

Si le système a redémarré correctement, on peut installer les modules. Il n’est pas nécessaire de prendre
les mêmes précautions pour les modules que pour le noyau. Il suffit donc ici de lancer la commande
suivante dans le répertoire /usr/src/linux/ :

make modules_install

Au préalable, il est recommandé de décharger tous les modules présents en mémoire. Cela peut être
réalisé à l’aide de la commande modprobe et de son option -r.
Les modules sont installés dans le répertoire /lib/module/version/, où version est le numéro de
version du noyau courant. Il est possible que des modules d’autres versions du noyau existent dans leurs
répertoires respectifs. Si vous n’en avez plus besoin, vous pouvez les effacer. Attention cependant si vous
avez installé des modules additionnels non fournis avec le noyau dans ces répertoires, vous pourriez
encore en avoir besoin.
Comme on l’a déjà vu, les modules sont utilisés par le chargeur de module du noyau, grâce à la
commande modprobe. Cette commande a besoin de connaître les dépendances entre les modules afin de
les charger dans le bon ordre. Il faut donc impérativement mettre à jour le fichier
/lib/modules/version/[Link] à chaque fois que l’on installe les modules, à l’aide de la
commande suivante :

depmod -a

Note : La commande depmod -a est exécutée automatiquement lors de l’installation des modules du
noyau. Toutefois, elle devra être exécutée manuellement si l’on installe des modules non fournis
avec le noyau.

212
Chapitre 8. Configuration du matériel et des
périphériques
Ce chapitre présente les concepts nécessaires à l’installation de cartes filles additionnelles et à la
configuration des périphériques complémentaires sous Linux. La procédure d’installation des disques
durs, graveurs, cartes son, cartes graphiques, cartes vidéo et cartes réseau sera donc décrite, ainsi que la
manière de les configurer pour obtenir un fonctionnement correct sous Linux.

Généralités sur le support matériel sous Linux

Comme il l’a déjà été expliqué dans les chapitres précédents, Linux gère tous les périphériques comme
des fichiers spéciaux. De plus, la plupart des gestionnaires de périphériques peuvent être chargés
dynamiquement, sous la forme de modules du noyau. Cette section présentera donc les notions de base
concernant les fichiers spéciaux de périphériques, les modules du noyau ainsi que leurs rôles respectifs
dans la configuration d’un nouveau matériel. La syntaxe utilisée pour fournir des options au noyau lors
de son amorçage et les mécanismes de détection du matériel et de chargement automatique des
gestionnaires de périphériques seront également présentés.

Notion de fichiers spéciaux de périphériques

La notion de fichier spécial de périphérique simplifie énormément l’utilisation du matériel par les
programmes d’application, puisque la plupart des opérations sur un périphérique reviennent simplement
à réaliser une écriture ou une lecture. Évidemment, l’écriture sur un fichier spécial de disque permet
d’enregistrer les données sur ce disque, et la lecture permet de les récupérer. Mais cela ne s’arrête pas là !
Par exemple, la communication avec le modem se fait simplement en écrivant et en lisant les données sur
le fichier spécial du port série sur lequel le modem est connecté. De même, jouer un fichier son revient
simplement à l’écrire dans le fichier spécial qui gère la carte son. Il est même possible d’accéder à la
mémoire vidéo par l’intermédiaire d’un fichier spécial de périphérique...
Bien entendu, certaines fonctionnalités avancées des périphériques ne peuvent pas être accédées
simplement par une une écriture ou une lecture dans un fichier spécial. Le système fournit donc aux
applications d’autres moyens d’accéder à ces fonctionnalités, par l’intermédiaire d’appels systèmes
spécifiques (pour ceux qui sont intéressés par la programmation système, cet appel système est réalisé
par la fonction ioctl, dont le nom provient de l’abréviation de l’anglais « Input / Output ConTroL »).
Évidemment, cette méthode n’est utilisée que par les programmes qui connaissent bien le fonctionnement
du gestionnaire du périphériques, car ils doivent spécifier une requête que seul ce gestionnaire comprend
en général. Quoi qu’il en soit, les requêtes de ce type utilisent elles aussi un descripteur de fichier spécial
de périphérique, ce qui fait que tous les accès au matériel ont lieu par l’intermédiaire de ces fichiers.
Il existe deux principaux types de fichiers spéciaux de périphériques. Le premier type correspond aux
périphériques de type bloc, dont les données ne peuvent être lues que par blocs (c’est le cas des disques
durs, des lecteurs de CD et de disquettes en particulier). Le deuxième type correspond aux périphériques
de type caractère, dont les données peuvent être lues caractère par caractère (cartes son, ports série, etc.).
En plus de son type, chaque fichier spécial de périphérique est caractérisé par deux codes permettant
d’identifier le type et le modèle du périphérique auquel il donne accès. Ces deux codes portent le nom de

213
 Chapitre 8. Configuration du matériel et des périphériques

code majeur et de code mineur. Comme nous le verrons plus tard, c’est par l’intermédiaire de ces codes
que le noyau est capable de retrouver le gestionnaire de périphériques à utiliser pour satisfaire aux
requêtes des clients qui accèdent à un fichier spécial de périphérique. Il y a donc, en général, une
association unique entre ces codes et les gestionnaires de périphériques. La liste des codes majeurs et
mineurs déjà affectés à des périphériques est donnée dans le fichier
/usr/src/linux/Documentation/[Link] (ce fichier vous donnera donc une idée des
périphériques qui peuvent être ou qui seront gérés par Linux).
Les fichiers spéciaux de périphériques sont tous stockés dans le répertoire /dev/. En général, ce
répertoire contient un grand nombre de fichiers spéciaux de périphériques, même pour des périphériques
inexistants sur votre machine. Ces fichiers sont généralement installés automatiquement par les
distributions, qui laissent au noyau le soin de signaler que le périphérique est absent lorsqu’un
programme tente d’accéder à un fichier spécial auquel aucun matériel ne correspond. Les fichiers fournis
par les distributions sont donc, en théorie, susceptibles de couvrir toutes les gammes de périphériques
courants, et vous n’aurez pas à toucher au répertoire /dev/. Cependant, si vous devez créer un fichier
spécial de périphérique vous-même, vous devrez utiliser la commande mknod. Sa syntaxe est
relativement simple :

mknod fichier type majeur mineur

où fichier est le nom du fichier spécial de périphérique à créer, type est une lettre indiquant le type du
fichier spécial (’c’ pour les fichiers de type caractère et ’b’ pour les fichiers de type bloc), et majeur et
mineur sont les codes majeur et mineur du périphérique. Je vous invite à consulter la page de manuel de
la commande mknod pour plus d’informations.

Modules du noyau
Les modules du noyau sont des bibliothèques que l’on peut charger dans le noyau lorsque celui-ci a
besoin d’une certaine fonctionnalité. Une fois chargés, les modules font partie intégrante du noyau et
ajoutent leurs fonctions à celles existantes. Ces bibliothèques sont normalement stockées dans le
répertoire /lib/modules/version/, où version est le numéro de version du noyau pour lequel ces
modules ont été créés.
Beaucoup de fonctionnalités du noyau peuvent être configurées pour être utilisées sous la forme de
modules. Dans le cas des pilotes de périphériques, les modules permettent de réaliser un noyau générique
et de prendre en charge dynamiquement les différents périphériques de l’ordinateur. Certains pilotes ne
fonctionnent d’ailleurs que sous la forme de modules, aussi faut-il savoir les manipuler. Les modules sont
également fortement utilisés pour la configuration automatique des périphériques connectables à chaud.

Chargement et déchargement des modules

Les modules peuvent être chargés manuellement à l’aide des commandes insmod et modprobe.
modprobe est un peu plus évoluée, car elle gère les dépendances entre les modules et est capable de
charger les modules utilisés par le module demandé. Leur utilisation est des plus simple :

insmod module

ou :

214
 Chapitre 8. Configuration du matériel et des périphériques

modprobe module

où module est le nom du module à charger.

En réalité, la commande modprobe appelle la commande insmod pour chaque module qui doit être
chargé, dans l’ordre des dépendances des modules. De cette manière, chaque module peut être chargé
sans problèmes, car toutes les fonctionnalités qu’il utilise sont déjà présentes dans le noyau lors de son
chargement. La commande modprobe va chercher les informations de dépendances dans le fichier
[Link], situé dans le répertoire /lib/module/version/. Ce fichier utilise une syntaxe très
simple, et spécifie pour chaque module les modules dont il dépend. Bien qu’il puisse parfaitement être
écrit à la main, cela nécessiterait d’avoir une connaissance approfondie des modules du noyau. C’est
donc pour cela que l’outil depmod a été écrit. Cet outil permet de générer le fichier [Link]
automatiquement, pourvu qu’on l’appelle avec l’option -a en ligne de commande :

depmod -a

Il faudra donc appeler cette commande après chaque installation ou suppression de modules dans le
système.
La liste de modules qui ont été chargés peut être obtenue aisément avec la commande lsmod :

lsmod

Enfin, la commande rmmod permet de décharger un module, avec la ligne de commande suivante :

rmmod module

On préférera cependant l’utilisation de la commande modprobe avec l’option -r pour décharger les
modules, car cette commande est capable de décharger récursivement les modules dont dépendait le
module à décharger lorsqu’ils ne sont eux-même plus utilisés. La syntaxe est alors la suivante :

modprobe -r module

Options des modules

La plupart des modules peuvent prendre un certain nombre d’options lors de leur chargement. Ces
options permettent de fixer certains paramètres, et dans le cas des pilotes de périphériques, de préciser la
configuration matérielle utilisée. Toutes ces options sont définies dans le fichier de
configuration/etc/[Link]. Lors du chargement d’un module, modprobe consulte ce fichier
et passe les paramètres indiqués au module à charger.
Les options des modules peuvent être spécifiées en ligne de commande lors de l’appel de insmod ou de
modprobe. Toutefois, il est plus facile de les enregistrer dans le fichier /etc/[Link]. Cela se
fait sur une ligne commençant par le mot clé options, suivi du nom du module pour lequel ces options
sont définies, lui-même suivi des paramètres de chargement du module. La syntaxe est donc la suivante :

215
 Chapitre 8. Configuration du matériel et des périphériques

options module paramètres

La liste des paramètres que l’on peut passer à un module dépend bien évidemment du module. Vous
pouvez obtenir la liste des options supportées par un module à l’aide de l’option -p de la commande
modinfo :

modinfo -p module

Nous verrons par la suite des exemples de passage de paramètres pour les modules les plus courants.
Le fichier [Link] permet également de définir la manière dont le chargement et le
déchargement des modules doit être faite. Pour cela, il permet de spécifier une ligne de commande
complète pour ces opérations. Ces lignes de commandes sont introduites via les mots-clefs install et
remove. La syntaxe de ces mots-clés est la suivante :

install module commande

remove module commande

où module est le nom du module à charger ou à décharger, et commande est la ligne de commande de
l’opération à effectuer pour cela.
Par exemple, si le port parallèle est utilisé pour accéder à un périphérique nécessitant une opération
d’initialisation quelconque, celle-ci peut être exécutée lors du chargement du module à l’aide du mot clé
install :

install parport_pc modprobe parport_pc --ignore-install && initperiph

(en supposant que la commande initperiph permet d’initialiser le périphérique en question).

Évidemment, ce type d’opération dépend du matériel connecté sur le port parallèle, mais le principe est
là. Vous noterez que pour éviter que la commande modprobe ne boucle sur elle-même dans la
commande indiquée par la directive install, l’option --ignore-install lui a été fournie. Dans le
cas d’une directive remove, il faudrait utiliser l’option --ignore-remove.
Dans la plupart des cas, la définition de ces commandes de chargement et de déchargement sont
facultatives, car les modules utilisent généralement un jeu de paramètres implicites qui permettent de les
utiliser même si le fichier de configuration [Link] est absent. Vous pouvez visualiser ces
options en renommant le fichier de configuration [Link] et en tapant la commande suivante :

modprobe -c

Cette commande vous permettra également de recréer un nouveau fichier de configuration si d’aventure
vous perdiez celui fourni avec votre distribution.

Chargement automatique des modules

Il n’est normalement pas nécessaire d’utiliser les commandes insmod ou modprobe pour charger les
modules. En effet, il est possible de faire en sorte que les modules soient chargés à la demande,
lorsqu’une de leurs fonctionnalités est demandée au niveau du noyau. Pour cela, le noyau utilise
lui-même la commande modprobe pour charger les modules, ce qui assure la gestion correcte des

216
 Chapitre 8. Configuration du matériel et des périphériques

dépendances entre les modules. À chaque fois que le noyau a besoin d’une fonctionnalité qui n’est pas
encore chargée, il effectue une requête à modprobe en lui demandant de charger le module manquant.
Le nom du module dont le noyau demande le chargement à modprobe dépend évidemment de la
fonctionnalité demandée et ne correspond pas forcément à un nom de module existant. Par exemple, le
module de gestion des ports parallèles se nomme, sur les ordinateurs de type PC, parport_pc.
Toutefois, lorsque le noyau désire accéder au port parallèle, il n’utilise pas ce nom, mais plutôt un nom
générique, qui est le même pour toutes les architectures matérielles supportées par Linux. Ce nom est
parport_lowlevel. Ainsi, le noyau utilise la commande suivante pour charger le module de prise en
charge du port parallèle :

modprobe -k parport_lowlevel

L’option -k permet d’indiquer à modprobe qu’il est appelé par le noyau, donc dans le contexte de
chargement automatique des modules.
modprobe doit donc faire la correspondance entre le nom de module demandé par le noyau et le nom
d’un module réel. C’est encore une fois dans le fichier de configuration /etc/[Link] que cette
correspondance est enregistrée. Pour cela, un certain nombre d’alias peuvent être définis pour identifier
les modules réels. Chaque alias est introduit par le mot clé alias, dont la syntaxe est donnée ci-dessous :

alias nom module

où nom est le nom de l’alias, et module est le nom du module réel. Lorsque la commande modprobe est
appelée avec le nom d’un alias en paramètre, elle commence par rechercher le nom du module réel dans
le fichier [Link], puis elle le charge en mémoire.
Par exemple, pour charger le module parport_pc automatiquement lorsque le noyau a besoin d’accéder
au port parallèle, on devra ajouter la définition d’alias suivante dans le fichier [Link] :

alias parport_lowlevel parport_pc

217
 Chapitre 8. Configuration du matériel et des périphériques

Figure 8-1. Chargement automatique des modules du noyau

Vous pouvez constater que le mécanisme d’alias permet de rendre le noyau indépendant des modules
utilisés, puisque l’association entre le nom du module utilisé par le noyau et le module réel et ses
paramètres est maintenu dans le fichier de configuration [Link]. L’inconvénient de cette
méthode est en revanche qu’il faut connaître les noms de modules utilisés par le noyau pour chaque
fonctionnalité. Ces noms sont assez variables et dépendent de la fonctionnalité demandée. En général, ce
nom apparaît dans les messages de traces du noyau lorsqu’il ne parvient pas à localiser un module lors de
son chargement automatique. Ces messages de traces peuvent être affichés à l’aide de la commande
dmesg. Il est donc possible de déterminer la liste des modules que le noyau a tenté de charger
relativement facilement. Toutefois, cela n’indique pas forcément la fonctionnalité implémentée par le
module en question, et encore moins l’application qui a tenté d’utiliser cette fonctionnalité.
Il est heureusement beaucoup plus facile de savoir quelle est la fonctionnalité demandée lorsque celle-ci
a trait à un périphérique de l’ordinateur. En effet, le nom de module utilisé par le noyau pour chaque
gestionnaire de périphérique est construit à partir des informations définissant ce fichier, ce qui permet de
l’identifier et donc de trouver le module à charger pour prendre en charge ce périphérique. En général, le
noyau utilise un nom de module de la forme « char-major-xxxx » pour les périphériques de type
caractère, et un nom de la forme « block-major-xxxx » pour les périphériques de type bloc. Les
caractères xxxx identifient le code majeur de ce périphérique, plus rarement son code mineur. Ainsi, le
périphérique accédé par le noyau est parfaitement identifié tant du point de vue de sa nature (disque,
périphérique de type caractère...) que du point de vue de ses codes majeur et mineur. Il est donc facile
d’en déduire le gestionnaire de périphérique nécessaire à la gestion de ce fichier spécial de périphérique,
et de définir l’alias permettant de faire la correspondance entre le nom du module utilisé par le noyau et
le module réel à charger.
Par exemple, pour les cartes son, le nom de module char-major-14 est utilisé pour demander le
chargement du module de gestion du son, parce que les cartes son utilisent toutes le code majeur 14. Il
faut donc définir un alias sur ce nom de module vers le module du gestionnaire de cartes son. Comme on

218
 Chapitre 8. Configuration du matériel et des périphériques

le verra dans la section traitant de la configuration des cartes son, ce module pourra lui-même demander
le chargement de modules complémentaires, en fonction de la carte son réellement utilisée et des
fonctionnalités demandées. Le numéro de code mineur sera indiqué lors de ces opérations.
Si vous devez modifier le [Link], sachez qu’il s’agit d’une opération délicate, car elle
nécessite de bien connaître les mécanismes de nommage utilisés par le noyau, les noms des modules
réels et leurs paramètres de configuration. En général, vous trouverez les informations sur les entrées à
ajouter ou à modifier dans le fichier d’aide du module correspondant, que vous pourrez trouver dans les
sources du noyau (dans le répertoire /usr/src/linux/Documentation/). Quoi qu’il en soit, la
modification de [Link] peut générer de nouvelles dépendances entre les modules. Il est donc
nécessaire d’exécuter la commande depmod -a après chaque modification de ce fichier.

Configuration des périphériques intégrés au noyau

Pour les périphériques intégrés directement dans le noyau, il n’est pas possible d’utiliser le fichier
[Link] pour définir les différentes options dont ils peuvent avoir besoin. Dans ce cas, il faut
fournir ces options au démarrage du système.
Cela se fait, comme nous l’avons vu dans la la section intitulée Amorçage du système et configuration
multiboot dans Chapitre 4, en fournissant des paramètres au noyau sur sa ligne de commande. Nous
avons déjà vu comment la quantité de mémoire de l’ordinateur pouvait être passée au noyau à l’aide de
l’option mem si elle n’était pas détectée correctement. Il est possible de spécifier de la même manière de
nombreuses autres options, en particulier pour activer ou désactiver certains gestionnaires de
périphériques ou pour leur indiquer les paramètres du matériel.
Généralement, les options du noyau sont fournies directement dans la ligne de commande du noyau par
le gestionnaire d’amorçage. Ces options sont ensuite lues par le noyau dès son démarrage, afin de fixer
les paramètres qu’elles décrivent jusqu’au redémarrage suivant. Pour certaines fonctionnalités, ces
paramètres peuvent toutefois être modifiées dynamiquement, via les systèmes de fichiers virtuels
/proc/ ou /sys/.

Il existe un grand nombre d’options, et leur syntaxe varie en fonction du sous-système qui les utilise. Le
fichier de documentation [Link] du répertoire Documentation/ des sources du
noyau vous donnera la liste complète de ces options. Nous verrons quelques-unes de ces options
spécifiquement dans la suite du chapitre, lorsque nous décrirons les paramètres des gestionnaires de
périphériques.
D’une manière générale, les fonctionnalités développées récemment et utilisable soit en tant que module,
soit en tant que fonctionnalité intégrée directement dans le noyau, utilisent une syntaxe générique
permettant de fixer leurs options. Cette syntaxe est la suivante :

[Link]ètre=valeur

où module est le nom que du module du noyau qui implémente cette fonctionnalité lorsqu’elle est
utilisée sous la forme de module, paramètre est le nom de l’option de ce module du noyau telle qu’elle
est donnée par la commande modinfo, et valeur est sa valeur. Ainsi, si vous voulez intégrer une
fonctionnalité d’un module dans le noyau, il suffit simplement d’ajouter les paramètres complémentaires
dans la ligne de commande de celui-ci en fonction des options définies dans le fichier
/etc/[Link]. Nous verrons la manière de procéder plus loin dans ce chapitre.

219
 Chapitre 8. Configuration du matériel et des périphériques

Note : Intégrer un pilote de périphérique directement dans le noyau peut être intéressant si ce
périphérique est inamovible et que l’on ne veut pas avoir à prendre en charge les modules. Toutefois,
ce n’est pas une bonne idée lorsqu’on installe ce périphérique et qu’on cherche à le configurer. En
effet, il est souvent nécessaire de redémarrer pour prendre en compte de nouveaux paramètres
dans ce cas, alors qu’avec les modules du noyau, un déchargement et un rechargement suffit. Par
contre, lorsque votre configuration sera finie, vous pourrez parfaitement vous passez des modules et
désactiver les fonctions de détection automatique du matériel utilisées par la plupart des
distributions : vous gagnerez ainsi plusieurs dizaines de secondes au démarrage de votre ordinateur.
Dans certaines situations, l’usage des modules reste impératif. C’est par exemple le cas lorsque
plusieurs périphériques identiques sont installés dans l’ordinateur, et que le gestionnaire de
périphérique impose d’être chargé plusieurs fois. Dans ce cas, il faut le charger sous forme de
module, avec, pour chaque périphérique, un nom de module différent. Cela est évidemment
infaisable si l’on intègre le gestionnaire de périphérique directement dans le noyau.

Périphériques connectables à chaud

Linux est capable de gérer les périphériques connectables à chaud, c’est-à-dire ordinateur allumé, de
manière très souple, par l’intermédiaire de programmes auxiliaires. Plus précisément, le noyau se
contente de détecter l’apparition et la disparition des périphériques USB, pcmcia, FireWire, PCI ou
autres sur les bus systèmes, de récupérer les informations sur ces périphériques, et de les fournir à un
programme auxiliaire chargé de faire tout le travail de configuration. Ce mécanisme permet de rendre le
noyau absolument indépendant des différentes opérations éventuellement nécessaires pour configurer le
matériel, et reste très souple et extensible pour les futurs périphériques connectables à chaud.

Agents hotplug
Dès qu’un événement de type apparition ou disparition d’un périphérique sur un bus se produit, le noyau
appelle le programme référencé dans le fichier hotplug du répertoire /proc/sys/kernel/ et fournit à
ce programme toutes les informations nécessaires à la configuration du périphérique : le type de
périphérique qui vient d’apparaître ou de disparaître, ainsi que la description complète de ce
périphérique.
Par défaut, le programme appelé par le noyau est le script /sbin/hotplug. Ce script identifie la nature du
périphérique pour lequel le noyau signale un événement et délègue le travail de configuration à des
sous-programmes, que l’on appelle « agents ». Ainsi, il existe un agent pour les périphériques USB, un
agent pour les périphériques PCI, un agent pour les périphériques FireWire, etc. Tous ces agents sont
normalement situés dans le répertoire /etc/hotplug/ et ont un nom de la forme

[Link]

où type est le type du périphérique pour lequel le noyau appelle hotplug.

Les agents ont besoin d’informations complémentaires pour déterminer quel est le périphérique qui vient
d’apparaître ou de disparaître. Le noyau fournit ces informations à hotplug sous la forme de variables
d’environnement spécifiques à chaque classe de périphérique. Par exemple, pour les périphériques USB,
les variables d’environnement définies par le noyau sont les suivantes :

220
 Chapitre 8. Configuration du matériel et des périphériques

• la variable ACTION, qui contient la description de l’événement qui s’est produit pour ce périphérique ;
• la variable PRODUCT, qui contient les identificateurs du vendeur, du produit et du périphérique pour
le périphérique considéré ;
• la variable TYPE, qui contient la classe et la sous-classe du périphérique, ainsi que son protocole de
communication ;
• et la variable INTERFACE, qui contient les paramètres de classe, sous-classe et de protocole pour les
interfaces, si le périphérique USB est de classe 0.
Des variables similaires sont définies pour les autres classes de périphériques.

Chargements des modules par hotplug

Les informations fournies par le noyau à hotplug sont suffisantes pour que les agents puissent charger les
gestionnaires de périphériques requis pour la prise en charge du matériel. Généralement, les événements
hotplug se traduisent donc par le chargement d’un module du noyau. Afin de connaître le module qui
contient le gestionnaire de périphérique, autrement dit le module à charger, hotplug doit pouvoir faire
l’association entre les informations fournies par le noyau pour identifier le périphérique et les modules
correspondants.
Cette association est maintenue par les modules eux-mêmes. En effet, chaque module de type
gestionnaire de périphérique contient une table indiquant la liste des périphériques qu’il est capable de
prendre en charge. Lors de l’installation du module, la command depmod extrait ces informations et les
place dans un des fichiers situés dans le répertoire d’installation des modules du noyau (à savoir
/lib/module/version/, où version est le numéro de version du noyau). depmod crée un fichier
pour chaque type de périphérique. Ces fichiers ont tous un nom de la forme :

[Link]

où type est le type de périphérique.

Par exemple, le fichier [Link] contient, pour chaque périphérique USB pris en charge par les
modules installés, une ligne indiquant le nom du module et l’ensemble des identifiants du périphérique
USB en question.
Ainsi, lorsque le noyau indique à hotplug l’apparition d’un nouveau périphérique, celui-ci consulte les
fichiers d’association des modules aux périphériques pour déterminer quel module est capable de gérer
ce périphérique. Ce module est chargé si nécessaire, et le gestionnaire de périphérique peut s’initialiser.

221
 Chapitre 8. Configuration du matériel et des périphériques

Figure 8-2. Chargement des modules par hotplug

Note : Certains modules peuvent ne pas contenir de table de déclaration des périphériques qu’ils
prennent en charge (cela relève du bogue). hotplug ne peut donc pas les charger automatiquement,
car ces modules n’apparaissent pas dans les fichiers d’association du noyau. Il serait possible de
rajouter explicitement les lignes manquantes dans ces fichiers, mais comme ils sont écrasés à
chaque exécution de depmod, cette solution n’est pas pérenne. Par conséquent, hotplug utilise
également des fichiers d’association complémentaires, que l’on peut modifier. Ces fichiers sont
placés dans le répertoire /etc/hotplug/.

Chargement des firmwares

Depuis la version 2.6 du noyau, hotplug est également capable de charger automatiquement le firmware
des périphériques connectés. Cette opération est réalisée par l’agent [Link], en réponse à un
événement généré par le noyau lorsqu’un gestionnaire de périphérique demande le chargement de son
firmware. Cet agent reçoit en paramètre le nom du firmware à charger et le recherche dans le répertoire
/usr/lib/hotplug/firmware/. Une fois le fichier du firmware localisé, l’agent le copie dans un
fichier du système de fichiers virtuel /sys/. Ce fichier est placé dans l’entrée correspondant au
périphérique dont le gestionnaire demande le firmware, et cette entrée est également communiquée à
hotplug par le noyau via la variable d’environnement DEVPATH.

222
 Chapitre 8. Configuration du matériel et des périphériques

Figure 8-3. Chargement des firmwares par hotplug

Normalement, le script hotplug et les agents utilisateurs doivent être fournis avec votre distribution.
Vous n’aurez donc généralement pas à l’installer ni à vous préoccuper sur la manière dont les
périphériques connectables à chaud doivent être configurés. En revanche, vous devrez activer la prise en
charge des périphériques connectables à chaud au niveau du noyau. Pour cela, il faut simplement valider
l’option « Support for hot-pluggable devices » du menu « General setup » dans la
configuration du noyau. Cette option ajoute également l’entrée hotplug dans le répertoire
/proc/sys/kernel/ du système de fichiers virtuels /proc/ du noyau.

Enfin, si vous désirez également utiliser les fonctionnalités de chargement de firmware du noyau, il vous
suffit simplement de placer les fichiers de firmware dans le répertoire /usr/lib/hotplug/firmware/
et d’activer également l’option « Hotplug firmware loading support » du sous-menu « Generic
Driver Options » du menu « Device Drivers ».

Création automatique des fichiers spéciaux de périphériques

Depuis la version 2.6 du noyau, le mécanisme de détection des périphériques connectables à chaud peut
également être utilisé pour définir automatiquement les fichiers spéciaux de périphériques du répertoire
/dev/. Ce système s’appuie sur la commande udev (abréviation de « Userspace /dev »), qui permet de
créer les fichiers spéciaux de périphériques dans le répertoire /dev/ à partir d’informations fournies par
le noyau et des entrées définissant les périphériques dans le système de fichiers virtuel /sys/.

Avantages d’udev
udev permet de résoudre plusieurs problèmes concernant les fichiers spéciaux de périphériques. Le plus
évident pour l’utilisateur est que seuls les fichiers spéciaux des périphériques effectivement présents et
pris en charge par un gestionnaire de périphérique apparaissent dans le répertoire /dev/. Ce répertoire
n’a donc plus à contenir les fichiers spéciaux de périphériques pour tous les périphériques pris en charge
par Linux. Le répertoire /dev/ en est donc d’autant réduit et beaucoup plus lisible.

223
 Chapitre 8. Configuration du matériel et des périphériques

Un autre avantage d’udev est que les codes majeurs et mineurs des fichiers spéciaux de périphériques
peuvent à présent être attribuées dynamiquement par le noyau lorsque les gestionnaires de périphériques
s’initialisent. Cela a plusieurs conséquences :

• il n’y a plus besoin d’avoir recours à une autorité centrale pour obtenir les valeurs de codes mineurs et
majeurs, ceux-ci pouvant être déterminés dynamiquement par le noyau ;
• il n’y a plus de risque de conflit entre deux périphériques, le noyau s’assurant de l’unicité des codes
utilisés ;
• la limitation du nombre de périphériques due au nombre limité de codes majeurs et mineurs n’existe
plus (il suffit de consulter la liste du fichier /usr/src/linux/Documentation/[Link] pour
constater qu’il reste peu de codes libres pour les périphériques à venir).

Enfin, udev permet de simplifier considérablement la configuration du système. Par exemple, il est
possible de fixer de manière permanente le nom des fichiers spéciaux des périphériques amovibles. De
plus, du fait du nombre plus réduit de fichiers spéciaux de périphériques, le répertoire /dev/ peut être un
système de fichiers virtuel, monté sur un disque en mémoire.

Principe de fonctionnements de udev

Le principe de fonctionnement de udev est le suivant. Lorsque le noyau détecte un nouveau périphérique,
il appelle, via les mécanismes de hotplug, la commande udevsend. Cette commande poste l’événement
dans une file d’attente, gérée par le démon udevd. Ce démon se charge de la vider en appelant la
commande udev pour réaliser les opérations de création ou de suppression des fichiers spéciaux de
périphériques dans le répertoire /dev/.
Le démon udevd exécute les commandes udev selon l’ordre indiqué par le noyau via un numéro de
séquence. Cette sérialisation est nécessaire parce que le noyau est capable de générer plusieurs
événements hotplug simultanément, et que toutes les instances de hotplug s’exécutent de manière
concurrente. Ces commandes pourraient donc ne pas s’exécuter dans le même ordre que celui demandé
par le noyau sans cette précaution.
udevsend, et donc udev via le démon udevd, reçoit en paramètre, via un jeu de variables
d’environnement, les informations relatives au périphérique pour lequel le noyau a généré un événement.
Ces paramètres comprennent, entre autres, l’opération à effectuer (ajout ou suppression de fichiers
spéciaux de périphériques) et le chemin sur le périphérique dans le système de fichiers /sys/. À partir
de ces informations, udev peut consulter les fichiers de configuration du répertoire /etc/udev/ et
déterminer quels sont les fichiers spéciaux de périphériques à créer, quels sont les droits que l’on doit
leur affecter, et quels sont les liens symboliques à créer sur ces fichiers spéciaux. Ainsi, la définition des
fichiers spéciaux de périphérique est-elle complètement paramétrable grâce aux fichiers de configuration
de ce répertoire.
La politique de création des fichiers spéciaux de périphérique par udev est donc complètement décrite
dans les fichiers de configuration du répertoire /etc/udev/. Le fichier de configuration principal est le
fichier [Link]. Ce fichier permet, entre autres, d’indiquer le répertoire cible dans lequel les fichiers
spéciaux de périphériques seront créés (normalement /dev/), et les répertoires contenant les politiques
de nommage et d’attribution des permissions aux fichiers spéciaux de périphériques (normalement
/etc/udev/rules.d/ et /etc/udev/permissions.d/).

224
 Chapitre 8. Configuration du matériel et des périphériques

Les fichiers de définition de la politique de nommage des fichiers spéciaux de périphériques contiennent
des lignes définissant chacune une règle de nommage. La ligne utilisée est choisie en fonction de critères
de sélection basés sur les informations fournies par le noyau. Par exemple, il est possible de sélectionner
le bus du périphérique (à l’aide du mot clé BUS), le nom donné au périphérique par le noyau (mot-clé
KERNEL), ou encore l’identifiant du périphérique sur le bus (mot clé ID). Il est même possible d’exécuter
un programme externe pour obtenir des informations complémentaires, et utiliser le résultat de cette
commande comme critère de sélection (mot clé PROGRAM). Vous pouvez consulter la page de manuel de
udev pour plus de détails sur la définition des critères de sélection des règles de nommage.
Outre les critères de sélection, les règles de nommage donnent bien entendu le nom du fichier spécial de
périphérique à créer, son propriétaire et son groupe, ainsi que les permissions sur ce fichier, à l’aide des
mots clefs NAME, OWNER, GROUP et MODE. Il est également possible de définir des liens symboliques
complémentaires (par exemple /dev/cdrom ou /dev/modem) sur les fichiers spéciaux de périphériques
ainsi créés (option SYMLINK). Les noms ainsi définis peuvent être paramétrés par les différentes
informations sur le périphérique grâce à des variables spécifiques. La page de manuel de udev vous
donnera encore une fois de plus amples informations à ce sujet.
Les permissions indiquées dans les fichiers du répertoire /etc/udev/permissions.d/ ne sont
utilisées que si les règles de nommage ne donnent aucune permission. La syntaxe de ces fichiers est
beaucoup plus simple, puisqu’elle associe, pour chaque nom de fichier spécial de périphérique, le
propriétaire, le groupe et les droits d’accès (spécifiés en octal).

Figure 8-4. Création des fichiers spéciaux de périphériques par udev

Comme vous pouvez le constater, les fichiers de configuration de udev permettent de paramétrer de
manière très souple et très précise la manière dont les fichiers spéciaux de périphériques sont créés. La
contrepartie est tout de même une certaine complexité dans la définition des règles de nommage et
d’attribution des permissions, mais vous n’aurez généralement pas à vous en préoccuper, car les
distributions fournissent des fichiers de configuration adaptés à la plupart des usages.

225
 Chapitre 8. Configuration du matériel et des périphériques

Persistance des fichiers spéciaux de périphériques

Les mécanismes de udev, pour complexes qu’ils puissent paraître, permettent de résoudre certains
problèmes autrement insolubles. En particulier, udev permet de garantir que le nom de fichier spécial de
périphérique affecté à un matériel donné ne change pas, quelle que soit la manière et l’ordre dont les
périphériques sont connectés au système. Par exemple, il peut être intéressant que les fichiers spéciaux de
périphériques attribués à deux imprimantes USB ne soient jamais échangés, ce qui pourrait se produire si
on rajoute un hub USB et qu’on les y connecte a posteriori.
Pour fixer les idées et donner un exemple, supposons que l’on ait deux clefs mémoire USB de modèles
différents et que l’on désire affecter de manière permanente des fichiers de périphériques à chacune
d’elle. Il suffit pour cela simplement de trouver un paramètre unique dans les identifiants de ces
périphériques afin de les distinguer. La liste des paramètres des périphériques peut être affichée à l’aide
de la commande systool.
Les disques USB apparaissant comme des périphériques SCSI. Pour obtenir les informations sur ces
périphériques, il faut utiliser, après les avoir connectés, l’option -b de systool. On utilisera également
l’option -v, sans laquelle seul un résumé est affiché :

systool -vb scsi

Supposons que cette commande donne le résultat suivant :

Bus = "scsi"

Device = "[Link]"
Device path = "/sys/devices/pci0000:00/[Link].0/usb2/2-2/2-2:1.0/host1/[Link]"
delete = <store method only>
detach_state = "0"
device_blocked = "0"
max_sectors = "240"
model = "MINI DATA DRIVE "
queue_depth = "1"
rescan = <store method only>
rev = "1.00"
scsi_level = "3"
state = "running"
timeout = "30"
type = "0"
vendor = " "

Device = "[Link]"
Device path = "/sys/devices/pci0000:00/[Link].2/usb1/1-1/1-1:1.0/host2/[Link]"
delete = <store method only>
detach_state = "0"
device_blocked = "0"
max_sectors = "240"
model = "USB DISK Pro "
queue_depth = "1"
rescan = <store method only>
rev = "1.08"
scsi_level = "3"

226
 Chapitre 8. Configuration du matériel et des périphériques

state = "running"
timeout = "30"
type = "0"
vendor = " "

Supposons à présent que les deux clefs se distinguent par le nom de leur modèle, par exemple « USB
DISK Pro » et « MINI DATA DRIVE ». Il est à présent possible d’affecter des fichiers spéciaux de
périphériques de manière fixe à chacune de ces clefs, en ajoutant les règles suivantes dans le fichier
[Link] :

BUS="scsi", KERNEL="sd[a-z]", SYSFS_model="MINI DATA DRIVE*", NAME="usbda"

BUS="scsi", KERNEL="sd[a-z][0-9]*", SYSFS_model="MINI DATA DRIVE*", NAME="usbda%n"
BUS="scsi", KERNEL="sd[a-z]", SYSFS_model="USB DISK Pro*", NAME="usbdb"
BUS="scsi", KERNEL="sd[a-z][0-9]*", SYSFS_model="USB DISK Pro*", NAME="usbdb%n"

Ces règles permettent d’associer aux périphériques SCSI normalement nommés « /dev/sdxx » les fichiers
spéciaux de périphériques /dev/usbda et /dev/usbdb (ainsi que les fichiers spéciaux de périphérique
pour accéder à leurs partitions) respectivement aux deux modèles de clefs USB. Vous noterez ici que le
mot clé SYSFS permet de récupérer les informations du système de fichiers virtuel /sys/ (en particulier,
ici, le nom du modèle des périphériques). Les caractères génériques sont utilisés afin de ne pas chercher
une correspondance trop stricte entre les noms de modèle et les critères de sélection. En effet, les noms
des modèles peuvent être suivis d’un ou de plusieurs espaces, qui ne sont pas significatifs ici.

Initialisation du système
Pour terminer cette description du mécanisme de création dynamique des fichiers spéciaux de
périphériques, signalons qu’il est nécessaire de créer manuellement les fichiers spéciaux des
périphériques des gestionnaires de périphériques intégrés au noyau lors de l’initialisation du système. En
effet, les événements hotplug ne sont pas émis par le noyau dans ce cas. Ces gestionnaires doivent donc
être recherchés dans le système de fichiers /sys/ et, pour chacun d’eux, udev doit être appelé
explicitement. Ce travail est généralement réalisé par le programme udevstart, que les distributions
exécutent au démarrage du système, après avoir mis en place l’éventuel système de fichier en mémoire
/dev/ (et /après avoir monté le système de fichiers virtuel /sys).

Notez bien que udevstart ne permet de créer les fichiers spéciaux de périphériques que pour les
périphériques dont les gestionnaires de périphériques sont chargés dans le noyau au moment de son
exécution. De même, udev ne permet de créer les fichiers spéciaux de périphériques que pour les
périphériques connectables à chaud. Par conséquent, aucun fichier spécial de périphérique ne sera créé
pour les périphériques classiques dont le gestionnaire de périphérique n’est pas chargé avant l’exécution
de udevstart. Comme aucune application ne peut accéder à ce fichier, le noyau ne chargera pas non plus
le module du gestionnaire de périphérique, et le périphérique ne fonctionnera pas. Ce problème se
rencontre par exemple pour le gestionnaire de périphérique du port parallèle et pour les vieux
périphériques ISA. Dans ce cas de configuration, il est recommandé soit d’intégrer les gestionnaires de
périphériques directement dans le noyau, soit de charger les modules correspondants dès le démarrage du
système, avant l’exécution de udevstart, soit de créer explicitement les fichiers spéciaux de
périphériques pour les périphériques en question après son exécution. Cette dernière solution peut être

227
 Chapitre 8. Configuration du matériel et des périphériques

mise en place en ajoutant des scripts d’initialisation complémentaires dans le répertoire

/etc/udev/scripts/.

Configuration des périphériques de masse

Les périphériques de masse sont les périphériques permettant de manipuler de grandes quantité de
données. Il s’agit généralement des périphériques connectés sur bus SCSI, des disques durs et lecteurs de
CD/DVD, des graveurs et des scanners.

Configuration des périphériques SCSI

Les périphériques de qualité sont généralement connectés sur bus SCSI, en raison des capacités de
celui-ci en termes de débit et de performances. En particulier, les disques durs SCSI restent privilégiés
sur les systèmes haut de gamme comme les serveurs par exemple, parce que le bus SCSI permet
d’utiliser plusieurs périphériques simultanément.
Sous Linux, les périphériques SCSI sont accédés par l’intermédiaire des fichiers spéciaux de
périphériques /dev/sdx pour les disques durs ou /dev/scdn pour les lecteurs ou les graveurs de
CD-ROM, où x est la lettre définissant le disque dur et n est le numéro du lecteur ou du graveur de
CD-ROM. Les autres périphériques SCSI sont accédés par l’intermédiaire des fichiers spéciaux de
périphériques SCSI génériques, à savoir les fichiers /dev/sgn. Notez que certains périphériques
pourront être utilisés par l’un ou l’autre de ces fichiers spéciaux, selon la fonctionnalité à laquelle on
cherche à accéder. Par exemple, les programmes de gravage utilisent les fichiers spéciaux de
périphériques /dev/sgn pendant le gravage, alors que la simple lecture d’un CD avec un graveur se fait
via le fichier spécial de périphérique /dev/scdn correspondant.
La prise en charge des périphériques SCSI se fait au niveau du noyau pour les fonctionnalités de base. En
réalité, la configuration des périphériques SCSI se restreint à celle de la carte SCSI utilisée. Les
fonctionnalités de plus haut niveau sont reléguées au niveau applicatif. Par exemple, la prise en charge
des différents graveurs SCSI du marché est réalisée par les logiciels de gravage eux-mêmes, de même
que la prise en charge des différents scanners l’est par les logiciels d’acquisition d’image.
La gestion des contrôleurs SCSI au niveau du noyau se fait par l’intermédiaire des options du menu
« SCSI support » du programme de configuration du noyau. Outre l’option « SCSI support » que l’on
activera bien évidemment, ce menu comprend les options suivantes, que l’on choisira en fonction du type
des périphériques SCSI à utiliser :

• « SCSI disk support », pour les disques durs SCSI, ainsi que pour certains périphériques de masse
qui apparaissent comme des disques durs SCSI (c’est en particulier le cas pour les clefs USB et un
grand nombre d’appareils photo numériques) ;
• « SCSI tape support », pour les lecteurs de cartouches SCSI. Les possesseurs de lecteurs de
cartouches OnStream SC-x0 devront plutôt utiliser l’option « SCSI OnStream SC-x0 tape
support », car le gestionnaire de périphériques standard n’est pas capable de les prendre en charge ;

228
 Chapitre 8. Configuration du matériel et des périphériques

• « SCSI CD-ROM support », pour les lecteurs de CD-ROM SCSI et pour les graveurs de CD-ROM
IDE, si l’on décide d’utiliser l’émulation SCSI avec certains logiciels de gravage (voir plus loin pour
plus de détails à ce sujet) ;
• « SCSI generic support », pour les autres périphériques dont l’utilisation requiert l’utilisation
d’un programme applicatif spécifique. Il s’agit ici des graveurs de CD, des scanners et autres
périphériques spéciaux.

Certains périphériques SCSI disposent de plusieurs numéros d’unités logiques sur leur bus. Il peut donc
être nécessaire, pour ces périphériques, d’activer l’option « Probe all LUNs on each SCSI
device » afin de pouvoir les utiliser correctement. Les autres options ne sont pas essentielles, consultez
leur aide pour plus de détails à leur sujet.
En plus des options générales de la prise en charge du SCSI, il est impératif de sélectionner le
gestionnaire de périphériques capable de piloter votre contrôleur SCSI. Cela peut être fait dans le
sous-menu « SCSI low-level drivers ». Vous devrez y activer la prise en charge pour votre matériel,
aucune règle ne peut donc être définie à ce niveau. Consultez la documentation de votre matériel pour
déterminer le gestionnaire de périphériques adéquat à utiliser.
Une fois la configuration du noyau effectuée, vous n’avez plus qu’à le compiler et à l’installer pour
pouvoir utiliser vos périphériques. La manière de procéder a été décrite en détail dans la la section
intitulée Compilation du noyau Linux dans Chapitre 7.

Configuration des disques durs IDE

Les disques durs IDE ont longtemps souffert d’un gros défaut par rapport aux disques SCSI : celui de ne
pas pouvoir effectuer des opérations sans l’intervention du processeur. En effet, l’envoi des données aux
disques se faisaient classiquement par de nombreuses écritures dans les ports d’entrée/sortie des
contrôleurs de disques, obligeant ainsi le système à consacrer une part importante des ressources
processeur uniquement pour les accès disque. Ce défaut a été corrigé avec la montée en puissance du
mode DMA (abréviation de l’anglais « Direct Memory Access »). Le mode DMA des périphériques IDE
existe depuis les tous débuts de l’architecture PC, mais les premiers contrôleurs DMA n’étaient pas
capables de suivre la cadence des disques dur, même des plus anciens. Il n’a donc malheureusement pas
été utilisé pendant longtemps, jusqu’à ce qu’une nouvelle technologie soit mise au point : l’Ultra DMA.
La plupart des jeux de composants des cartes mères modernes sont à présent capables de gérer l’Ultra
DMA, dont les fréquences de bus les plus courantes sont 33, 66 et 100MHz.

Note : Même si les interfaces IDE ont à présent réduit l’écart avec les interfaces SCSI au niveau du
taux de transfert des données, elles ont toujours un train de retard par rapport à elles. En effet, les
périphériques SCSI sont d’une part capables de communiquer entre eux sur leur bus, déchargeant
ainsi totalement le processeur de ce travail de transfert des données, et d’autre part capables de
traiter plusieurs requêtes d’affilée sans l’intervention du processeur. Ces fonctionnalités déchargent
le bus système, mais sont également extrêmement utiles pour les systèmes d’exploitation
multitâches. Ceux-ci peuvent en effet envoyer plusieurs commandes aux périphériques et effectuer
d’autres traitements pendant qu’elles s’exécutent en asynchrone. Les disques SCSI ont donc un
taux d’occupation du processeur et du bus système nettement moindre, et permettent aux systèmes
tels que Linux d’atteindre un degré de réactivité inégalé avec les disques IDE classiques. Cela dit,
les périphériques IDE coûtent nettement moins cher que les périphériques SCSI, et c’est sans doute
là la clef de leur succès.

229
 Chapitre 8. Configuration du matériel et des périphériques

En général, Linux configure les contrôleurs des disques durs de manière quasi optimale, et il n’est
généralement pas nécessaire de modifier leur paramétrage. Cependant, les contrôleurs IDE peuvent être
configurés ou optimisés manuellement grâce à l’utilitaire hdparm. Comme son nom l’indique, cet
utilitaire permet de modifier les paramètres des disques durs et des contrôleurs IDE. Il permet également
de tester les performances de votre configuration, et peut donc servir d’outil de diagnostic très utile. La
mesure du débit de votre sous-système disque (sans les mécanismes de cache du système) peut être en
effet réalisée facilement avec la commande suivante :

hdparm -t périphérique

où périphérique est le fichier spécial de périphérique de votre disque dur.

Note : Si vous obtenez des valeurs inférieures ou égales à 6 Mo/s, vous avez réellement un
problème de configuration. Les premiers disques UltraDMA 33 peuvent atteindre facilement 8 à 10
Mo/s, les disques UltraDMA 66 atteignent facilement 17 à 22 Mo/s, et les disques les plus récents en
UltraDMA 100 peuvent aller encore bien au delà.
Faites bien attention à ne pas utiliser l’option -T à la place de l’option -t. En effet, vous mesureriez
le débit dans le sous-système disque complet de Linux, avec ses mécanismes de cache. Vous
obtiendriez alors des taux de transfert nettement plus grands (dix fois plus au moins), qui ne
représenteraient pas le taux de transfert réel de votre interface IDE.

L’utilitaire hdparm permet également de fixer un certain nombre de paramètres des disques durs. Par
exemple, l’activation ou la désactivation de l’UltraDMA se fait simplement avec l’option -d. Cette
option prend en paramètre un entier pouvant valoir 1 ou 0, selon que l’UltraDMA doit être activé ou non.
Cette option peut être complétée d’autres options d’optimisation pour les disques modernes, pour
lesquels on peut également préciser le mode de transfert à utiliser. Ce mode peut être indiqué à l’aide de
l’option -X, qui prend en paramètre un nombre dont la valeur est le numéro du mode plus une constante
identifiant le type de transfert utilisé. Les transferts de type PIO (c’est à dire le mode dans lequel le
processeur effectue lui-même les transferts par l’intermédiaire des ports d’entrée / sortie) utilisent la
constante 8, les transferts de type DMA simple utilisent la constante 32, et les transferts en UltraDMA
utilisent la constante 64. Ainsi, la sélection du mode UltraDMA mode 2 pour le disque maître du premier
contrôleur IDE se fait avec la commande suivante :

hdparm -d1 -X66 /dev/hda

La valeur 66 utilisée ici signifie donc que les transfers se font en UltraDMA (constante 64), mode 2
(valeur 2).

Note : Pour que l’UltraDMA soit utilisable, il faut bien entendu que les pilotes IDE de votre noyau
Linux le gèrent. Généralement, les noyaux des distributions en sont capables, mais si d’aventure ce
n’était pas le cas, vous devriez recompiler votre noyau. Les options à activer dans le programme de
configuration du noyau sont les options suivantes du menu « ATA/IDE/MFM/RLL support » :

• « Generic PCI IDE chipset support » du menu « IDE, ATA and ATAPI Block devices » ;

• « Generic PCI bus-master DMA support » ;

230
 Chapitre 8. Configuration du matériel et des périphériques

• « Use PCI DMA by default when available ».

Vous devrez également activer le support pour les jeux de composants utilisés par votre carte mère.

L’utilitaire hdparm permet également d’activer et de désactiver le mode 32 bits de ces contrôleurs à
l’aide de l’option -c. Comme pour l’option -d, l’option -c prend en paramètre un indicateur pouvant
valoir 1 ou 0 et permettant d’activer ou de désactiver le mode 32 bits du contrôleur. Notez que certains
contrôleurs ne supportent pas correctement le mode de fonctionnement 32 bits et peuvent perdre des
données si vous l’activez.

Note : Prenez garde lorsque vous utilisez la commande hdparm. Si vous spécifiez des paramètres
incorrects ou non pris en charge par votre matériel, vous pouvez fort bien bloquer complètement vos
contrôleurs IDE, et planter ainsi le système en un temps très court. Si d’aventure cela se produisait,
il faudrait attendre un peu de temps, jusqu’à ce que le système s’aperçoive de la mauvaise
configuration des contrôleurs et les réinitialisent avec leurs paramètres initiaux. Vous pouvez
détecter ce genre de réinitialisation dans les messages du noyau, que vous pouvez à tout moment
afficher avec la commande dmesg. Sachez toutefois que le risque de corruption du système de
fichiers en cas de mauvaise configuration reste bien réel, et qu’il vaut mieux un système légèrement
plus lent qu’un système qui détruit vos données en un temps record.

Lorsque vous aurez trouvé les paramètres optimaux de vos contrôleurs de disque, vous pourrez demander
au système de conserver ces paramètres par défaut en ajoutant l’option -k1 dans la ligne de commande
de hdparm. Par exemple, pour configurer de manière permanente le premier disque IDE en UltraDMA
mode 2 et en accès 32 bits, il faut utiliser la commande suivante :

hdparm -c1 -d1 -X66 -k1 /dev/hda

Note : Prenez garde toutefois au fait que les réinitialisations du contrôleur en cas d’erreur
reprendront systématiquement les mêmes paramètres, ce qui peut réellement bloquer complètement
votre sous-système disque (et planter irrémédiablement votre système). Dans ce cas, il ne vous
restera plus que le redémarrage brutal, avec les risques de pertes de données qui en découlent.

La configuration des disques durs et des contrôleurs IDE pourra également être ajoutée dans le script de
démarrage de votre système. Ce script est généralement placé dans le répertoire /etc/rc.d/ ou dans le
répertoire /sbin/init.d/ selon votre distribution. Bien entendu, il faut réellement être sûr de la
commande de configuration utilisée, car elle sera exécutée systématiquement à chaque démarrage.

Installation d’un graveur de CD/DVD

Linux dispose de tous les logiciels permettant de graver des CD ou des DVD, et ce avec la plupart des
graveurs disponibles sur le marché. Il permet de copier des CD et de créer des images disques.
Cependant, il n’est pas encore possible d’utiliser le gravage par paquet, qui permettrait d’utiliser les

231
 Chapitre 8. Configuration du matériel et des périphériques

graveurs de CD comme des périphériques de sauvegarde amovibles. Cette fonctionnalité est en effet
encore à l’étude, elle sera sans doute disponible sous peu.

Notions de base sur le gravage sous Linux

Originellement, tous les graveurs de CD/DVD utilisaient l’interface SCSI. Ce n’est que plus tard que les
graveurs sur port parallèle et les graveurs IDE ATAPI sont apparus. Actuellement, les graveurs externes
connectés sur port parallèle sont de moins en moins vendus. Les graveurs IDE on fait une belle percée et
sont les plus courants actuellement. Les logiciels de gravage doivent donc toutefois être capable
d’utiliser n’importe quel type de graveur, ce qui n’est pas simple. Heureusement, le protocole de
communication ATAPI n’est rien d’autre qu’un mode de transport de commandes SCSI pour les
périphériques IDE, ce qui fait que les logiciels de gravage peuvent utiliser les deux types de
périphériques de manière relativement générique.
Les anciennes versions des logiciels de gravage ne permettaient d’utiliser que l’interface SCSI pour
graver des CD. Il n’était donc pas possible d’utiliser les graveurs IDE de manière native. Une couche
d’émulation SCSI a donc été développée dans Linux afin de simuler une interface SCSI pour les
périphériques IDE, et de traduire à la volée les commandes SCSI en commandes ATAPI. À présent, les
logiciels de gravage sont tous capables d’utiliser nativement les graveurs IDE, et cette couche
d’émulation n’est plus que très rarement nécessaire. Elle ne sera donc pas décrite plus en détail ici.

Configuration du noyau
L’utilisation des graveurs de CD/DVD ne requiert généralement pas d’option particulière au niveau de la
configuration. Autrement dit, si vous pouvez utiliser votre graveur comme un simple lecteur, alors vous
pouvez également l’utiliser pour graver. Cependant, il peut-être intéressant d’activer le support de
certains systèmes de fichiers pour utiliser correctement les lecteurs et les graveurs.
Les principales options de configuration du noyau ayant trait aux lecteurs et aux graveurs de CD/DVD
sont récapitulées ci-dessous :

« Loopback device support »

Cette option permet d’activer une fonctionnalité permettant d’utiliser un fichier comme un
périphérique normal. Elle est très utile pour tester les images de CD, car il suffit simplement de
monter le fichier image comme un périphérique « loopback ». Il est donc recommandé d’activer
cette fonctionnalité, que l’on dispose d’un graveur SCSI ou IDE. Cette fonctionnalité peut être
activée sous la forme de module ou non, la réponse recommandée est ’Y’.

« Include IDE/ATA-2 CDROM support »

Cette option permet d’activer la gestion des lecteurs de CD IDE ATAPI. Vous devez répondre à cette
question par ’Y’ si vous disposez d’un graveur ou d’un lecteur IDE, ce qui est généralement le cas.
La réponse recommandé est ’Y’.

« SCSI support »
Cette option permet d’activer la gestion des périphériques SCSI dans votre noyau. Il va de soi qu’il
faut l’activer si vous disposez d’un graveur SCSI. Cette fonctionnalité peut être activée sous forme
de module ou non. La réponse recommandée est ’N’.

232
 Chapitre 8. Configuration du matériel et des périphériques

« SCSI CD-ROM support »

Cette option permet d’activer la gestion des lecteurs de CD SCSI. Il faut l’activer si l’on dispose
d’un graveur SCSI. La réponse recommandée est ’Y’ si vous disposez d’un lecteur ou d’un graveur
SCSI, et ’N’ dans le cas contraire.

« Enable vendor-specific extensions (for SCSI CDROM) »

Cette option permet d’autoriser l’emploi d’extensions au protocole SCSI définies par les fabricants
de matériels. Certains graveurs utilisent de telles extensions, c’est en particulier le cas des graveurs
de CD HP. Toutefois, si vous ne disposez pas d’un tel graveur, il est peu probable que vous ayez à
activer cette fonctionnalité. La réponse recommandée est donc ’N’.

« SCSI generic support »

Cette option permet d’utiliser les périphériques SCSI avec des commandes non standards, ce qui
requiert l’emploi de programmes capables de communiquer directement avec les périphériques
SCSI. C’est le cas pour les graveurs, qui seront pilotés directement par les logiciels de gravage. Il
faut généralement activer cette fonctionnalité si l’on dispose de périphérique SCSI, aussi la réponse
recommandée est-elle ’Y’ si l’on se trouve dans cette situation.

« Probe all LUNs on each SCSI device »

Cette option permet, lorsqu’on dispose de périphériques SCSI capables de gérer plusieurs numéros
d’unité logiques, de leur demander tous ces numéros. Ce type de périphérique est assez rare, et en
général chaque périphérique n’utilise qu’un et un seul numéro d’unité logique. Il ne faut donc pas,
en général, activer cette fonctionnalité. La réponse recommandée pour cette question est donc ’N’.

« ISO 9660 CDROM file system support »

Cette option permet de prendre en charge les systèmes de fichiers des CD-ROMs. Il est impératif
d’activer cette fonctionnalité, aussi la réponse recommandée pour cette question est-elle ’Y’.

« Microsoft Joliet CDROM extensions »

Cette option permet de prendre en charge les extensions Microsoft au système de fichiers ISO 9660
(pour la gestion des noms longs du DOS). Étant donné le nombre de CDs qui utilisent ces
extensions, il est impératif d’activer cette fonctionnalité. La réponse recommandée pour cette
question est donc ’Y’.

« UDF file system support »

Cette option permet de prendre en charge les systèmes de fichiers UDF, utilisé par certains
CD-ROMs gravés par paquets et par tous les DVDs. Il est impératif d’activer cette fonctionnalité,
aussi la réponse recommandée pour cette question est-elle ’Y’.

Enfin, il faut choisir le pilote bas niveau permettant de gérer son graveur de CD. Pour les graveurs IDE
ATAPI il n’y a pas de pilote bas niveau à inclure. Pour les graveurs SCSI, il faut choisir le pilote
approprié de votre carte ou de votre contrôleur SCSI.
Une fois cette configuration effectuée, il ne reste plus qu’à compiler le noyau et les modules et à les
installer. La manière de procéder a été décrite dans la section traitant de la compilation du noyau.

233
 Chapitre 8. Configuration du matériel et des périphériques

Configuration des modules du noyau

Vous aurez sans doute à modifier le fichier de configuration /etc/[Link] si vous avez activé
certaines fonctionnalités SCSI sous la forme de modules, afin de charger les modules nécessaires
lorsqu’une commande sera effectuée sur l’un des fichiers spéciaux de périphériques SCSI. Si toutes les
fonctionnalités SCSI sont intégrées au noyau, cette étape est bien entendue facultative. Les fichiers
spéciaux utiles pour les périphériques blocs SCSI sont les fichiers scdx et sgx, où x est le numéro du
périphérique. Les fichiers spéciaux du premier groupe sont de type bloc, et permettent d’accéder aux
lecteurs de CD SCSI. Les fichiers du deuxième groupe en revanche sont de type caractère, et permettent
d’accéder aux périphériques SCSI de manière générique. Les codes majeurs pour ces deux groupes de
fichiers spéciaux sont respectivement 11 et 21, il faut donc ajouter les entrées du fichier
[Link] pour les modules nommés block-major-11 et char-major-21. Normalement, ces
entrées sont déjà présentes dans le fichier fourni par votre distribution.

Installation des logiciels de gravage

Lorsque le noyau aura été correctement configuré et installé, il ne vous restera plus qu’à installer les
logiciels de gravage. Les logiciels indispensables sont les suivants :

• cdrecord, qui permet de piloter le graveur de CD et d’effectuer les tâches nécessaires pour le gravage ;
• mkisofs, qui permet de créer des images disques ISO 9660, éventuellement avec les extensions Joliet
(CD Windows 95), Rock Ridge (CD Unix) ou HFS (CD Macintosh) ;
• cdda2wav, qui permet d’extraire les données numériques des CD audio ;
• cdrdao, qui permet de réaliser des gravages bas niveau et en mode « Disk At Once ».

Vous pourrez vérifier que votre configuration fonctionne correctement si vous disposez d’un périphérique
SCSI ou si vous utilisez l’émulation SCSI avec la commande suivante :

cdrecord -scanbus

Cette commande recherche tous les périphériques SCSI du système. Vous devrez normalement y trouver,
en plus de vos autres périphériques SCSI, votre graveur de CD. Cette commande ne fonctionne pas si
vous utilisez un graveur IDE.

Utilisation des logiciels de gravage

Nous allons à présent voir les commandes permettant de faire les principales opérations ayant trait au
gravage des CDs. Bien que ce document soit consacré à l’installation de Linux et non à son utilisation,
elles vous permettront de tester si tout fonctionne correctement.
La copie directe d’un CD peut se faire avec la commande suivante :

cdrecord -dummy -v dev=graveur speed=n -isosize /dev/source

234
 Chapitre 8. Configuration du matériel et des périphériques

L’option dev permet de spécifier le périphérique du graveur à utiliser. Cette option peut prendre en
paramètre soit le fichier spécial de périphérique du graveur (par exemple /dev/hdc), soit un triplet de
valeur permettant d’identifier un périphérique sur le bus SCSI (par exemple 0,1,0). La première valeur
représente le bus SCSI sur lequel le graveur est branché, la deuxième le numéro de périphérique du
graveur sur ce bus SCSI et la troisième son numéro d’unité logique (« Logical Unit Number »). Le
numéro du bus SCSI et le numéro de périphérique peuvent être obtenus avec la commande cdrecord
-scanbus présentée ci-dessus si vous utilisez un graveur SCSI. Le numéro d’unité logique est, dans la
majorité des cas, 0.
Le nombre n donné dans la ligne de commande précédente doit valoir le facteur multiplicateur de la
vitesse de gravage. Vous pouvez essayer avec des valeurs faibles pour commencer, afin d’être sûr que
tout se passe bien. Le fichier de périphérique /dev/source quant à lui représente le fichier spécial de
périphérique du lecteur de CD utilisé pour lire le CD-ROM. L’option -isosize permet de demander à
cdrecord de lire la taille de la piste à graver dans le système de fichiers ISO9660 du CD source. Enfin,
l’option -dummy permet de faire toutes les opérations en conservant le laser du graveur éteint, ce qui
revient à faire un test. Si vous voulez réellement graver votre CD, il suffit de supprimer cette option.
Il va de soi que si vous ne disposez pas d’un lecteur de CD en plus de votre graveur, vous ne pouvez pas
utiliser la commande précédente. Dans ce cas, vous devrez faire une image disque en extrayant toutes les
données du CD source. Cela peut être réalisé avec la commande suivante :

dd if=/dev/source of=image

où /dev/source est le fichier spécial de périphérique du lecteur utilisé pour faire l’image, et image est
le fichier image qui doit être créé.
Le gravage d’une image disque peut être réalisé avec la commande suivante :

cdrecord -dummy -v dev=graveur speed=n -data image

où les options sont les mêmes que dans les commandes précédentes.
Si vous désirez créer une image disque à partir des fichiers de votre disque dur, vous pouvez utiliser
mkisofs. Ce programme permet de créer une image disque ISO9660, avec les extensions Rock Ridge
pour activer les fonctionnalités des systèmes de fichiers Unix (noms de fichiers plus longs, liens
symboliques, droits d’accès...), et éventuellement les extensions Joliet utilisées par les systèmes
Windows 95, Windows NT, Windows 2000 et XP (noms de fichiers longs Microsoft). Le prix à payer
pour cette amélioration est la perte de quelques centaines de kilo octets, ce qui est dérisoire étant donné
le gain en portabilité. La ligne de commande à utiliser pour créer une image disque est la suivante :

mkisofs [-J][-r | -R][-hfs | -apple] [-C début,fin [-M disque]] \

[-V "nom"] -o image répertoires

Les options -r ou -R, -J et -hfs ou -apple permettent respectivement d’utiliser les extensions Rock
Ridge, Joliet ou HFS (pour les disques devant être lus sur les Macintosh). Il est possible de faire des
images disque hybrides, qui pourront être lues sur plusieurs systèmes d’exploitation différents. La seule
contrepartie est la perte de quelques dizaines de kilo-octets, ce qui est dérisoire. La distinction entre
l’option -r et l’option -R est que -r modifie les attributs des fichiers Unix afin que le CD puisse être
utilisé sur un autre ordinateur que celui sur lequel le CD a été créé. En particulier, le propriétaire et le
groupe des fichiers voient leurs valeurs fixées à 0. L’option -V permet de fixer le nom du volume dans

235
 Chapitre 8. Configuration du matériel et des périphériques

l’image. Il est possible de placer ce nom entre guillemets. Cette fonctionnalité est intéressante si ce nom
comprend des espaces.
Il est possible de créer des CD multisessions à condition de spécifier l’emplacement de cette session lors
de la création de l’image disque. Cela se fait avec l’option -C de mkisofs. Cette option prend en
paramètre le numéro du secteur de début et le numéro du secteur de fin de la session à la suite de laquelle
la nouvelle session doit être écrite, séparés par des virgules. Si l’on veut également importer la session
précédente (c’est-à-dire permettre l’accès aux données des sessions précédentes comme si elles étaient
également présentes dans la session à écrire), il faut utiliser l’option -M, à laquelle il faut indiquer le
fichier spécial de périphérique du lecteur contenant le disque dont la session doit être importée.
La détermination des secteurs de début et de fin de la session précédente peut être difficile, mais
cdrecord est capable d’obtenir cette information avec la commande suivante :

cdrecord dev=graveur -msinfo

Appelé ainsi, cdrecord affiche les secteurs de début et de fin de la dernière session du disque du lecteur
spécifié par son option dev, directement dans le format attendu par mkisofs.
L’option -o de mkisofs permet de spécifier le nom du fichier image qui doit être créé. Les paramètres
suivant l’option -o constituent la liste des répertoires et des fichiers qui doivent être insérés dans le
CD-ROM. Par défaut, chaque répertoire ou fichier indiqué en paramètre est placé dans le répertoire
racine du CD-ROM, et l’arborescence des sous-répertoires est respectée. Cependant, il est possible de
placer un des répertoires ou fichiers indiqués en paramètre dans un autre répertoire du CD-ROM, à l’aide
de la syntaxe suivante :

destination=source

où destination est le répertoire destination du CD-ROM, et source le répertoire ou le fichier source à

ajouter à l’image disque. De même, il est possible d’exclure certains sous-répertoires de l’image disque à
l’aide de l’option -x :

-x répertoire

Les sous-répertoires du répertoire indiqué seront également supprimés de l’image disque.

Vous pouvez tester votre image disque en la montant par l’intermédiaire du périphérique virtuel du noyau
loopback. Il faut pour cela que vous ayez activé la gestion de ce périphérique dans la configuration du
noyau. La commande à utiliser est la suivante :

mount -t iso9660 -o ro,loop=/dev/loop0 image /cdrom

où image est le nom de votre fichier image à tester. Cette commande monte le système de fichiers de
cette image dans le répertoire /cdrom. La commande umount peut être utilisée pour démonter ce
système de fichiers de la manière habituelle.
Lorsque votre image disque est satisfaisante, vous pouvez la graver avec la première ligne de commande
suivante :

cdrecord -v dev=graveur speed=n -multi -data image

Vous noterez la présence de l’option -multi, qui permet de demander à cdrecord de créer un disque
multisession. Bien entendu, vous pouvez vous passer de cette option si votre disque n’est pas
multisession.

236
 Chapitre 8. Configuration du matériel et des périphériques

La création d’une image disque nécessite d’avoir une place disque égale à la taille de la session à ajouter,
ce qui peut être contraignant. Sur les systèmes suffisamment puissants, il est possible de créer l’image
disque et de la graver à la volée en créant un tube entre mkisofs et cdrecord. Dans ce cas, il ne faut pas
donner de nom à l’image disque dans la ligne de commande de mkisofs, et utiliser l’option - dans la
ligne de commande de cdrecord pour lui demander de prendre les données sur son entrée standard.
Malheureusement, cette technique n’est pas utilisable facilement pour les disques multisessions, parce
que la lecture des informations de la session précédente peut se faire en même temps que le début du
gravage. Pour résoudre ce problème, il faut utiliser l’option -waiti de cdrecord, qui lui demande
d’attendre l’arrivée des premières données dans le tube avant d’ouvrir le fichier spécial de périphérique
du graveur. La ligne de commande complète devient alors assez complexe, comme vous pouvez en juger :

mkisofs -r -M périphérique -C ‘cdrecord dev=graveur -msinfo‘ \

fichiers | cdrecord -v dev=graveur speed=vitesse -multi -waiti -

Les commandes présentées ci-dessus ne permettent pas de travailler avec des CD audio. Pour extraire les
données audio d’un CD, vous devrez utiliser le programme cdda2wav» :

cdda2wav [-H] -B nom [-tdébut[+fin]] -O wav dev=graveur

L’option -H permet d’éviter la création des fichiers d’information .inf sur les pistes extraites par
cdda2wav. L’option -B permet d’utiliser le nom nom complété d’un numéro pour les fichiers son créés.
Les pistes seront donc stockées dans des fichiers portant les noms nom_01, nom_02, etc. L’option -t
permet d’indiquer la piste début et la piste fin afin de sélectionner les pistes dont les données audio
doivent être extraites. Si la piste de fin n’est pas précisée, toutes les pistes depuis la piste de début jusqu’à
la dernière piste du CD seront extraites. De même, si la piste de début n’est pas précisée, l’extraction
commencera à partir de la première piste. L’option -O permet d’indiquer le type de fichier de sortie, wav
indique ici que les fichiers créés seront au format WAV des fichiers son de Windows. Il est également
possible d’utiliser le type de fichier raw, avec lequel les fichiers seront prêts à être gravés tels quels.
Enfin, l’option dev permet de spécifier le périphérique à utiliser pour lire les données audio. La syntaxe
de cette option est la même que celle utilisée par cdrecord.
Le gravage des pistes audio peut être réalisé avec la commande suivante :

cdrecord -dummy -v dev=graveur speed=n -nofix -audio [Link] \

[Link] ...

L’option -nofix permet ici d’éviter de fermer la session. Elle doit être utilisée si l’on désire rajouter des
pistes audio sur le CD-ROM ultérieurement. Si, en revanche, elle est omise, cdrecord fermera
automatiquement la session après l’écriture de la dernière piste, et plus aucune donnée ne pourra être
ajoutée. La commande suivante vous permettra de fixer le disque a posteriori :

cdrecord -dummy -v dev=graveur speed=n -fix

Enfin, si vous disposez d’un graveur de CD réinscriptible, vous pourrez utiliser la commande suivante
pour effacer un CDRW :

237
 Chapitre 8. Configuration du matériel et des périphériques

cdrecord -dummy -v dev=graveur -blank=fast

où graveur représente toujours le périphérique du graveur.

Il est peu probable que vous ayiez à utiliser ces commandes directement, car il existe de nombreux
programmes graphique capable de les piloter de manière conviviale (k3b, gcombust, xcdroast, etc.). Il
est vivement recommandé d’en installer un et de l’utiliser. Ils sont relativement simples d’emploi et leur
utilisation ne devrait pas poser de problème particulier.

Configuration des cartes filles

Il existe un grand nombre de cartes filles sur le marché, dont les plus courantes sont sans doute les cartes
graphique, les cartes son et les cartes réseau. Toutes ces cartes permettent d’ajouter des fonctionnalités
de manière modulaire à une machine, en les enfichant dans les emplacements prévus à cet effet sur la
carte mère.
Les cartes les plus vielles que l’on peut encore rencontrer sont les cartes ISA. La configuration de ces
cartes a toujours été extrêmement difficile, en raison des nombreux conflits matériels qu’elles
provoquaient entre elles et avec les ressources de la carte mère. Le standard Plug and Play a été introduit
pour limiter ces problèmes par la suite, mais ce n’est qu’avec l’arrivée des cartes PCI que l’on a enfin pu
commencer à brancher n’importe quoi n’importe comment dans un ordinateur (cela dit, ce n’est pas
encore la panacée parce que l’on est toujours obligé d’éteindre l’ordinateur...). Enfin, les cartes
graphiques ne se connectent plus de nos jours ni sur les ports PCI, ni sur les ports ISA, pour des raisons
de performances et de débit de données. Elles utilisent un port spécial, le port AGP. Cela ne pose
cependant pas de problème de configuration spécial (du moins si l’on se contente d’une seule carte
graphique).
Ce chapitre traite de la manière de configurer les cartes ISA et PCI en général, et donne des informations
plus détaillées pour chacun des types courants de cartes filles.

Généralités sur les cartes ISA, Plug And Play et PCI

L’architecture initiale des PC a très mal vieilli et souffre actuellement de défauts majeurs qui nuisent à
leur développement. Sans parler des goulots d’étranglement sur les différents bus systèmes qui ne suivent
plus les vitesses des processeurs actuels, la plupart des périphériques sont obligés de se restreindre à des
protocoles de communication obsolètes pour conserver une compatibilité ascendante. L’une des
limitations majeurs de cette architecture est le nombre incroyablement restreint de lignes d’interruption
permettant à un périphérique de signaler au processeur qu’il a besoin de l’intervention de son
gestionnaire pour poursuivre son travail, et la quasi absence des possibilités d’accès directs à la mémoire,
qui impose l’utilisation du processeur pour réaliser de simples transferts de données entre les
périphériques et la mémoire.
Ces ressources limitées, en plus de pénaliser les performances, posent des problèmes évidents
d’extensibilité. En effet, qui dit ressource limité dit qu’il est impossible de connecter plus de
périphériques « intelligents » que ce que l’architecture matérielle autorise. L’installation de plusieurs
cartes ISA gérant chacune une interruption ou un canal DMA était réellement un casse-tête il y a encore
peu de temps. C’est pour résoudre ces problèmes de configuration du matériel que le standard Plug and

238
 Chapitre 8. Configuration du matériel et des périphériques

Play a été développé. Ce standard établit un protocole de communication matériel permettant au BIOS de
configurer automatiquement les périphériques ISA en évitant les conflits sur les ressources partagées (le
plus souvent, les lignes d’interruption).
Ce protocole a soulagé bien des gens, mais suppose un support spécifique de la part du système
d’exploitation, puisque les paramètres matériels de chaque carte Plug and Play ne sont pas fixés d’un
démarrage à l’autre de la machine. Il faut donc que le système soit ou capable de récupérer ces
paramètres, ou de refaire la configuration du matériel. Cette deuxième solution est souvent imposée par
le fait que bon nombre de BIOS sont bogués et effectuent une mauvaise configuration des cartes Plug
and Play.
Le Plug and Play a été une amélioration sensible, mais n’a pas résolu les problèmes concernant les
ressources limitées des PC. Heureusement, depuis l’avènement du bus PCI, ces limitations se sont
estompées. En effet, le bus PCI permet non seulement aux périphériques de s’autoconfigurer et de se
déclarer dans le système PCI, mais également de partager une même ligne d’interruption et de prendre le
contrôle du bus mémoire. Ainsi, il n’y a virtuellement plus aucune difficulté pour installer une carte PCI
dans un ordinateur. De nos jour, on ne trouve quasiment plus de cartes ISA, et la plupart des cartes mères
n’acceptent même plus ces cartes.
Mais ne croyez pas pour autant que le bus PCI soit idéal, c’est loin d’être le cas. En effet, il ne permet
pas encore l’ajout et la suppression de cartes à chaud (c’est-à-dire lorsque le système est allumé), et
fonctionne désormais à une vitesse bien trop faible compte tenu de la vitesse des processeurs, cartes
graphiques et circuits mémoire. Il est donc encore appelé à évoluer.
Le sous-système PCI de Linux permet d’utiliser directement les cartes PCI, sans configuration
particulière. Les périphériques ISA, en revanche, peuvent être plus difficiles à configurer. S’ils ne sont
pas Plug and Play, il n’y a pas d’autre choix que de spécifier leurs paramètres matériels directement, soit
lors de la compilation du noyau, soit à l’aide d’options de boot lorsque le système démarre, soit à l’aide
d’options dans le fichier /etc/[Link] si leur gestionnaire est compilé sous forme de module.
La première solution est la plus technique, puisqu’elle nécessite de reconfigurer et de recompiler le
noyau, les deux autres relèvent de la configuration simple.
Les cartes ISA Plug and Play constituent un cas à part car, comme il l’a été dit ci-dessus, la plupart des
BIOS Plug and Play sont bogués et les initialisent mal. Il est donc nécessaire que le système les initialise
lui-même, et détermine par la même occasion leur configuration matérielle. En pratique, il existe deux
possibilités pour effectuer ces deux opérations. La première possibilité est de laisser le noyau faire tout le
travail de configuration des cartes et d’allocation des ressources. La deuxième possibilité est d’effectuer
la configuration des cartes ISA Plug and Play au niveau applicatif dans les scripts de démarrage du
système. Cette solution est relativement technique, et ne doit être utilisée que lorsqu’on désire contrôler
finement les ressources allouées par les périphériques dans le système.
Si l’on désire utiliser les fonctionnalités Plug and Play du noyau, il n’y a strictement rien à faire. Linux
se charge simplement d’initialiser automatiquement les cartes ISA Plug and Play lors du démarrage du
système, de leur attribuer les paramètres matériels adéquats, et de communiquer ces paramètres aux
gestionnaires de périphériques. Il prendra également en charge la gestion des conflits avec les autres
périphériques, qu’ils soient ISA non Plug and Play ou PCI. Par conséquent, vous n’aurez aucune
configuration spécifique à effectuer.
Mais Linux fournit également la possibilité de contrôler soi-même les ressources allouées à chaque
périphérique, pour ceux qui veulent avoir la maîtrise totale de leur matériel ou ceux qui ont une
configuration tellement spécifique qu’elle nécessite un paramétrage manuel. Dans ce cas, l’initialisation
des cartes ISA Plug and Play ne se fera pas lors du démarrage du noyau, mais plutôt ultérieurement. En

239
 Chapitre 8. Configuration du matériel et des périphériques

général, on effectue cette tâche dans les scripts d’initialisation du système, mais ce n’est pas une
obligation. Quoi qu’il en soit, comme l’attribution des ressources aux cartes est différée, les gestionnaires
de périphériques ne peuvent pas être inclus dans le noyau. Il est donc nécessaire d’utiliser les modules du
noyau pour ces gestionnaires. Les paramètres matériels pourront alors être communiqués simplement à
ces gestionnaires lors du chargement des modules, à l’aide d’options dans le fichier de configuration
/etc/[Link].

La configuration manuelle des cartes ISA Plug and Play se fait classiquement à l’aide des outils
« isapnp ». Parmi ces outils se trouve le programme isapnp, que l’on utilise pour initialiser les cartes
ISA Plug and Play. Cet utilitaire utilise les informations qui se trouvent écrite dans le fichier de
configuration /etc/[Link] pour déterminer les plages d’entrée/sortie, les canaux DMA et les
lignes d’interruption à utiliser pour chaque carte.
La rédaction manuelle du fichier [Link] n’est pas une tâche aisée. Heureusement, cela peut être
réalisé automatiquement, à l’aide d’un autre utilitaire nommé pnpdump. Celui-ci affiche la liste des
différentes possibilités de configuration pour chaque périphérique ISA Plug and Play. Cette liste est
affichée exactement sous une forme exploitable par isapnp, ce qui fait qu’il est très simple de créer un
fichier de configuration correct en faisant une redirection de sa sortie standard dans un fichier :

pnpdump > /etc/[Link]

Le fichier de configuration ainsi créé contient les différentes configurations possibles. Cependant, elles
sont toutes commentées, et aucun périphérique ISA ne sera configuré sans intervention supplémentaire.
Il va donc falloir éditer ce fichier et retirer les commentaires devant les options de configuration qui vous
intéressent. Les lignes de commentaires commencent toutes par un caractère dièse (’#’). Il suffit donc
d’effacer ce caractère pour les décommenter. Vous devez choisir les options à décommenter de telle
manière qu’aucun conflit d’adresse, d’interruption ou de canal DMA n’existe dans votre système. Pour
chaque périphérique, plusieurs possibilités sont offertes, mais vous ne devez retirer les commentaires que
devant les lignes d’une seule de ces possibilités. Les zones à décommenter sont clairement identifiées
dans le fichier [Link] généré par pnpdump, il vous suffit donc d’effectuer le choix de la
configuration à utiliser. Enfin, il ne faut pas oublier de retirer le commentaire devant la ligne suivante :

(ACT Y)

à la fin des différentes options de configuration pour chaque carte correctement configurée, faute de quoi
elle ne sera pas activée lors de l’appel à isapnp.
En général, il est souhaitable d’appeler la commande isapnp à chaque démarrage du système, dans un
des scripts de démarrage. Vous devrez donc inclure une ligne telle que celle-ci :

/sbin/isapnp /etc/[Link]

dans le fichier de démarrage principal de votre système. Ce fichier peut se trouver dans le répertoire
/etc/rc.d/ (ou dans /sbin/init.d/ selon la distribution que vous utilisez). La plupart des
distributions permettent de paramétrer l’appel à cette commande à l’aide d’une option de configuration
modifiable à l’aide de leur programme de configuration. Consultez la documentation de votre distribution
pour plus de détails à ce sujet.
Une fois que vous aurez déterminé la configuration correcte pour vos périphériques dans le fichier
/etc/[Link], vous pourrez charger les modules du noyau gérant ces périphériques. Cela peut

240
 Chapitre 8. Configuration du matériel et des périphériques

nécessiter la modification du fichier /etc/[Link]. Afin de limiter les risques d’erreur, vous
devriez procéder comme suit :

• déterminer le fichier spécial de périphérique utilisé par les applications pour accéder à votre
périphérique ;
• déterminer le nom du module que le noyau tentera de charger lorsqu’un programme tentera d’utiliser
ce fichier spécial de périphérique ;
• rechercher la ligne définissant l’alias pour ce nom de module, afin de savoir quel est le module qui sera
effectivement chargé par modprobe. Vous pouvez également trouver ce nom dans la documentation
de la configuration du noyau pour le gestionnaire du périphériques que vous configurez, ou en
regardant directement dans le répertoire d’installation des modules /lib/modules/ ;
• ajouter éventuellement la ligne « options module paramètres » permettant de spécifier les
paramètres de chargement paramètres pour le module module ;
• ajouter éventuellement les lignes « install » et « remove », permettant d’effectuer des actions
complémentaires lors du chargement et du déchargement du module.

Comme il l’a été indiqué dans la la section intitulée Modules du noyau, la détermination des noms de
modules utilisés par le noyau pour les requêtes de chargement automatique n’est pas facile. Vous aurez
sans doute à vous servir du type, du code majeur et du code mineur de ce fichier spécial de périphérique.
Vous pourrez obtenir ces informations à l’aide de la commande ls -l fichier, où fichier est le nom du
fichier spécial de périphérique. Le type de ce fichier est indiqué dans le premier caractère des droits du
fichiers. Le caractère ’c’ indique que le périphérique est un périphérique de type caractère, et le caractère
’b’ indique qu’il s’agit d’un périphérique de type bloc. Les numéros de codes majeur et mineur quant à
eux sont indiqués juste après les informations concernant le propriétaire et le groupe du fichier,
généralement égaux à « root ».
Quoi qu’il en soit, il est fortement recommandé de lire la documentation du module gérant votre
périphérique Plug and Play. Cette documentation est en général située dans le répertoire
/usr/src/linux/Documentation/.

Pour tester si les modifications que vous avez effectuées sont correctes, vous pouvez essayer de charger
le module avec la commande suivante :

modprobe module

où module est le nom du module à charger. Vous pouvez également vérifier que ce module se charge
bien lorsqu’une requête sur le fichier spécial de périphérique correspondant est effectuée, avec par
exemple la commande suivante :

echo Coucou > /dev/périphérique

où périphérique est le fichier spécial de périphérique à tester. Vous pouvez voir si le module s’est
correctement chargé en demandant la liste des modules chargés à l’aide de la commande lsmod. Cette
commande vous indique également l’état de chaque module, ainsi que le nombre de fois qu’il est utilisé
et par qui. Si un module est marqué « uninitialized », vous avez de fortes chances de devoir

241
 Chapitre 8. Configuration du matériel et des périphériques

redémarrer l’ordinateur et de revoir votre configuration, car un module qui se trouve dans cet état est
inutilisable et peut parfois même refuser de se décharger.

Configuration des cartes son

Fonctionnalités du matériel
Les fonctionnalités fournies par les gestionnaires de son de Linux varient dans de larges proportions,
selon le matériel utilisé. La quasi totalité des cartes son gèrent bien entendu l’essentiel : la restitution de
fichiers audio numériques. Les fonctionnalités des cartes son sont à ce niveau relativement disparates :
les différences vont du taux d’échantillonage utilisé jusqu’à la possibilité de les faire fonctionner en full
duplex (enregistrement et lecture simultanée) ou non. Cette dernière fonctionnalité est essentielle pour
les applications de téléphonie sur Internet par exemple.
De plus, très peu de cartes son sont capables de gérer la restitution des fichiers MIDI correctement (les
fichiers MIDI sont des fichiers musicaux permettant de stocker les séquences de notes à jouer pour
restituer le morceau, au lieu de stocker le son lui-même sous forme numérique). La plupart des cartes son
ne fournissent aucun support matériel pour cela, et la restitution des notes des fichiers MIDI se fait
généralement à l’aide d’un synthétiseur logiciel. C’est en particulier le cas pour toutes les cartes son
intégrées sur les cartes mères des ordinateurs récents. Les gestionnaires de périphériques de Linux ne
fournissent pas de synthétiseur logiciel, en revanche il existe plusieurs programmes permettant de lire les
fichiers MIDI, moyennant une consommation plus ou moins importante des ressources de calcul de
l’ordinateur.
La plupart des cartes son bas de gamme disposent toutefois d’un synthétiseur en modulation de
fréquence (synthétiseur dit « FM »), qui permet de simuler des notes d’instrument de musique,
généralement avec une qualité très médiocre. Certains pilotes de cartes son de Linux permettent
d’utiliser ces synthétiseurs, mais ce n’est toujours pas la panacée. En réalité, si l’on veut restituer
correctement les notes des fichiers MIDI, il faut utiliser une carte son disposant de ce que l’on appelle
une table d’échantillons. Ces tables permettent de stocker dans la mémoire de la carte son des
échantillons de sons d’instruments de musique enregistrés en qualité numérique. La carte son peut ainsi
reconstituer le son de toutes les notes de musique fidèlement, avec une très grande ressemblance avec
l’instrument réel. Ces cartes sont bien entendu plus coûteuses, mais la qualité sonore est incomparable à
ce niveau (les cartes SoundBlaster AWE et Live en particulier disposent de tables d’échantillons). Linux
permet parfaitement d’utiliser ces cartes, et même de charger de nouveaux jeux d’échantillons dans la
mémoire de la carte pour changer la sonorité des instruments.
Je ne saurais donc que trop vous conseiller de bien vous renseigner avant l’achat d’une carte son, car ce
sujet n’est pas très souvent pris en considération lors de l’achat. Bien entendu, si vous ne désirez pas
utiliser votre carte son dans ses derniers retranchements, vous pouvez vous contenter des cartes intégrées
sur les cartes mères. Dans les autres cas, renseignez-vous.

Configuration du noyau
La plupart des cartes son vendues actuellement sont des cartes PCI, qui se configurent relativement
aisément. Cependant, il existe encore un bon nombre de cartes son ISA, dont la configuration peut être
plus technique, surtout si elles ne sont pas Plug and Play.

242
 Chapitre 8. Configuration du matériel et des périphériques

La première étape lors de la configuration de votre carte son sera la sélection du gestionnaire de
périphériques à utiliser dans le programme de configuration du noyau. En ce qui concerne les cartes son,
les options de configuration se trouvent dans le menu « Sound ». Vous y trouverez deux jeux de pilotes :
les pilotes ALSA (« Advanced Sound Linux Architecture ») et les pilotes OSS (« Open Sound
System »). Les pilotes ALSA sont les plus modernes, et devront être utilisés en priorité, car ils
fournissent le plus de fonctionnalités. Les pilotes OSS sont des pilotes plus anciens, qui sont toutefois
maintenus à titre de compatibilité d’une part et, d’autre part, parce que certaines cartes son ne sont pas
encore totalement prises en charge par les pilotes ALSA. Les pilotes OSS sont eux-mêmes classés en
deux catégories : les pilotes classiques (première partie des options du menu) et les pilotes OSS purs. Ces
derniers utilisent une spécification d’interface de programmation commune permettant l’accès aux cartes
son, mais il n’y a pas de différence au niveau des applications pour l’utilisation de ces pilotes. Vous
devez choisir le gestionnaire de périphériques ALSA ou OSS qui convient le mieux à votre matériel.
L’erreur la plus classique que l’on peut faire au niveau du choix du pilote est de supposer que l’on
possède une carte compatible Sound Blaster alors que ce n’en est pas une. Je tiens à préciser que
quasiment aucune carte dite « compatible » sous Windows ne l’est sous Linux. La compatibilité sous
Linux, c’est le fait d’avoir quasiment la même électronique ou du moins les mêmes interfaces au niveau
matériel. Sous Windows, la compatibilité n’existe qu’au niveau des interfaces fournies par le pilote de la
carte son. Par conséquent, il vous faut savoir exactement de quel nature est votre carte son, et non ce que
vous avez retenu des arguments commerciaux du fabricant. Notez en particulier que certaines cartes
Sound Blaster ne sont pas compatibles Sound Blaster (Creative Labs est renommé en ce qui concerne les
incompatibilités entre les différents modèles de cartes son). C’est notamment le cas pour les cartes sons
SB64 PCI et SB128 PCI, qui sont en réalité des cartes son ESS1370 ou ESS1371, et dont l’électronique
est fabriquée par la société Ensoniq (cette société a été rachetée par Creative Labs, qui vend ces cartes en
s’appuyant sur son image de marque et qui sème ainsi la confusion sur le marché). En conclusion, si
vous ne voulez pas essayer plusieurs pilotes et recompiler le noyau jusqu’à ce que vous trouviez le bon,
renseignez-vous bien sur la nature de votre carte son (si possible avant de l’acheter, au moins afin de
savoir exactement ce que vous aurez). Vous pouvez également taper la commande lspci afin de voir les
périphériques réellement présents sur le bus PCI. La commande système dmesg peut également vous être
utile. Elle permet de réafficher la liste des messages de traces générés par le noyau, et vous y trouverez
donc les messages relatif à la phase de détection des périphériques.
Lorsque vous aurez choisi le gestionnaire de périphériques adéquat, vous aurez le choix entre le compiler
à l’intérieur du noyau (en choisissant l’option ’Y’) ou le compiler sous forme de module (en choisissant
l’option ’M’). Il est possible soit de charger ces pilotes en tant que module, soit de les intégrer au noyau.
En général, il est préférable d’utiliser les modules, car les programmes de configuration audio peuvent
ainsi détecter automatiquement les cartes son utilisées. De plus, certaines fonctionnalités non essentielles
sont souvent désactivées par défaut par les pilotes, et doivent être activées explicitement à l’aide d’une
option lors du chargement du module ou d’un paramètre à fournir au noyau lors de son amorçage. Les
modules sont donc là aussi plus faciles à utiliser, car ils éviteront de redémarrer le système à chaque
essai. Cependant, pour la plupart des paramètres matériels (en particulier les lignes d’interruptions, les
ports d’entrée/sortie et les canaux d’accès direct à la mémoire), Linux déterminera automatiquement les
valeurs correctes. Cette configuration n’est donc pas à faire, et votre carte son fonctionnera généralement
immédiatement.
Les vielles cartes son ISA qui ne sont pas Plug and Play devront généralement également être intégrées
au noyau. En effet, pour ces cartes sons, la configuration logicielle est très simple, puisqu’on ne peut pas
les configurer du tout, et l’on n’a donc pas besoin de modules du tout. Bien entendu, il faut que vous
ayez résolu manuellement les conflits possibles de matériel de votre ordinateur en fixant les switchs
adéquats sur vos cartes filles, mais cela ne concerne pas Linux. Pour ces cartes, il faut généralement

243
 Chapitre 8. Configuration du matériel et des périphériques

indiquer au noyau les paramètres matériels (IRQ, DMA et ports d’entrée/sortie) lors de la configuration.
Il se peut toutefois que vous ne puissiez pas spécifier ces paramètres matériels dans les menus de
configuration de Linux. Bien qu’en théorie il soit possible de modifier les fichiers sources de Linux
directement pour indiquer ces paramètres, ce n’est pas à la portée du commun des mortels. Par
conséquent, on utilisera malgré tout dans ce cas les modules du noyau, et les options matérielles seront
indiquées dans le fichier de configuration /etc/[Link]. Notez que c’est également de cette
manière que vous devrez procéder si vous désirez configurer vous-même l’allocation des ressources pour
les cartes son ISA Plug and Play, ou, autrement dit, si vous préférez utiliser l’outil isapnp au lieu des
fonctionnalités Plug and Play du noyau.

Configuration des modules du noyau

Si vous compilez les gestionnaires de son sous la forme de modules, vous devrez ajouter les alias et les
options nécessaires à leur chargement dans le fichier /etc/[Link].
Les fichiers spéciaux de périphériques utilisés ne sont pas les mêmes pour les pilotes OSS et les pilotes
ALSA. Les premiers utilisent les fichiers spéciaux /dev/audio?, /dev/dsp? et /dev/mixer?, dont le
numéro de code majeur est 14, alors que les seconds utilisent les fichiers spéciaux de périphériques
/dev/aloadCn et /dev/aloadSEQ, ainsi que tous les fichiers spéciaux de périphérique du répertoire
/dev/snd/, tous de numéro de code majeur 116. Les pilotes ALSA étant également capables de simuler
le comportement des pilotes OSS par compatibilité, ils utilisent le numéro de code majeur 14 également.
Lorsque le noyau désire accéder aux fonctionnalités d’ALSA ou d’OSS, il cherche donc à charger, selon
les fichiers spéciaux de périphériques utilisés, les modules char-major-116 ou char-major-14. Le
premier doit être associé au module snd d’ALSA, alors que le second doit être associé au module
soundcore. Ces modules prennent en charge respectivement les systèmes de son d’ALSA et d’OSS. Le
fichier /etc/[Link] devra donc définir ces alias comme suit :

# Permet le chargement des pilotes ALSA :

alias char-major-116 snd

# Permet le chargement des pilotes OSS ou l’émulation des pilotes OSS par ALSA :
alias char-major-14 soundcore

Les systèmes de son gérés par ces modules permettent de prendre en charge plusieurs cartes son. Chaque
carte son est bien entendu référencée par le numéro de code mineur du fichier spécial de périphérique
utilisé. Il faut donc définir, pour chaque carte son, le module du gestionnaire de périphérique de cette
carte son. Cela se fait en définissant les alias pour les noms de modules génériques snd-card-n pour
ALSA et sound-slot-n pour OSS, où ’n’ est le numéro de la carte son.
Par exemple, si l’on dispose d’une carte son SoundBlaster 128 avec les pilotes ALSA, le module à utiliser
est snd-ens1370 ou snd-ens1371 selon le modèle (parce que ces cartes son sont en réalité des cartes
Ensoniq). Le fichier de configuration /etc/[Link] devra donc contenir les alias suivants :

# La première carte son est gérée par le module snd-ens1371 :

alias snd-card-0 snd-ens1371
alias sound-slot-0 snd-card-0

244
 Chapitre 8. Configuration du matériel et des périphériques

Si vous désirez utiliser les pilotes OSS, le module à utiliser pour ce type de carte se nomme es1371, ce
qui fait que le fichier de configuration /etc/[Link] se réduit dans ce cas à :

# La première carte son est gérée par le module es1371 :

alias sound-slot-0 es1371

Les modules des gestionnaires de périphériques peuvent prendre des options permettant de contrôler les
ressources matérielles et les fonctionnalités prises en charge. Vous pourrez trouver la liste des différents
modules de pilotes de périphériques disponibles, ainsi que leurs options, dans la documentation fournie
dans le répertoire Documentation/sound/ des sources du noyau.
Enfin, les pilotes de périphériques OSS n’implémentent pas forcément l’ensemble des fonctionnalités
classiques des cartes son. Lorsqu’une de ces fonctionnalité est demandée, le pilote peut donc demander
le chargement d’un module complémentaire. Le nom utilisé par le noyau pour ce module est
« sound-service-n-m », où ’n’ est le code majeur du fichier spécial de périphérique de la carte son et
m le code de la fonctionnalité utilisée. Ces codes correspondent aux numéros de codes mineurs des
fichiers spéciaux de périphériques permettant d’accéder à ces fonctionnalités. Ainsi, la valeur 0
correspond au mixeur (fichier spécial de périphérique /dev/mixer), la valeur 2 correspond au port
MIDI (fichier spécial de périphérique /dev/midi), et les codes 3 et 4 au canal de la carte son (fichiers
spéciaux de périphériques /dev/dsp et /dev/audio). La liste des fichiers spéciaux de périphériques
utilisés par OSS peut être consultée dans le fichier Documentation/[Link].
Si vous utilisez les pilotes ALSA, vous devrez ajouter les alias suivants dans le fichier
/etc/[Link] afin de charger à la demande les modules d’émulation des services OSS :

# Charge les modules ALSA des services OSS :

alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

Ajustage des paramètres audio avec ALSA

Ces opérations vous permettront de faire fonctionner votre carte son pour toutes les opérations de base, à
savoir la lecture et l’enregistrement de fichiers son, le réglage du volume sonore et éventuellement la
lecture des CD audio par l’intermédiaire de votre carte son (si, bien entendu, vous avez relié la sortie
audio de votre lecteur de CD à l’entrée auxiliaire de votre carte son).
Le réglage des paramètres de votre carte son peut être réalisé très simplement si vous utilisez les pilotes
ALSA. En effet, il existe une application en mode texte permettant de réaliser ces réglages. Cette
application se lance simplement avec la commande alsamixer
Comme vous pouvez le constater, cette application présente une interface très simple, dans laquelle
chaque canal de la carte son peut être réglé indépendamment. Pour passer d’un canal à l’autre, il suffit
d’utiliser les flèches droite et gauche, et pour régler les volumes, d’utiliser les flèches haut et bas du
clavier. Vous pouvez également rendre un canal complètement muet en appuyant sur la touche ’M’. Cette

245
 Chapitre 8. Configuration du matériel et des périphériques

touche permet également d’activer ou de désactiver certaines fonctionnalités de votre carte son. Lorsque
les réglages vous conviendront, vous pouvez simplement quitter alsamixer en appuyant sur la touche
’Échap’.
Les réglages réalisés de cette manière ne sont pas permanents. Cela signifie que d’un redémarrage à
l’autre de la machine, les valeurs par défaut seront reprises. ALSA fournit donc également l’outil alsactl,
qui permet d’enregistrer les paramètres des cartes son dans le fichier de configuration
/etc/[Link]. Pour cela, il suffit simplement d’appeler cette commande avec l’option store :

alsactl store

alsactl permet également de restaurer les paramètres sauvegardés, à l’aide de son option restore. On
aura donc tout intérêt à placer une ligne telle que celle-ci dans les fichiers d’initialisation de sa
distribution, si ce n’est déjà fait :

alsactl restore

Par ailleurs, pour les cartes son qui disposent d’un synthétiseur FM, il peut être intéressant d’activer cette
fonctionnalité. Généralement, les pilotes ALSA désactivent cette fonctionnalité. Elle peut toutefois être
réactivée en spécifiant le port d’entrée / sortie du synthétiseur FM de la carte son à l’aide de l’option
fm_port. du module prenant en charge votre carte son. De même, vous pourrez activer la gestion des
pilotes MIDI en ajoutant l’option mpu_port et en indiquant le numéro de port pour le port MIDI. Vous
pouvez consulter le fichier de documentation
Documentation/sound/alsa/[Link] des sources du noyau Linux pour plus
d’informations à ce sujet. En général, le numéro de port utilisé pour les synthétiseurs FM est le numéro
0x388, et le numéro du port MIDI est le 0x300. Par exemple, pour une carte son CMI, la ligne suivante
pourra être ajoutée dans le ficher de configuration [Link] :

options snd-cmipci fm_port=0x388 mpu_port=0x300

Si vous désirez compiler en dur le pilote de votre carte son, vous devrez fournir ces informations en ligne
de commande à l’amorçage du noyau. Vous devez donc ajouter, pour chacun de ces paramètres, une
option à la ligne de commande du noyau. Par exemple, pour une carte son CMI, il faudrait ajouter les
options suivantes dans le fichier de configuration du GRUB ou dans le fichier [Link] :

[Link]=0 snd-cmipci.fm_port=0x388 snd-cmipci.mpu_port=0x300

La première option permet d’indiquer que cette carte son est la première carte son du système. Elle peut
être nécessaire si vous avez intégré dans le noyau des pilotes pour d’autres cartes son, réelles ou
virtuelles. Les autres options sont directement déduites de celles spécifiées dans le fichier
[Link].

Enfin, vous aurez sans doute à charger une banque de sons dans le pilote, que vous utilisiez une synthèse
FM ou une table d’échantillons. La manière de procéder est toutefois différente selon la carte son
utilisée. Pour les cartes sons qui ne disposent que d’une émulation FM, il faut utiliser le programme
sbiload. Ce programme est fourni avec les outils complémentaires d’ALSA, et disponible sur le site web

246
 Chapitre 8. Configuration du matériel et des périphériques

du projet ALSA ([Link] Ce programme permet de charger dans le pilote les

définitions des notes en modulation de fréquence. La syntaxe est la suivante :

sbiload -p65:0 --opl3 std.o3 drums.o3

Cette commande permet de charger dans le périphérique MIDI ALSA 65:0 les fichiers de définition de
notes std.o3 et drums.o3. Ces fichiers sont fournis avec sbiload (pas dans toutes les versions
toutefois). L’option --opl3 permet d’indiquer le format de ces fichiers. Quant à l’option -p, elle permet
d’indiquer le port MIDI dans le pilote ALSA. Les numéros de ports disponibles peuvent être obtenus
avec la commande suivante :

sbiload -l

Note : La commande sbiload ne fonctionne qu’avec les ports MIDI FM.

Si le périphérique MIDI FM ne s’affiche pas, c’est que soit votre carte son n’en dispose pas, soit il n’a
pas été activé dans le pilote et qu’il faut fournir l’option fm_port au module ou au noyau lors de son
démarrage, soit que le module snd-synth-opl3 n’a pas été chargé.

Pour les cartes son qui disposent d’une table d’échantillons, le programme à utiliser est différent. Pour
les cartes Sound Blaster AWE et Sound Blaster Live, ce programme se nomme sfxload. Ce programme
peut être trouvé sur le site [Link] Vous trouverez également les
fichiers de patches utilisables avec les cartes son AWE sur ce site. Vous pouvez utiliser le fichier de
définition des patches de Creative, que vous trouverez normalement soit sur une installation de Windows
avec une carte son AWE, soit sur vos CD d’installation, soit sur Internet. Le fichier fourni par Creative se
nomme [Link].
Pour charger les patches dans la mémoire de la carte, il suffit d’utiliser la commande suivante :

sfxload /usr/lib/[Link]

(en supposant que le fichier de patches soit placé dans le répertoire /usr/lib/). Vous pourrez placer
cette commande dans les scripts de démarrage de votre système ou dans une option de chargement du
module de prise en charge de votre carte son.

Fichiers MIDI et synthétiseurs logiciels

Comme indiqué en introduction, la plupart des cartes son ne permettent pas de lire les fichiers MIDI au
niveau matériel. Les fichiers MIDI sont des fichiers ne contenant que les « partitions » des morceaux
enregistrés. Ils ne contiennent pas les données audio numériques comme c’est le cas pour les fichiers son
classiques ou les pistes de CD audio. Cela explique leur taille réduite, mais pose un problème pour leur
restitution. En effet, la lecture d’un fichier MIDI suppose que votre carte son dispose d’un jeu de sons
numérisés dans sa mémoire afin de pouvoir reconstituer le signal sonore à partir des informations du
fichier MIDI. Ces sons sont couramment appelés des « échantillons » (« patches » en Anglais), et ils
peuvent être enregistrés soit en dur dans la mémoire de la carte son, soit chargés lors de son initialisation.
Il va de soi que certaines cartes son ne disposent pas des fonctionnalités nécessaires à la lecture des

247
 Chapitre 8. Configuration du matériel et des périphériques

fichiers MIDI. Dans ce cas, il faut utiliser un programme externe capable de synthétiser le son à partir
d’échantillons enregistrés sur le disque dur et d’envoyer les données audio ainsi créées à la carte son pour
la lecture.
Pour les cartes son ne disposant pas de la possibilité de lire les fichiers MIDI, il ne reste que la solution
de l’émulation logicielle. Le meilleur synthétiseur logiciel sous Linux est incontestablement le logiciel
Timidity. Timidity est un programme de lecture de fichiers MIDI très complet, paramétrable et capable
d’utiliser des banques de sons externes variées. De plus, le moteur de Timidity est utilisé par de
nombreux autres programmes, en particulier par le lecteur KMidi de KDE.
L’auteur originel de Timidity ne le maintient plus. Cependant, d’autres programmeurs ont pris le relais et
l’ont amélioré pour en faire la version Timidity++. Cette dernière version peut être trouvée sur Internet
sur le site de Timidity ([Link] L’archive que vous récupérerez ne contient pas
forcément le programme : il peut ne s’agir que des fichiers sources permettant de le générer. Les notions
de fichiers sources et de compilation de programmes exécutables seront expliquées en détail dans le
chapitre suivant. En attendant, si vous récupérez les sources, vous pourrez suivre les indications données
ci-dessous pour compiler et installer Timidity.
Timidity peut utiliser différentes interfaces utilisateur, accessibles via différentes bibliothèques. De plus,
il est capable d’utiliser différentes interfaces pour lire et jouer les morceaux. En particulier, il peut être
utilisé comme un serveur MIDI via ALSA afin que tous les programmes MIDI puissent y accéder via les
interfaces standard d’ALSA. De même, il est capable de partager le canal audio de sortie de la carte son
via le serveur de son aRts de KDE. Pour utiliser ces fonctionnalités, il faut configurer les sources avec la
ligne de commande suivante :

./configure --prefix=/usr --enable-dynamic --enable-server \

--enable-interface=gtk,ncurse --enable-audio=arts,alsa,oss --enable-alsaseq

Une fois cela fait, vous pourrez générer l’exécutable avec la commande suivante :

make

et l’installer avec la commande :

make install

Cela installera Timidity dans le répertoire /usr/bin/.

La deuxième étape est bien entendu d’installer les fichiers de patches. Timidity utilise des patches pour
les cartes son Gravis Ultrasound. Vous pourrez trouver des archives contenant de tels patches sur Internet
très facilement. En particulier, la collection de patches EAWPATS
([Link] réalisée par Eric A. Welsh est très complète.
Cette collection a de plus l’avantage d’être préconfigurée pour l’emploi avec Timidity.
Lorsque vous aurez installé les fichiers de patches, vous devrez indiquer à Timidity leur emplacement
dans le système de fichiers. Cette information doit être stockée dans le fichier de configuration
[Link] du répertoire /usr/share/timidity/. Vous pourrez vous inspirer du fichier fourni
avec la collection de patches EAWPATS. Cependant, vous aurez à modifier les chemins indiqués dans ce
fichier, car il a été écrit pour la version Windows de Timidity. Le premier répertoire à indiquer est celui
des bibliothèques. Il faut ici simplement remplacer la ligne « dir c:\timidity » par la ligne « dir

248
 Chapitre 8. Configuration du matériel et des périphériques

/usr/lib/timidity ». Notez que cette ligne est facultative et peut être commentée si vous n’avez pas
déplacé ce répertoire. Le deuxième répertoire est plus important, puisque c’est le répertoire d’installation
des patches. Il s’agit cette fois de remplacer la ligne « dir c:\eawpats » par la ligne « dir
répertoire », où répertoire est le répertoire où vous avez extrait les fichiers patches.

Une fois que vous aurez terminé ces modifications, vous pourrez lire un fichier MIDI simplement en
utilisant la ligne de commande suivante :

timidity fichier

où fichier est le nom du fichier MIDI à lire. Si vous désirez utiliser l’interface graphique de Timidity,
vous n’avez qu’à ajouter l’option -ig à la ligne de commande précédente. Enfin, si vous désirez utiliser
Timidity en tant que séquenceur système ALSA et permettre le mixage du flux audio qu’il produit avec
les flux des autres applications par l’intermédiaire du serveur de son aRts de l’environnement de
développement de KDE, vous devrez utiliser les options -iA -OR -B2,8 -EFreverb=0. Les
programmes MIDI devront ensuite se connecter sur le port MIDI 128:0 d’ALSA.
L’installation de KMidi ne pose pas de problème particulier, puisqu’il est fourni avec KDE et que KDE
est normalement inclus dans toute bonne distribution. La seule opération que vous ayez à faire est
simplement de modifier le fichier de configuration de KMidi pour lui indiquer l’emplacement des fichiers
de patches. Or comme KMidi est basé sur les sources de Timidity, il utilise le même fichier de
configuration [Link] que Timidity. Ce fichier est normalement situé dans le répertoire
/base/kde/share/apps/kmidi/config/, où base représente le répertoire de base d’installation de
KDE. Vous n’aurez donc qu’à répéter les opérations faites sur le fichier de configuration de Timidity
avec le fichier de configuration de KMidi.

Installation d’une carte graphique 3D

De nos jours, toutes les cartes graphiques disposent d’une accélération matérielle non seulement pour les
opérations graphiques en 2D, mais également pour le calcul de scènes en 3D. Ce développement des
cartes 3D a été principalement poussé pour les jeux, mais ces fonctionnalités sont également très utiles
pour les applications de modélisation et de conception.
La manière dont les opérations graphiques en 3D sont réalisées dépend évidemment du modèle de carte
graphique utilisée, car il n’existe pas de standard au niveau matériel. Comme il est impensable que les
applications qui désirent utiliser les fonctionnalités 3D des ordinateurs modernes aient à prendre en
compte le type de carte utilisée, des interface logicielles standards ont été définies.
De toutes ces interfaces, Linux n’en gère qu’une seule : OpenGL. Cette interface a été définie par Silicon
Graphics pour ses stations de travail haut-de-gamme et s’est imposée comme étant la norme en la matière
pour ce qui est de la 3D. Cette interface a l’avantage d’être ouverte et disponible sur la plupart des
systèmes, qu’ils soient de type Unix ou non.
La prise en charge de l’interface OpenGL est réalisée à deux niveaux sous Linux. La partie principale
réside dans le serveur X qui, comme nous l’avons déjà signalé, n’est rien d’autre que le programme
fournissant les services graphiques aux autres applications sous Unix. Cette partie est implémentée par
une extension de l’interface de programmation XWindow, que l’on nomme tout simplement GLX.
Cependant, le serveur X ne peut pas tout faire à lui tout seul car, pour des raisons de performances, il lui
faut accéder directement au matériel lors du rendu de scènes 3D. Il s’appuie donc pour cela sur un

249
 Chapitre 8. Configuration du matériel et des périphériques

module du noyau, dont le but est de contrôler les accès au ressources matérielles et de garantir ainsi la
stabilité globale du système.
La configuration des fonctionnalités 3D des cartes graphiques sous Linux nécessite donc d’intervenir à la
fois dans le noyau et au niveau du serveur X. Pour ce qui est du noyau, il faut tout d’abord s’assurer que
les fonctionnalités d’accès direct au matériel sont bien supportées. Ces fonctionnalités sont couramment
appelées « DRI », ce qui est l’abréviation de l’anglais « Direct Rendering Infrastructure ». Pour activer
les fonctionnalités DRI, vous devrez, dans la configuration du noyau, valider l’option « Direct Rendering
Manager » du menu « Character devices », ainsi que le type de carte graphique utilisée (3Dfx, 3dlabs,
ATI Rage 128 ou ATI Radeon, chipset i810 ou Matrox G200/G400).

Note : Les fonctionnalités 3D des cartes graphiques basées sur les puces NVidia ne sont pas
supportées directement par [Link] et par le noyau. En revanche, NVidia fournit un pilote pour Linux
pour ces cartes, qui, bien qu’il n’utilise pas DRI, dispose également d’un module du noyau et d’un
module pour [Link].

Quelle que soit votre carte graphique, vous aurez également sans doute intérêt à activer le support du bus
AGP dans le noyau, si bien sûr votre carte graphique est une carte AGP. Pour cela, il suffit d’activer
l’option « /dev/agpgart (AGP support) » dans le menu « Character devices » de la configuration du
noyau, ainsi que le type de chipset utilisé par votre carte mère.
Une fois la configuration du noyau faite, vous pourrez le recompiler et l’installer. La manière de procéder
a été décrite en détail dans la la section intitulée Compilation du noyau Linux dans Chapitre 7.
Vous devrez également vous assurer que le fichier spécial de périphérique /dev/agpgart est bien
présent dans le répertoire /dev/. Son code majeur est 10, et son code mineur est 175. De même, si vous
avez compilé les options précédentes sous la forme de modules du noyau, assurez-vous qu’ils sont bien
référencés dans le fichier [Link].
La suite des opérations se passe alors au niveau de la configuration du serveur X de [Link]. L’activation
du support de l’AGP et d’OpenGL se fait simplement en rajoutant deux options dans le fichier de
configuration /etc/X11/[Link]. Vous devez trouver la section « Modules » et lui ajouter les deux
lignes suivantes :

Section "Module"
.
.
.
Load "dri"
Load "glx"
.
.
.
EndSection

Vous trouverez de plus amples renseignements sur la manière de procéder dans le Chapitre 10.

Note : Pour le pilote fourni par NVidia pour [Link], il n’est pas nécessaire de demander le
chargement du module DRI, car il ne l’utilise pas.
Il est supposé ici que le serveur X utilisé correspond bien à la carte graphique et dispose des
fonctionnalités 3D. Si ce n’est pas le cas, vous devrez sans doute réinstaller [Link].
Les programmes utilisant OpenGL utilisent souvent une bibliothèque complémentaire nommée
GLUT. Cette bibliothèque est fournie avec la couche d’émulation logicielle d’OpenGL MESA.

250
 Chapitre 8. Configuration du matériel et des périphériques

Toutefois, la bibliothèque GLUT n’est disponible que dans les programmes d’exemples de MESA.
Vous devrez donc réinstaller MESA complètement si votre distribution ne fournit pas la bibliothèque
GLUT.

Installation d’une carte d’acquisition vidéo

Linux fournit toutes les fonctionnalités nécessaires à la manipulation des flux de données vidéo par
l’intermédiaire d’une interface de programmation nommée video4linux (ce qui se lit « Video for
Linux »). Linux est capable de gérer la plupart des cartes d’acquisition TV du marché et quelques-unes
des cartes d’acquisition vidéo. Comme d’habitude, seuls les constructeurs de matériel qui ont accepté de
jouer le jeu de fournir les informations nécessaires à la programmation de gestionnaires de périphériques
libres voient leur matériel supporté sous Linux. Par conséquent, il est encore une fois nécessaire de bien
se renseigner sur la nature du produit et la politique du fabricant lorsqu’on achète une carte d’acquisition
TV.
En pratique, quasiment toutes les cartes d’acquisition TV utilisent les circuits intégrés Bt848 ou un de
leurs dérivés, et Linux sait les gérer sans problèmes. Les cartes d’acquisition et de montage vidéo
utilisent d’autres circuits plus puissants, dont les spécifications ne sont généralement pas disponibles.
Seule la configuration des cartes TV sera donc décrite ci-dessous.
Les applications, pour accéder aux périphériques vidéo, utilisent l’un des fichiers spéciaux de
périphérique /dev/video*. Ces fichiers sont des fichiers de type caractère, dont le code majeur vaut 81.
Le code mineur est utilisé pour différencier les différents périphériques installés sur votre système. En
général, il existe un lien symbolique /dev/video sur l’un de ces fichiers spéciaux, qui sera utilisé pour
accéder au périphérique vidéo par défaut. Normalement, tous ces fichiers sont installés d’office dans le
répertoire /dev/ soit par les distributions, soit par udev au démarrage du système, et vous n’aurez donc
généralement pas à les créer vous-même.
Le support de la vidéo sous Linux passe bien entendu par la configuration du noyau. Cette fois, il n’est
pas certain du tout que le noyau fourni avec votre distribution supporte les cartes d’acquisition TV, aussi
aurez-vous peut-être à recompiler vous-même votre noyau. La manière de procéder a été décrite en détail
dans la la section intitulée Compilation du noyau Linux dans Chapitre 7.
Sachez toutefois que les options à valider dans la configuration du noyau se trouvent dans le menu
« Multimedia devices ». Vous devrez activer l’option « Video For Linux ». Si vous compilez cette
fonctionnalité sous la forme de module, celui-ci sera nommé videodev. Ce pilote se chargera de
répondre aux requêtes du client sur les fichiers spéciaux de périphérique /dev/video*. Lorsque vous
aurez activé la fonctionnalité de vidéo pour Linux, vous aurez le choix des pilotes de cartes vidéo dans le
sous-menu « Video adapters ». Il est recommandé de compiler ces gestionnaires de périphériques sous la
forme de modules, car il vous faudra sans doute spécifier des options afin d’adapter ces gestionnaires à
votre matériel.

Note : La configuration des cartes basées sur la puce Bt848 (option de menu « BT848 Video For
Linux ») n’est accessible que si vous avez également activé l’option « I2C bit-banging interfaces » du
menu « I2C support » (lui-même situé dans le menu « Character devices »).
De plus, le pilote prenant en charge les puces du type Bt848 ne prend pas en charge la gestion du
son. Ces puces n’intègrent en effet pas de gestion du son, et nécessitent de brancher la sortie audio
de la carte TV sur l’entrée ligne d’une carte son. Toutefois, un mixeur est disponible. Celui-ci est pris

251
 Chapitre 8. Configuration du matériel et des périphériques

en charge automatiquement pour les pilotes de son ALSA. Pour les pilotes OSS en revanche, un
gestionnaire spécifique devra être activé. L’option correspondante est l’option « TV card (bt848)
mixer support ». Pour les puces Bt878, qui sont plus récentes, une carte son intégrée est fournie, et
il existe un pilote complet ALSA et OSS, que l’on devra également activer.

Une fois le noyau recompilé et installé, il faut modifier trouver les paramètres adaptés à votre matériel.
En effet, bien que Linux soit parfaitement capable de déterminer les ressources requises par les cartes
vidéo, il est rare que le matériel soit correctement identifié par les gestionnaires de périphériques. Cela
est dû au fait que les gestionnaires se basent plus sur les composants courants permettant de faire
l’acquisition vidéo que sur les modèles de cartes de chaque fabricant. La palme revient sans doute au
gestionnaire pour les cartes basées sur les puces Bt848 et ses dérivées, puisqu’il est capable de faire
fonctionner toutes les cartes vidéo de tous les fabricants qui utilisent cette puce. Par conséquent, il faut
indiquer le modèle de la carte au gestionnaire, et bien souvent le modèle de tuner doit également être
spécifié.
Si vous avez compilé les gestionnaires de périphériques sous forme de module, vous pourrez spécifier le
type de carte et le type de tuner simplement dans le fichier de configuration /etc/[Link], à
l’aide des options du module du gestionnaire de périphérique adéquat. Pour les cartes basées sur la puce
Bt848, le gestionnaire de périphérique est pris en charge par le module bttv. Le type de carte peut lui
être communiqué à l’aide de l’option card. Cette option peut prendre comme valeur un numéro
identifiant le modèle de la carte. Les valeurs actuellement supportées sont indiquées dans le fichier
[Link] du répertoire /usr/src/linux/Documentation/video4linux/bttv/. Le type
de tuner quant à lui doit être spécifié à l’aide de l’option tuner. Cette option prend, elle aussi, une valeur
numérique indiquant la nature du tuner utilisé. Les valeurs supportées sont données dans le fichier
[Link]. En pratique, il est fort probable que vous utilisiez le type de tuner 3, qui correspond
au tuner Philips SECAM, car la France utilise le standard SECAM pour les émissions TV.
Ainsi, si vous disposez d’une carte MIRO PCTV (carte de type 1) basée sur le tuner Philips SECAM,
vous devriez avoir les lignes suivantes dans votre fichier [Link] :

# Nom du module de gestion de Video For Linux :

alias char-major-81 videodev

# Nom du module à utiliser pour le premier périphérique vidéo :

alias char-major-81-0 bttv

# Options du module de gestion du Bt848 :

options bttv card=1 tuner=3

Vous devrez bien entendu adapter ces lignes selon votre propre configuration.
Si vous ne désirez pas utiliser les modules du noyau, vous devrez fournir ces paramètres au gestionnaire
de périphérique via la ligne de commande du noyau. Les options à utiliser peuvent alors être déduites des
options du module, comme on l’a expliqué dans la la section intitulée Configuration des périphériques
intégrés au noyau. Pour notre exemple, ces paramètres seraient les suivants :

[Link]=1 [Link]=3

252
 Chapitre 8. Configuration du matériel et des périphériques

Si vous avez compilé les fonctionnalités de l’interface I2C sous forme de module (option de menu « I2C
bit-banging interfaces »), vous aurez également à ajouter ces lignes dans votre fichier de configuration
[Link] :

# Nom du module de gestion des fonctionnalités I2C :

alias char-major-89 i2c-dev

# Activation de l’agorithme bit-banging :

options i2c-algo-bit bit_test=1

Pour information, I2C est un protocole de communication entre micro-contrôleurs, que la plupart des
cartes mères sont capables de gérer. Cette fonctionnalité n’est nécessaire que pour les cartes basées sur la
puce Bt848.
Enfin, si vous utilisez les pilotes OSS pour la gestion du mixer de votre carte d’acquisition vidéo (ce qui
est nécessaire pour les cartes vidéo basées sur les puces Bt848, parce qu’ALSA ne fournit pas de pilote
pour ces cartes à l’heure actuelle), vous devrez définir les alias nécessaires au chargement des modules
de cette carte lors de l’accès aux périphériques audio. Par exemple, pour une carte basée sur la puce
Bt848, les alias suivants doivent être ajoutés dans le fichier de configuration [Link] :

# Charge le pilote de la carte vidéo en tant que deuxième carte son :

alias sound-slot-1 bttv

# Charge le mixer de la carte son de cette carte :

alias sound-service-1-0 tvmixer

Note : Vous pouvez rencontrer quelques problèmes lors de la configuration de votre carte TV.
Généralement, si vous n’obtenez aucune image, c’est que vous vous êtes trompé de tuner. Revoyez
dans ce cas l’option type du module tuner. Si vous obtenez bien une image, mais pas de son, c’est
sans doute que vous vous êtes trompé dans le type de carte, ou que vous avez oublié d’inclure le
support du son pour les cartes à base de Bt848. On notera que, comme pour les cartes son, seule la
compatibilité matérielle importe. Par exemple, les cartes Studio PCTV de Pinacle vendues en France
sont en réalité des cartes Miro PCTV et ne sont pas reconnues comme des cartes Studio PCTV par
Linux... Si vous avez des problèmes de son, vous devrez donc revoir la configuration du noyau ou
modifier la valeur passée à l’option card du module bttv. Dans tous les cas, n’hésitez pas à utiliser la
commande lspci, qui permet de visualiser les informations du bus PCI, et la commande dmesg, qui
permet de voir la liste des messages du noyau.
Vous pouvez également avoir quelques problèmes de droits sur les fichiers spéciaux de
périphériques /dev/videoX. Le symptôme classique est dans ce cas que tout fonctionne
parfaitement sous le compte root, mais pas sous les comptes utilisateurs. Dans ce cas, on pourra
résoudre ces problèmes en créant un groupe d’utilisateurs video, auquel appartiendront tous les
utilisateurs ayant le droit d’utiliser la carte d’acquisition TV, et de changer le groupe des fichiers
spéciaux de périphériques /dev/videoX.
Enfin, l’utilisation des cartes d’acquisition TV nécessite d’activer les fonctionnalités DGA ou Xv du
serveur X. Ces fonctionnalités permettent aux programmes d’accéder directement à la mémoire
vidéo, et donc de faire l’incrustation de l’image décodée par la carte TV dans la surface d’affichage
d’un écran. La manière d’activer les fonctionnalités DGA et Xv sera précisée dans le chapitre traitant
de la configuration du serveur X.

253
 Chapitre 8. Configuration du matériel et des périphériques

Configuration des cartes réseau

Le support des cartes réseau est très complet sous Linux et la prise en charge d’une nouvelle carte revient
souvent simplement à ajouter le gestionnaire de périphériques de cette carte dans la configuration du
noyau. La plupart des cartes réseau sont des cartes Ethernet compatibles soit avec les cartes NE2000, soit
avec les cartes 3COM, aussi suffit-il en général d’activer le gestionnaire de périphériques pour l’une de
ces cartes pour qu’elle soit utilisable.
La configuration des gestionnaires de périphériques se fait dans le menu « Networking support » de la
configuration du noyau. Il faut activer l’option « Network device support » en premier lieu, puis
sélectionner le gestionnaire de périphériques approprié dans le sous-menu « Ethernet (10 or 100Mbit) ».
Ce menu présente en premier lieu les gestionnaires de périphériques pour les cartes ISA, et regroupe les
gestionnaires de toutes les autres cartes dans les sous-options de l’option « EISA, VLB, PCI and on
board controllers ». Vous aurez donc certainement à activer cette option et la sous-option
correspondante au gestionnaire de périphériques de votre carte réseau. Vous pouvez activer ces options
sous la forme de module du noyau ou non, le plus simple étant ici de ne pas utiliser les modules afin
d’avoir à éviter de compléter le fichier de configuration /etc/[Link].
La compilation du noyau elle-même est décrite en détail dans la la section intitulée Compilation du
noyau Linux dans Chapitre 7 et ne sera donc pas reprise plus en détail ici. Remarquez également que la
prise en charge de la carte réseau par un gestionnaire de périphériques ne suffit en aucun cas à
l’utilisation de l’ordinateur en réseau. En effet, il faut également configurer l’ensemble des paramètres
réseau du système, ce qui sera décrit dans le Chapitre 9. Le nombre des fonctionnalités réseau de Linux
interdit de les décrire toutes ici, veuillez vous référer à ce chapitre pour plus de détails.

Configuration des adaptateurs Wifi

Le Wifi (abréviation de l’anglais « Wireless Fidelity » est une technologie permettant de mettre plusieurs
ordinateurs en réseau par ondes radio. La plage de fréquences utilisée est située dans la gamme des
micro-ondes (2.44GHz) et est soumise à une réglementation stricte dans de nombreux pays, car elle est
en partie réservée aux applications militaires. En pratique, seuls certains canaux sont donc utilisables, et
des dérogations peuvent être nécessaires pour une utilisation en extérieur. De plus, cette plage de
fréquences est la même que celle utilisée par de nombreux autres appareils sans fil, comme les
téléphones portables. Les communications sont donc fortement perturbables par ces appareils, ainsi bien
sûr que par les fours à micro-ondes. Enfin, du fait même que ce sont des ondes radio, la confidentialité et
la sécurité des communications peuvent être compromises.

Note : Comme pour toute onde proche des 2.4 GHz, l’influence des ondes radio Wifi sur les corps
organiques humides n’est pas neutre (la problématique se pose bien entendu également pour les
téléphones portables). En effet, les effets sont strictement les mêmes que ceux des ondes des fours
à micro-ondes : ces ondes sont à la fréquence propre des molécules d’eau, qui entrent donc en
résonnance en leur présence (cette interaction est due à la polarité de la molécule H2O, elle même
due à son asymétrie - les atomes d’hydrogène et d’oxygène ne sont pas en ligne - et à la différence
d’eléctronégativité entre les atomes d’hydrogène et d’oxygène qui la constituent). Les molécules
d’eau restituent ensuite l’énergie de l’onde par diffusion de leur agitation moléculaire dans les

254
 Chapitre 8. Configuration du matériel et des périphériques

molécules avoisinantes, ce qui provoque une augmentation de température. On est donc en droit de
se poser la question du danger de l’utilisation de ces ondes pour l’organisme. En général, les
puissances émises restent très faibles, et leur influence décroit de manière inversement
proporionnelle au carré de la distance à l’émetteur, ce qui fait que le danger est relativement réduit.
Toutefois, à titre personnel, et sans prétendre avoir fait la moindre étude sur le sujet, je vous invite à
la prudence lors de l’utilisation d’ordinateurs ou de téléphones portables, en raison même de leur
proximité (note : je n’ai pas de téléphone portable). Notez également que la chaleur directe dégagée
par ces appareils par effet Joule ne doit pas non plus être oubliée et est certainement encore plus
dangereuse.

Plusieurs normes de transmission ont été définies pour spécifier les interactions entre les appareils Wifi,
ainsi que les technologies de chiffrement utilisées. La norme la plus répandue est la norme 802.11b, qui
permet d’atteindre un débit de 11 Mbits/s théorique sur des distances allant jusqu’à 300 mètres en
extérieur (quelques dizaines de mètres en intérieur). Cette norme définit un mécanisme de sécurité
primitif, qui peut être considéré comme absolument inefficace de nos jours. Il est probable que le
remplaçant de cette norme soit la norme 802.11g, car elle permet une compatibilité ascendante avec les
équipements 802.11b (elle utilise la même plage de fréquences). Il s’agit d’une amélioration conséquente
du 802.11b, puisque le débit théorique est relevé à 54 Mbits/s (30 Mbits/s rééls). Une autre norme
concurrente du 802.11g a été définie, mais elle semble ne pas avoir autant d’avenir. Il s’agit de la norme
802.11a, qui utilise une plage de fréquence à 5 GHz. Les problèmes d’interférences sont donc moindres,
mais la portée est également réduite (plus la fréquence d’une onde radio est élevée, plus sa portée est
réduite et plus elle est susceptible d’être bloquée par des objets). Enfin, la norme 802.11i, encore peu
répandue, a pour but d’améliorer la sécurité des communication en utilisant un véritable procédé
cryptographique. Cette norme pourra être transposée pour les appareils 802.11g et 802.11a. Comme vous
pouvez le constater, le terme Wifi cache bien des choses complexes, et le choix d’une technologie sur une
autre peut être assez difficile.
Malgré tous ces inconvénients, la technologie Wifi est très pratique, car elle permet de connecter
simplement des machines sans s’emmêler les pattes dans les câbles réseau. La plupart des ordinateurs
portables vendus disposent maintenant d’un adaptateur réseau sans fil Wifi, et il est très facile d’en
connecter un à un ordinateur de bureau, soit avec une carte fille, soit grâce à un adaptateur USB (il existe
même des clefs USB dont l’encombrement est réduit à celui d’un stylo). Il est donc certain que ces
technologies sont appelées à se développer et à se généraliser.
Certains matériels Wifi ne sont pas supportés nativement par Linux, soit parce que les constructeurs ne
désirent pas fournir les informations permettant aux développeurs de faire un gestionnaire de
périphérique libre, soit parce que les constructeurs n’ont eux-mêmes pas le droit de divulguer la
technologie utilisée dans leurs appareils ou parce que les réglementation locales sur les émissions radio
leur impose de tenir secret les caractéristiques de leurs appareils. Le choix d’un périphérique Wifi doit
donc se faire avec précaution. Vous pourrez consulter le site Web
([Link] de Jean Tourrilhes pour savoir le matériel
supporté par les différents pilotes disponibles.
La prise en charge des périphériques Wifi nécessite d’activer le support du Wifi dans le noyau lui-même.
Cela peut être fait en activant l’option « Wireless LAN drivers (non-hamradio) & Wireless
Extensions » du menu « Networking support » du noyau. Cette option vous donnera également accès
aux options de configuration de quelques pilotes de périphériques Wifi. Il est probable cependant que
vous devrez chercher sur Internet le pilote correspondant à votre matériel. Plusieurs projets ont en effet
été créés afin de prendre en charge le Wifi sous Linux. Dans le cas des portables estampillés « Centrino »,

255
 Chapitre 8. Configuration du matériel et des périphériques

Intel a lancé lui-même (sous la demande pressante des utilisateurs) les projets pour ses propres puces.
Voyez le site [Link] pour plus de détails à ce sujet. Vous trouverez également sur
le site de Jean Tourrilhes des liens vers les projets des pilotes pour les autres puces Wifi.
Si aucun pilote Linux n’est disponible pour votre matériel, vous pourrez vous rabattre sur le projet
NDISWrapper ([Link] Ce projet a pour but de simuler la couche réseau
NDIS de Windows XP afin de pouvoir charger les gestionnaires de périphériques pour Windows fournis
par les fabricants, et les duper en leur faisant croire qu’ils s’exécutent bien sous Windows. Cette
technique reste toutefois une magouille et ne résout bien entendu pas le problème de la disponibilité de
pilotes libres.
L’installation des pilotes ne sera pas détaillée plus ici, car la manière de procéder est spécifique à chaque
matériel. Dans le cas de NDISWrapper, l’installation se fait simplement en installant NDISWrapper
lui-même et en exécutant la commande suivante :

ndiswrapper -i [Link]

où [Link] est le fichier .inf du gestionnaire de périphérique pour Windows de votre matériel.
Cette commande copie les fichiers nécessaires de ce gestionnaire de périphérique dans le répertoire
/etc/ndiswrapper/ et définit la configuration pour l’utilisation de ce périphérique. Une fois cela fait,
le chargement du module ndiswrapper suffit pour charger le gestionnaire de périphérique :

modprobe ndiswrapper

Pour les autres gestionnaires de périphériques, il suffit généralement également de charger le module du
noyau du pilote, et éventuellement de charger un firmware.
Lorsque le pilote est chargé, une nouvelle interface réseau « wlanX » apparaît dans le système, où X est
le numéro de l’interface réseau sans fil. Cette interface peut ensuite être utilisée comme n’importe quelle
interface réseau, à ceci près qu’il faut au préalable configurer les paramètres du réseau sans fil. En
particulier, il est nécessaire de spécifier le mode de fonctionnement, le canal à utiliser et l’identifiant du
réseau sans fil. Une clef de chiffrement des communications peut également être donnée (cela ne garantit
toutefois pas une sécurité absolue, sauf en 802.11i).
Les réseaux Wifi peuvent être établis de plusieurs manières. S’il s’agit de relier deux machines par Wifi,
le mode de fonctionnement utilisé le plus simple est le mode « ad hoc ». Dans ce mode, les deux
machines peuvent communiquer directement, sans avoir recours à une infrastructure quelconque.
Inversement, si plusieurs machines doivent être reliées à un réseau existant (ou simplement entre elles), il
est nécessaire d’installer ce qu’on appelle un « point d’accès », qui synchronisera les communications
entre toutes ces machines. Dans ce cas, le mode de fonctionnement utilisé est le mode « managé ».
Le canal permet de spécifier la fréquence utilisée par les périphériques sans fil. Bien entendu, toutes les
machines devant participer à la communication doivent utiliser le même canal. Le canal est donc un des
paramètres essentiel du réseau. Il existe plusieurs canaux, mais en pratique, seuls quelques-uns peuvent
être utilisés librement en France. Il s’agit des canaux 10 (2457 MHz), 11 (2462 MHz), 12 (2467 MHz) et
13 (2472 MHz).
Comme on peut être amené à créer plusieurs réseaux Wifi utilisant un même canal, il est nécessaire de
pouvoir les distinguer afin d’éviter de mélanger les transmissions. Deux possibilités s’offrent alors à
l’utilisateur : soit on utilise ce qu’on appelle un numéro de réseau virtuel (« Network ID »), soit on utilise
un nom de réseau. La première solution ne permet de définir qu’une cellule du réseau, alors que la

256
 Chapitre 8. Configuration du matériel et des périphériques

deuxième permet de regrouper plusieurs de ces cellules et autorise un utilisateur à passer d’une de ces
cellules à l’autre (une cellule est une zone géographique prise en charge par un point d’accès).
Tous ces paramètres peuvent être spécifiés avec la commande iwconfig, sauf pour certains pilotes de
périphériques non standards qui nécessitent des commandes spécifiques. La syntaxe générale de cette
commande est la suivante :

iwconfig interface options

où interface est le nom de l’interface réseau sans fil (par exemple wlan0), et options est la liste des
options permettant de définir les paramètres du réseau sans fil. Les principales options sont récapitulées
dans le tableau suivant :

Option Signification
channel Numéro du canal.
mode Mode de fonctionnement.
essid Nom de réseau.
nwid Numéro de réseau.
key Clef de chiffrement du
réseau.

Les modes de fonctionnement les plus courants sont le mode « ad hoc » pour le mode ad hoc, et le
mode « managed » pour l’utilisation d’un point d’accès. La page de manuel de iwconfig vous donnera la
liste des autres modes utilisables.
Par exemple, pour configurer une interface sans fil sur le canal 11, en mode managé et avec un nom de
réseau "MonWLAN", il faudra utiliser la commande suivante :

iwconfig wlan0 mode managed essid MonWLAN channel 11

À la suite de cette commande, l’interface wlan0 sera utilisable comme n’importe quelle interface réseau.
Si vous désirez définir une clef de chiffrement pour votre réseau sans fil, vous devrez utiliser l’option
key. L’utilisation du chiffrement peut être facultative en Wifi, sauf si l’interface est configurée pour
n’accepter que les communications chiffrées. L’option key peut donc accepter, en plus de la clef de
chiffrement (dont la taille est de 64 ou 104 bits, soit 8 ou 13 octets), un paramètre indiquant si le
chiffrement est obligatoire ou non. Ce paramètre peut prendre la valeur open si le chiffrement est
facultatif, restricted s’il est obligatoire, ou tout simplement off si le chiffrement doit être désactivé.
Par exemple, pour imposer l’utilisation d’une clef de chiffrement sur l’interface wlan0, la commande
suivante devra être utilisée :

iwconfig wlan0 key restricted 74151B6DCD98D808

Comme vous pouvez le constater, la clef est fournie en hexadécimal (c’est-à-dire en base 16, les chiffres
au dessus de 9 étant représentés par les lettres A à F). Pour sortir du mode chiffré, la commande suivante
pourra être utilisée :

257
 Chapitre 8. Configuration du matériel et des périphériques

iwconfig wlan0 key off

La liste des réseaux sans fils disponibles peut être récupérée avec l’option scan de la commande iwlist.
Par exemple, la commande suivante vous affichera tous les réseaux sans fils disponibles via l’interface
réseau wlan0, ainsi que leurs caractéristiques :

iwlist wlan0 scan

La commande iwlist accepte d’autres options, dont vous trouverez la liste et la description dans sa page
de manuel.
Enfin, utilisée sans option, la commande iwconfig affiche la configuration des interfaces sans fil du
système. En particulier, vous y trouverez le mode de fonctionnement, le numéro de canal et les
identifiants du réseau, éventuellement la clef de chiffrement utilisée, ainsi que la qualité du signal radio.
le mode La page de manuel de iwconfig vous donnera de plus amples informations sur la manière dont
ces informations peuvent être interprétées.

Configuration des ports de communication

Les ports de communication sont les seuls moyens de communication de l’ordinateur avec d’autres
appareils, et sont donc essentiels au même titre que les réseaux.
Historiquement, les plus vieux ports de communication utilisés sont sans doute les ports série, qui
permettent de connecter une multitude de périphériques en raison de sa grande simplicité. Les ports
parallèles sont également courants, et sont encore souvent utilisés pour connecter les imprimantes.
Cependant, ces ports souffrent de défauts indéniables, dont l’un des principaux est sans doute le faible
débit de données qu’ils autorisent. Ils ne peuvent donc pas être utilisés pour les applications les plus
exigeantes. C’est pour cela que les ports USB (abréviation de l’anglais « Universal Serial Bus ») et
IEEE1394 (alias « FireWire ») ont été inventés.
Cette section présente la manière de configurer les différents ports de communication actuellement
utilisés, à savoir le port parallèle, les ports série standards, et enfin les ports USB et IEEE1394.

Prise en charge des périphériques ISA standards

La plupart des PC disposent encore de périphériques d’entrée/sortie standards ISA intégrés aux cartes
mères, comme les ports série et les ports parallèles, même s’ils ne permettent plus de brancher des cartes
filles ISA. Il est donc encore nécessaire de prendre en charge ces fonctionnalités au niveau du noyau,
même si vous ne disposez d’aucun périphérique ISA.
Pour cela, il suffit d’activer les options « Plug and Play support » et « Plug and Play BIOS
support » du menu « Plug and Play support » de la configuration du noyau. Ces options permettent de
prendre en charge les ressources Plug and Play des cartes mères, et donc de réaliser la configuration
automatique des ports parallèles et série de l’ordinateur.

258
 Chapitre 8. Configuration du matériel et des périphériques

Configuration du port parallèle

La configuration du port parallèle sous Linux est relativement automatique. Il suffit en effet, dans le
programme de configuration du noyau, d’activer les options « Parallel port support »,
« PC-style hardware », « Use FIFO/DMA if available » et « IEEE 1284 transfer modes »
du menu « Parallel port support ». Si vous désirez connecter une imprimante sur votre port parallèle, ce
qui est généralement le cas, il vous faudra également activer l’option « Parallel printer
support » du menu « Character devices ». De même, si vous désirez connecter un disque dur, un lecteur
de CD-ROM ou un lecteur de bande sur votre port parallèle, vous devrez activer l’option « Parallel
port IDE device support » du menu « Block devices », ainsi qu’au moins une des sous-options
pour le type de périphérique à utiliser et un des modules de prise en charge des protocole de
communication sur port parallèle.
Pour des raisons de compatibilité, le gestionnaire de ports parallèles utilise par défaut une interrogation
périodique pour déterminer l’état des ports. Cela consomme généralement des ressources de calcul, mais
c’est une technique fiable. Toutefois, si votre matériel le permet, il est possible de le configurer pour
utiliser une interruption matérielle, et soulager ainsi le processeur de cette tâche. Nous allons donc voir
comment configurer le port parallèle ci-dessous.
Afin d’utiliser une interruption matérielle pour le port parallèle, il est nécessaire de spécifier
explicitement la ligne de cette interruption. Cela peut se faire avec l’option irq du module prenant en
charge le port parallèle. Sur les ordinateurs de type PC, le nom de ce module est « parport_pc », mais,
comme on l’a vu dans la la section intitulée Modules du noyau, le noyau demande toujours le
chargement du module « parport_lowlevel » pour des raisons de portabilité. Il faut donc définir un
alias dans le fichier de configuration /etc/[Link].
Outre la ligne d’interruption à utiliser, le module parport_pc peut prendre en paramètre une autre option
permettant d’indiquer le port d’entrée / sortie qu’il doit utiliser pour accéder au port parallèle. Cette
option est l’option io. En général, le port utilisé est le port numéro 378h et la ligne d’interruption est
souvent la 7. Les options suivantes doivent donc être définies dans le ficher [Link] pour
obtenir un fonctionnement optimal du port parallèle sous Linux :

alias parport_lowlevel parport_pc

options parport_pc io=0x378 irq=7

D’autre options pourront être définies dans le fichier de configuration [Link] pour prendre en
charge les périphériques de type bloc connectés sur port parallèle. Cela est inutile pour les imprimantes
connectées sur le port parallèle.
Si l’on désire intégrer le gestionnaire de périphérique du port parallèle dans le noyau et faire en sorte
qu’il utilise les paramètres détectés automatiquement pour ce port, la solution la plus simple est de
fournir l’option parport du noyau et de lui affecter la valeur auto :

parport=auto

Cela activera automatiquement l’utilisation de la ligne d’interruption du port parallèle. Les autres
paramètres du port parallèle peuvent être trouvés dans le fichier [Link] de la
documentation du noyau.

259
 Chapitre 8. Configuration du matériel et des périphériques

Configuration des ports série

Les ports série fournis en standard sur les cartes mères sont détectés et configurés automatiquement par
le noyau lorsque l’ordinateur démarre. Pour que cela fonctionne, il suffit que l’option
« Standard/generic (8250/16550 and compatible UARTs) serial support » du menu
« Character devices » soit activée.
Cela dit, il se peut que votre ordinateur contienne un port série non standard, ou que vous ayez à
sélectionner des options spécifiques pour votre matériel. Il vous faudra, dans ce cas, activer les options
complémentaires relatives aux ports série dans le menu « Character devices ».
Le noyau n’est, en général, capable d’initialiser que les ports série standards intégrés dans les cartes
mères (c’est-à-dire les ports COM1 à COM4), auxquels on accède, sous Linux, par l’intermédiaire des
fichiers spéciaux de périphériques /dev/ttyS0 à /dev/ttyS3. Pour les autres ports série, il peut être
nécessaire de les initialiser manuellement, par exemple dans un fichier de configuration lancé au
démarrage du système.
Cette initialisation se fait à l’aide de la commande setserial, dont la syntaxe simplifiée est la suivante :

setserial fichier [uart type] [port adresse] [irq ligne]

où fichier est le fichier spécial de périphérique permettant d’accéder au port série à initialiser, type
est le type de port série utilisé, adresse est son adresse d’entrée / sortie et ligne est la ligne
d’interruption qu’il utilise. La commande setserial dispose de nombreuses autres options. Je vous invite
à en lire la page de manuel pour les découvrir.
Une fois le port série correctement initialisé, il est possible de fixer les paramètres de la ligne de
communication avec la commande stty. Comme on l’a déjà vu précédemment, cette commande permet
de fixer tous les paramètres des lignes de communication des terminaux et non seulement les paramètres
des lignes série, et elle dispose donc d’un grand nombre d’options. Nous n’allons nous intéresser ici
qu’aux options utilisés pour les lignes série. La page de manuel de stty pourra être consultée pour plus
de détails.
La syntaxe à utiliser pour lire les paramètres de communication d’une ligne série est la suivante :

stty -a -F périphérique

où périphérique est le fichier spécial de périphérique de la ligne. Si vous exécutez cette commande,
vous constaterez qu’un grand nombre d’information est donné. Les informations les plus utiles sont sans
doute speed, qui donne la vitesse de la ligne série, csN, qui donne le nombre N de bits de données par
caractère, [-]parenb, qui indique si un bit de parité est utilisé ou non (auquel cas le caractère ’-’ est
présent), [-]parodd, qui indique le type de parité utilisée (paire ou impaire selon la présence ou
l’absence du caractère ’-’), et [-]cstopb, qui indique le nombre de bits de stop utilisés (un ou deux
selon la présence ou l’absence du caractère ’-’). L’option [-]crtscts indique si le contrôle de flux
matériel est utilisé ou non. À titre d’exemple, voici une sortie typique de la commande stty sur le premier
port série :

speed 9600 baud; rows 0; columns 0; line = 0;

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <indéfini>;
eol2 = <indéfini>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl

260
 Chapitre 8. Configuration du matériel et des périphériques

ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl

onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

Les mêmes options peuvent être utilsées pour fixer les paramètres de la ligne de communication. La ligne
de commande à utiliser est alors la suivante :

stty -F périphérique options

Il existe une différence cependant : le paramètre permettant de fixer la vitesse de la ligne est décomposé
en deux options ispeed pour le flux de données entrant et ospeed pour le flux de données sortant. On
peut fixer la vitesse de la ligne avec l’option ispeed. Par exemple, pour faire passer la ligne de
communication du deuxième port série à 115200 bauds, 7 bits de données, un bit de stop et une parité
paire, il faut utiliser la ligne de commande suivante :

stty -F /dev/ttyS1 ispeed 115200 cs7 -cstopb parenb -parodd

Il est important de bien configurer les ports série avec les mêmes paramètres de ligne que ceux utilisés
par les périphériques qui y sont connectés pour que la communication se fasse correctement.

Installation des périphériques USB

Bien qu’ayant eu quelques difficultés à ses débuts, le port USB est désormais en pleine expansion. Il
s’agit d’une extension des ports série classiques, qui offre les avantages suivants :

• possibilité de connecter jusqu’à 127 périphériques sur un même port, selon une structure arborescente ;
• bande passante accrue jusqu’à 12 Mbits/s théoriques pour l’USB 1.1, et de 480 Mbits/s pour l’USB
2.0 ;
• capacité de connexion des périphériques « à chaud » et détection automatique par le système
d’exploitation ;
• possibilité d’alimentation des périphériques par le bus lui-même, évitant ainsi d’avoir des câbles
supplémentaires pour les périphériques consommant peu d’électricité.

Tous ces avantages font que le bus USB est appelé à remplacer les ports série que l’on connaît, et que l’on
n’utilise plus désormais que pour les modems, les vieilles souris série et quelques appareils extérieurs.
Notez que la simplicité du port série fera qu’il restera encore présents sur bon nombre d’appareils pour
plusieurs années encore, mais les périphériques informatiques risquent de s’en détourner de plus en plus.
La gestion de l’USB sous Linux se base profondément sur les mécanismes de détection dynamique des
périphériques connectables à chaud. Les gestionnaires de périphériques sont donc généralement des
modules du noyau chargés automatiquement lorsque ces périphériques sont détectés. Il est toutefois
également possible d’intégrér ces gestionnaires au sein du noyau, et de laisser les opérations de

261
 Chapitre 8. Configuration du matériel et des périphériques

configuration des périphériques (chargement du firmware, création des fichiers spéciaux de périphériques
par udev et configuration du matériel) se faire via les mécanismes de gestion des périphériques
amovibles. Linux est capable d’utiliser la plupart des périphériques USB existant actuellement sur le
marché.
Au niveau du noyau, la configuration des périphériques USB se fait dans le menu « USB support ». Il
faut simplement activer l’option « Support for USB », sélectionner un gestionnaire pour le port USB
et choisir les gestionnaires des différents types de périphériques que l’on voudra connecter sur la
machine.
Il est impératif d’activer l’option « USB device filesystem » afin de permettres à certains outils
d’accéder, via le répertoire /proc/bus/usb/ du système de fichiers virtuel /proc/, aux périphériques
USB connectés à l’ordinateur. Ce système de fichiers doit être monté à l’aide de la commande suivante :

mount -t usbfs none /proc/bus/usb

pour pouvoir être utilisé. Il est également possible de le monter automatiquement dans le fichier
/dev/fstab.

En fait, il existe trois types d’interfaces USB sur le marché : les interfaces EHCI (abréviation ed l’anglais
« Enhanced Host Controler Interface »), qui prennent en charge l’USB 2.0, les interfaces UHCI
(abréviation de l’anglais « Universal Host Controller Interface »), spécifiées par Intel et que les
contrôleurs de la plupart des cartes mères utilisent (chipsets Intel et VIA), et les interfaces OHCI (« Open
Host Controller Interface »), spécifiées par Compaq, et qui sont utilisées par les chipsets Compaq et ALi
principalement. Les ports USB 2.0 comprennent également un port USB 1.1 UHCI ou OHCI, qui permet
donc de connecter les anciens périphériques USB. La configuration de l’USB se restreint donc
simplement à la sélection des pilotes nécessaires pour votre matériel (option « EHCI HCD (USB 2.0)
support » si vous disposez d’un port USB 2.0, et le pilote UHCI « UHCI HCD (most Intel and
VIA) support » ou le pilote OHCI « OHCI HCD support »). Notez que le pilote EHCI ne gère que la
partie USB 2.0 de votre contrôleur USB, et que vous devez également inclure le support UHCI ou OHCI
pour pouvoir utiliser les périphériques USB 1.1.
Comme vous pouvez le constater dans le menu de configuration du noyau, un grand nombre de
périphériques USB sont gérés par Linux. Vous devez bien entendu activer les options permettant de
prendre en charge votre matériel. Il est conseillé d’inclure ces fonctionnalités sous forme de modules afin
de permettre le chargement dynamique des gestionnaires de périphériques. Cela est nécessaire pour la
configuration des périphériques connectés à chaud dans le système. Les options les plus importantes sont
sans doute « USB Audio support », pour la prise en charge des périphériques USB audio, « USB
Printer support », pour toutes les imprimantes USB et « USB Mass Storage support », pour la
prise en charge des clefs USB et de la majorité des appareils photos numériques. Les scanners USB sont
pris en charge automatiquement par les logiciels et ne requièrent pas de configuration particulière au
niveau du noyau.
Les périphériques d’entrée tels que le clavier et la souris devront, si possible, être inclus directement au
sein du noyau afin d’éviter de se retrouver sans clavier et sans souris au démarrage, en cas de problème
dans la configuration du système. Notez qu’il existe deux types de pilotes pour les périphériques
d’entrée : un pilote général (option « USB Human Interface Device (full HID) support ), qui
fonctionne avec tous les périphériques d’entrée du menu « Input core support », et des pilotes
simplifiés (options du sous-menu « USB HID Boot Protocol drivers »), que l’on utilisera pour
réaliser des systèmes embarqués ou des noyaux légers. Il est évidemment recommandé d’utiliser le
premier pilote, si réellement le support du clavier USB est nécessaire (normalement, les claviers USB

262
 Chapitre 8. Configuration du matériel et des périphériques

sont pris en charge par le BIOS de l’ordinateur et apparaissent exactement comme des claviers classiques
pour le système d’exploitation).
Il est fortement recommandé, si l’on désire utiliser des périphériques USB, d’activer les fonctionnalités
de chargement dynamique des modules, de gestion des périphériques connectables à chaud et de
chargement des firmware automatique de Linux.

Installation des périphériques IEEE1394

Le bus IEEE1394 (initialement dénommé bus FireWire) est un bus série à grande vitesse, capable de
transférer des données avec un très grand débit (400 mégabits par secondes). Ce bus peut être utilisé pour
connecter de nombreux périphériques (disques dur et lecteurs de CDROM externes par exemple), mais
sa principale utilisation reste pour les transferts de données vidéo provenant des caméscopes numériques.
Certaines cartes mères disposent d’un port IEEE1394 intégré, mais la plupart nécessitent l’ajout d’une
carte fille PCI. La plupart de ces cartes sont vendues en tant que cartes de montage vidéo et disposent de
deux ports IEEE1394 afin de permettre une entrée et une sortie du flux vidéo.
Le bus IEEE1394 dispose d’avantages indéniables, puisqu’il permet de brancher et de débrancher un
périphérique à chaud (c’est-à-dire sans redémarrer l’ordinateur), les données sont transférées en
numérique (donc sans perte de qualité pour les séquences vidéo), et de piloter les appareils qui y sont
connectés (ce qui permet de contrôler par exemple un caméscope à partir d’un logiciel de montage
vidéo). Il est également possible d’utiliser le bus IEEE1394 pour connecter deux ordinateurs en réseau,
bien que cette fonctionnalité soit encore expérimentale.
Linux dispose des pilotes permettant d’utiliser les ports IEEE1394 de manière générique. Cependant, il
faut bien le reconnaître, les logiciels spécifiques aux différents types d’appareils sont encore très rares ou
incomplets. Cet état de fait est particulièrement vrai en ce qui concerne les caméscopes numériques, pour
lesquels il n’existe quasiment aucun logiciel de montage vidéo dont la qualité s’approche de celle de
ceux qui ont été développés pour Windows. Cela dit, les autres périphériques tels que les disques durs et
les lecteurs de CD-ROM externes sont mieux supportés, et la configuration du port IEEE1394 peut être
réalisée complètement en attendant que des logiciels plus évolués ne voient le jour. Vous pouvez obtenir
les dernières informations concernant le support des périphériques FireWire sous Linux sur le site de
linux1394 ([Link]

Configuration du noyau
La prise en charge du bus IEEE1394 au niveau du noyau est réalisable par l’intermédiaire des options du
menu « IEEE 1394 (FireWire) support (EXPERIMENTAL) ». Comme le support des périphériques
IEEE1394 sous Linux en est encore à ses balbutiements, ce menu ne peut être accédé que si l’on a activé
l’option « Prompt for development and/or incomplete code/drivers » du menu « Code
maturity level options ». Les principales options utilisables sont les suivantes :

• l’option « IEEE 1394 (FireWire) support (EXPERIMENTAL) », qui est l’option principale qui
active toutes les autres options. Il faut donc impérativement activer cette option et répondre ’Y’ ;
• l’option « Texas Instruments PCILynx support », qui permet de prendre en charge les cartes
IEEE1394 basées sur la puce PCILynx de Texas Instrument. Ce ne sont pas les cartes les plus
couramment utilisées, aussi la réponse recommandée est-elle ’N’. Si vous activez cette option, vous
pourrez configurer des paramètres complémentaires du gestionnaire de périphériques avec les options

263
 Chapitre 8. Configuration du matériel et des périphériques

« Use PCILynx local RAM » (utilisation de la mémoire embarquée sur la carte PCI) et « Support
for non-IEEE1394 local ports » (utilisation de fonctionnalités complémentaires non FireWire
de ces cartes) ;
• l’option « OHCI-1394 support », qui active la prise en charge des périphériques IEEE1394
compatible OHCI (abréviation de l’anglais « Open Host Controller Interface ), qui sont les
périphériques les plus courants à présent. La réponse recommandée est ’Y’ ;
• l’option « OHCI-1394 Video support », qui permet de prendre en charge les caméras vidéo
numériques. Cette option ajoute également une fonctionnalité intéressante qui permet aux programmes
de partager les données avec le gestionnaire de périphériques directement. Cela permet d’éviter qu’une
copie de ces données ne soit réalisée entre la mémoire du noyau et la mémoire de l’application et
d’obtenir ainsi de meilleures performances. La réponse recommandée est bien évidemment ’Y’. Cette
option n’est toutefois disponible que pour les périphériques OHCI ;
• l’option « SBP-2 support (Harddisks, etc.) », qui permet de prendre en charge les disques
durs et les lecteurs de DVD connectés sur bus IEEE1394. Ces lecteurs apparaissent alors comme des
périphériques SCSI standards et pourront être montés via l’un des périphériques /dev/sdx ;
• l’option « Raw IEEE1394 I/O support », qui permet aux applications de communiquer
directement avec le bus IEEE1394 par l’intermédiaire d’un fichier spécial de périphérique. Cette
option est nécessaire au bon fonctionnement de la plupart des applications IEEE1394 et la réponse
recommandée est donc ’Y’ ;
• l’option « Excessive debugging output », qui active l’émission de messages de traces pour
toutes les données survenant sur le bus IEEE1394. Cette option saturera vos fichiers de traces très vite
et n’est réellement utile que pour les développeurs, aussi faut-il répondre ’N’.

Comme pour tous les périphériques sous Linux, les fonctionnalités IEEE1394 du noyau seront
accessibles par l’intermédiaire de fichiers spéciaux de périphériques situés dans le répertoire /dev/. Les
fonctionnalités vidéo seront accédées par l’intermédiaire d’un fichier spécial de périphérique de type
caractère et de code majeur 172. De même, l’interface de données brute activée par l’option « Raw
IEEE1394 I/O support » est exposée par l’intermédiaire d’un fichier spécial de périphérique de type
caractère et de code majeur 171. Vous devrez donc créer ces fichiers spéciaux à l’aide des deux
commandes suivantes :

mknod /dev/raw1394 c 171 0

mknod -m 666 /dev/video1394 c 172 0

Le numéro de code mineur est utilisé pour distinguer les différents ports IEEE1394 présents dans la
machine. Les lignes de commandes précédentes ne montrent que la manière de créer les fichiers spéciaux
de périphériques que pour le premier port IEEE1394.

Installation des bibliothèques complémentaires

Les fonctionnalités IEEE1394 peuvent être utilisées par les applications directement par l’intermédiaire
des fichiers spéciaux de périphériques /dev/raw1394 et /dev/video1394, mais quasiment aucune ne
le fait. En effet, des bibliothèques spécifiques ont été écrites afin de fixer les interfaces de programmation
de Linux avec ces applications. Il est donc nécessaire d’installer ces bibliothèques pour pouvoir utiliser
les périphériques IEEE1394.

264
 Chapitre 8. Configuration du matériel et des périphériques

Il est encore rare que ces bibliothèques soient installées par les distributions, certainement parce qu’elles
sont encore en cours de développement. Leur installation nécessite donc de les compiler soi-même, ce
qui est une tâche facile si on sait le faire, mais qui peut effrayer un débutant. Rappelons une fois de plus
que le support des périphériques IEEE1394 sous Linux est encore expérimental.
La bibliothèque de programme la plus importante est celle qui permet d’utiliser la fonctionnalité d’accès
direct aux périphériques IEEE1394 par l’intermédiaire du fichier spécial de périphérique
/dev/raw1394. Les fichiers sources de cette bibliothèque peuvent être trouvées sur le site du projet
libraw1394 ([Link] Une autre bibliothèque utilisée par les
programmes vidéo est la bibliothèque libavc1394 ([Link] Cette
bibliothèque permet en effet aux programmes de piloter les caméscopes numériques par l’intermédiaire
du bus IEEE1394. Enfin, les programmes d’édition vidéo peuvent avoir besoin de la bibliothèque libdv
([Link] qui permet de manipuler les données au format DV (c’est-à-dire le format
de données utilisé par la plupart des caméscopes numériques). Cette bibliothèque ne fait pas à
proprement parler partie des bibliothèques permettant de communiquer avec les périphériques
IEEE1394, mais elle est extrêmement utile.
La compilation de ces bibliothèques se fait classiquement avec les commandes suivantes :

./configure --prefix=/usr
make

à partir du répertoire des sources. Celui-ci pourra être extrait des archives à l’aide de la commande tar
xzf archive, où archive est le nom de l’archive en question. Une fois compilées, les bibliothèques
pourront être installées avec la commande :

make install

Ces opérations ne devraient pas poser de problème particulier. Consultez le Chapitre 7 pour plus de
détails sur ces opérations.
Une fois ces bibliothèques installées, vous devriez pouvoir installer et utiliser des applications dédiées
aux périphériques IEEE1394, comme dvgrab (outil de capture vidéo), kino ou broadcast2000 (outils
d’édition de séquences vidéo). Force est de reconnaître que ces programmes sont très loins d’être finis et
réellement difficiles à utiliser.

265
Chapitre 9. Configuration du réseau
Linux est un système d’exploitation fabriqué par l’Internet et pour l’Internet. Inutile de préciser que c’est
l’un des meilleurs systèmes pour gérer et exploiter un réseau. Certains ne l’utilisent d’ailleurs que pour
cela, et profitent de ses excellentes performances sur les petites machines afin de récupérer du matériel
autrement voué à la casse. En fait, les fonctionnalités réseau de Linux sont si nombreuses que j’ai été
obligé d’y consacrer un chapitre à part entière.
La configuration d’un réseau est une opération qui nécessite quelques connaissances théoriques sur le
fonctionnement des réseaux TCP/IP. Ces informations sont assez techniques, mais indispensables pour
bien configurer les services réseau de toute machine connectée, et pas seulement les machines
fonctionnant sous Linux. Il n’est en effet pas rare de trouver des réseaux de machines fonctionnant sur
des systèmes dont la configuration est supposée être plus simple, mais dont l’organisation est une hérésie
absolue et qui risque de nécessiter une remise à plat complète à chaque interconnexion.
Cette section va donc donner quelques explications sur les notions fondamentales des réseaux
informatiques. Il traitera ensuite de la configuration des réseaux locaux, puis celle des connexions
temporaires à Internet. Les services réseau évolués tels que le partage de connexion à Internet et la
création d’un serveur de fichiers seront finalement traités en fin de chapitre.

Notions de réseau TCP/IP

Généralités sur les réseaux

Un réseau n’est en général rien d’autre qu’une interconnexion entre plusieurs machines qui leur permet
d’échanger des informations. Il existe de nombreux moyens de réaliser cette interconnexion, qui utilisent
parfois des supports physiques variés. Les techniques les plus utilisées sont la liaison radio et la liaison
par câble. Cette dernière technique comprend diverses variantes, dont les réseaux Ethernet, TokenRing et
simplement la liaison téléphonique.
Il est évident que la manière d’envoyer et de recevoir des informations est différente pour ces différents
supports physiques, parce qu’elle dépend tout simplement des possibilités techniques offertes par la
technologie sous-jacente utilisée. Cependant, il est très courant de découper les informations à échanger
en paquets, qui sont ensuite transmis sur le réseau. Ces paquets peuvent être de tailles variées, et contenir
des informations utiles à la gestion du réseau. L’information la plus importante est sans doute celle
permettant de connaître la machine destinataire du paquet. On l’appelle l’adresse de la machine cible, il
s’agit généralement d’un numéro permettant de l’identifier de manière unique sur le réseau. En général,
les paquets contiennent également l’adresse de la machine source, afin qu’une réponse puisse lui être
envoyée.

266
 Chapitre 9. Configuration du réseau

Figure 9-1. Notion de paquet et d’adresse réseau

Du fait de la diversité des supports physiques de réseau, il n’est pas simple d’écrire une application
réseau qui puisse travailler dans des environnements réseau hétérogènes. Cela supposerait de connaître
les protocoles de communication pour chaque type de réseau, ce qui compliquerait à l’infini le moindre
programme et le rendrait inutilisable avec les nouveaux réseaux. Par conséquent, cette tâche ingrate a été
reléguée au plus profond des couches réseau spécifiques au support physique. Les applications quant à
elles utilisent un protocole de communication plus évolué, dont le but est d’assurer l’interopérabilité des
différents supports physiques. Ce protocole utilise toujours des paquets et une notion d’adresse, mais
cette fois ces informations sont standardisées et utilisables par toutes les applications. Les paquets de ce
protocole sont stockés dans les paquets des réseaux physiques et transmis tels quels. Ils peuvent
éventuellement être découpés en sous-paquets dans le cas où la taille des paquets du réseau serait trop
petite pour les contenir. Cette technique s’appelle l’encapsulation d’un protocole dans un autre protocole.

Figure 9-2. Encapsulation de protocoles

Le protocole IP
Les machines Unix utilisent toutes le protocole de communication de bas niveau IP (« Internet

267
 Chapitre 9. Configuration du réseau

Protocol »). Ce protocole a été inventé pour permettre l’interconnexion d’un grand nombre de réseaux
physiques différents (le nom d’Internet provient d’ailleurs de cette caractéristique : « INTERconnected
NETworks »). Il permet de transmettre des informations de manière uniforme sur tous ces réseaux
physiques. Ainsi, les programmes qui utilisent IP ne voient pas les spécificités des différents réseaux
physiques. Pour eux, il ne semble y avoir qu’un seul réseau physique, dont le protocole de
communication de base est IP. Autrement dit, les applications qui utilisent le réseau se contentent
d’utiliser le protocole IP, et n’ont plus à se soucier de la manière dont il faut formater et transmettre les
informations sur chaque support physique du réseau. Ce genre de détail est laissé aux couches réseau de
chaque machine et aux passerelles reliant les divers réseaux physiques.
Comme il l’a déjà été dit ci-dessus, le protocole IP utilise des adresses pour identifier les machines sur
les réseaux. Les adresses IP sont codées sur quatre octets (nombres binaires à huit chiffres, permettant de
représenter des valeurs allant de 0 à 255), chacun définissant une partie du réseau. Ces adresses sont
utilisées un peu comme les numéros de téléphone : le premier octet définit le numéro d’un
« super-réseau » dans lequel le correspondant se trouve (ces « super-réseaux » sont appelés les réseaux
de classe A), le deuxième octet définit le numéro du sous-réseau dans le super-réseau (ces sous-réseaux
sont appelés réseaux de classe B), le troisième octet définit encore un sous-sous-réseau (réseaux dits de
classe C) et le quatrième octet donne le numéro de la machine dans ce sous-sous-réseau.
Cette numérotation permet d’affecter des adresses similaires pour les différentes machines d’un réseau,
et de simplifier ainsi la gestion de ce dernier. Elle dispose en revanche d’un inconvénient majeur :
beaucoup d’adresses sont gaspillées, car il n’y a pas suffisamment de réseaux de classe A d’une part, et
qu’on ne peut pas mélanger les machines de deux sous-réseaux dans un même réseau de classe A d’autre
part. Si l’on reprend la comparaison avec les numéros de téléphone, il y a énormément d’abonnés dont le
numéro commence par 01, mais beaucoup moins dont le numéro commence par 02, et quasiment aucun
dont le numéro commence par 08. Si l’on venait à manquer de place dans la liste des numéros
commençant par 01, on ne pourrait pas pour autant utiliser les numéros commençant par 02 pour des
raisons géographiques. C’est la même chose pour les adresses IP, sauf que les zones géographiques sont
remplacées par des sous-réseaux. Le problème est que, malheureusement, on commence à manquer
d’adresses disponibles (alors qu’il y en a plein de libres mais inutilisables parce qu’elles se trouvent dans
d’autres sous-réseaux !). Il va donc falloir effectuer une renumérotation d’ici peu, exactement comme il y
en a déjà eu dans le monde de la téléphonie...

Note : Le protocole IPv6, qui remplacera le protocole IP classique (encore appelé IPv4), a pour but
de résoudre les limitations du protocole IP utilisé actuellement. Les adresses du protocole IPv6 sont
codées sur 16 octets, ce qui résoudra définitivement le problème du manque d’adresses. De plus,
les services modernes que sont l’authentification de l’émetteur, ainsi que la qualité de service
(c’est-à-dire la garantie du délai de transmission des données, garantie nécessaire pour transmettre
de façon correcte les flux multimédia tels que le son et la vidéo en temps réel) sont fournis par IPv6.
Bien entendu, Linux est déjà capable d’utiliser IPv6 (combien de systèmes peuvent aujourd’hui
l’affirmer ?) ! Notez toutefois que pour cela, il faut recompiler le noyau et toutes les applications
réseau du système, ce qui est tout de même très lourd. Par conséquent, il vaut mieux se contenter
du protocole IP actuel. Malgré ses limitations, ce protocole reste sans doute le meilleur protocole
réseau du monde, car il allie souplesse et fonctionnalité. Il est difficilement concevable de créer un
réseau aussi grand qu’Internet avec les autres protocoles existant sur le marché...

Les adresses IP sont donc parfaitement définies à l’aide de leurs quatre nombres, que l’on note les uns à
la suite des autres et en les séparant d’un point. Comme on l’a vu, les adresses IP sont classées en
sous-réseaux, de classe A, B et C. Les adresses des réseaux de classe C ont leurs trois premiers nombres

268
 Chapitre 9. Configuration du réseau

fixés, et seul le quatrième nombre change pour chaque machine du réseau. De la même manière, les
réseaux de classe B ont leurs deux premiers nombres fixés, et seuls les deux derniers nombres permettent
de distinguer les différentes machines du réseau. Enfin, les réseaux de classe A n’ont de fixé que leur
première composante, les autres sont libres. Il est donc clair qu’il existe peu de réseaux de classe A, mais
que ce sont de très gros réseaux (ils peuvent contenir jusqu’à 16 millions de machines !). En revanche, il
existe beaucoup plus de réseaux de classe C, dont la taille est plus modeste (seulement 256 machines).
Pour un réseau donné, les adresses ont donc toutes la même forme. Les premiers octets des adresses du
réseau sont toujours les mêmes (ce peut être le premier octet pour les réseaux de classe A, les deux
premiers pour les réseaux de classe B ou les trois premiers pour les réseaux de classe C). On peut donc
définir la notion d’adresse de réseau, qui est l’adresse IP d’une machine du réseau dont les parties
variables ont pour valeur 0. Par exemple, si une machine d’un réseau de classe C a pour adresse
[Link], alors l’adresse de son sous-réseau est [Link]. Cela signifie que toutes les machines de
ce réseau auront une adresse de la forme « [Link] ».
Un réseau n’appartient qu’à une et une seule classe. Les adresses IP sont réparties sur les différentes
classes de réseaux, selon la valeur des bits de poids fort de leur premier octet. Par exemple, les réseaux de
classe A sont identifiables au fait que le bit de poids fort de leur adresse est nul. Les adresses de réseau
valides pour les réseaux de ce type sont donc les adresses comprises entre [Link] et [Link]. Il n’existe
donc que 128 réseaux de classes A en tout et pour tout. Les autres réseaux ont donc le bit de poids fort de
leur adresse fixé à 1, et c’est le deuxième bit de poids fort qui est utilisé pour distinguer les réseaux de
classe B des autres. Les réseaux de classe B utilisent toujours la valeur 0 pour ce bit, leurs adresses
varient donc entre [Link] et [Link]. De même, les réseaux de classe C utilisent la valeur 1 pour le
deuxième bit de leur adresse, et ont nécessairement un troisième bit nul. Leurs adresses vont donc de
[Link] à [Link]. Les adresses pour lesquelles le troisième bit (en plus des deux premiers) est à
1 sont réservées (soit pour une utilisation ultérieure, soit pour s’adresser à des groupes d’ordinateurs en
multicast) et ne doivent pas être utilisées. Il s’agit des adresses [Link] à [Link]. Cette
dernière adresse a une signification spéciale et permet de s’adresser à tous les ordinateurs d’un réseau.
Il est possible de déterminer l’adresse du réseau auquel une machine appartient en utilisant ce qu’on
appelle le masque de sous-réseau. Le masque de sous-réseau est une série de quatre nombres ayant le
même format que les autres adresses IP, mais dont les composantes ne peuvent prendre que la valeur 0 ou
la valeur 255, les 255 devant nécessairement apparaître en premier. Les composantes des adresses IP qui
correspondent à la valeur 255 dans le masque de sous-réseau font partie de l’adresse dudit sous-réseau.
Les composantes qui correspondent à la valeur 0 dans le masque de sous-réseau n’en font pas partie, et
varient pour chaque machine du réseau. Pour reprendre l’exemple précédent, si une machine a pour
adresse IP [Link] et que son masque de sous-réseau est [Link], alors l’adresse de son
réseau est [Link]. Si le masque de sous-réseau avait été [Link] (typiquement le masque d’un
réseau de classe B), l’adresse du réseau aurait été [Link]. Comme on le voit, le masque de
sous-réseau est utilisé par le système pour déterminer rapidement l’adresse de sous-réseau d’une
machine à partir de son adresse IP. On notera que certaines combinaisons d’adresses IP et de masques de
sous-réseau sont invalides. Par exemple, les adresses affectées aux réseaux de classe C (comme
[Link] par exemple) ne peuvent pas avoir de masque de sous-réseau en [Link], car cela
impliquerait que cette adresse serait une adresse de réseau de classe B.

269
 Chapitre 9. Configuration du réseau

Figure 9-3. Addresse IP et adresse de réseau

Les adresses IP ne sont pas attribuées aux machines au hasard. Il est évident que chaque machine doit
avoir une adresse unique, et que son adresse doit appartenir à la plage d’adresses utilisée pour le
sous-réseau dont elle fait partie. Pour cela, les classes de réseau, ainsi que les adresses qu’ils utilisent,
sont attribuées par l’IANA, un organisme de gestion de l’Internet. Le rôle de l’IANA (abréviation de
l’anglais « Internet Assigned Numbers Authority ») est essentiellement d’assurer l’unicité des adresses
IP sur l’Internet. Cependant, certaines adresses sont librement utilisables pour les réseaux locaux qui ne
sont pas connectés directement à l’Internet. Les paquets utilisant ces adresses sont assurés de ne pas être
transmis sur Internet. Ces adresses peuvent donc être utilisées par quiconque. Les plages d’adresse
réservées sont les suivantes :

Tableau 9-1. Plages d’adresses IP réservées pour un usage personnel

Classe de réseau Adresses de réseau réservées

A [Link]
B [Link] à [Link]
C [Link] à [Link]

Ainsi, un réseau de classe A (d’adresse [Link]), 16 réseaux de classe B (les réseaux [Link] à
[Link]) et 255 réseaux de classe C (d’adresses [Link] à [Link]) sont disponibles. Vous
pouvez donc les utiliser librement.
Il est également possible de configurer les machines pour qu’elles récupèrent leurs adresses IP auprès
d’un serveur à l’aide du protocole DHCP (abréviation de l’anglais « Dynamic Host Configuration
Protocol »). Cette technique est très intéressante quand on dispose d’un grand nombre de machines qui
ne sont pas toujours toutes connectées à un réseau. Il est donc possible de redistribuer les adresses IP
d’un stock d’adresses en fonction des machines qui se connectent, et d’économiser ainsi les précieuses
adresses. En revanche, elle n’est pas appropriée pour les serveurs qui sont couramment accédés par des
postes clients, et qui doivent donc avoir une adresse IP fixe.
Certaines adresses IP ont une signification particulière et ne peuvent pas être attribuées à une machine.

270
 Chapitre 9. Configuration du réseau

Par exemple l’adresse [Link] représente, pour une machine, elle-même. Cette adresse est souvent
utilisée pour accéder à un programme réseau sur la machine locale. Elle fait partie du sous-réseau de
classe A [Link], qui ne comprend pas d’autres adresses. De plus, les adresses dont les derniers
nombres (c’est-à-dire les nombres qui ne font pas partie de l’adresse du réseau) se terminent par 0 ou 255
sont réservées pour l’envoi des paquets à destination de tout le monde sur le réseau (émission dite
« broadcast »). Par exemple, les adresses [Link] et [Link] ne peuvent pas être affectées à
une machine. Ce sont typiquement ces adresses qui sont utilisées par le protocole DHCP pour émettre
des requêtes sur le réseau alors que la machine n’a pas encore d’adresse fixe.
Il est important de savoir que, par défaut, une machine ne communiquera qu’avec les machines de son
propre réseau. C’est à dire que si une machine utilise l’adresse IP [Link] et que son masque de
sous-réseau est [Link], elle ne pourra contacter que des machines dont l’adresse est de la forme
[Link]. Elle ne pourra donc pas voir par exemple une machine dont l’adresse IP est [Link].
Cela ne signifie pas que l’on doive toujours utiliser le masque [Link] pour voir toutes les machines du
monde, mais plutôt que la machine [Link] ne fait pas partie, a priori, du même réseau physique que
la machine [Link]. Il est donc inutile de chercher à la contacter (et mettre le masque de
sous-réseau à [Link] ne résoudrait évidemment pas le problème). Cependant, si deux réseaux physiques
ont nécessairement deux adresses de réseau différentes, rien n’empêche de définir, sur un même réseau,
plusieurs réseaux logiques. Ainsi, une même carte réseau peut avoir plusieurs adresses IP. La
communication avec les machines des différents réseaux logiques se fait alors par l’intermédiaire de la
même interface réseau.
Arrivé à ce stade des explications, je sens venir la question suivante : « ?! Euhhh... Mais alors, comment
peut-on voir les machines sur Internet ? Je n’ai pas de réseau, et quand je me connecte à Internet, je peux
y accéder ! Et même si j’avais un réseau, elles ne feraient certainement pas partie de mon réseau... ».
Explications :

• premièrement, vous avez un réseau, même si vous ne le savez pas. Toute machine appartient
généralement au moins à son propre réseau virtuel, sur laquelle elle est la seule machine, et où elle a
l’adresse [Link] ;
• deuxièmement, effectivement, les machines qui se trouvent sur Internet n’appartiennent pas à votre
réseau, que celui-ci existe effectivement ou soit virtuel ;
• troisièmement, toutes les informations que vous envoyez et recevez transitent par un seul ordinateur,
celui de votre fournisseur d’accès à Internet. C’est cet ordinateur qui se charge de faire le transfert de
ces informations vers les machines situées sur Internet.

C’est donc ici qu’intervient la notion de passerelle (« Gateway » en anglais).

Une passerelle est une machine qui appartient à deux réseaux physiques distincts, et qui fait le lien entre
les machines de ces deux réseaux. Les ordinateurs des deux réseaux peuvent communiquer avec la
passerelle de part et d’autre, puisqu’elle appartient aux deux réseaux. Les ordinateurs de chaque réseau
transmettent à cette passerelle tous les paquets qui ne sont pas destinés à une machine de leur propre
réseau. Celle-ci se charge simplement de transférer ces paquets aux machines de l’autre réseau.

271
 Chapitre 9. Configuration du réseau

Figure 9-4. Notion de passerelle

Lorsque vous vous connectez à Internet, vous ne faites rien d’autre que de créer un réseau (dont le
support physique est la ligne téléphonique), et vous utilisez l’ordinateur que vous avez appelé comme
passerelle par défaut. Tous les paquets destinés à un autre réseau que le vôtre (donc, en pratique, tous les
paquets si vous n’avez pas de réseau local) sont donc envoyés sur le réseau constitué de votre connexion
à Internet et arrivent donc chez votre fournisseur d’accès, qui se charge ensuite de les transmettre aux
autres ordinateurs. Notez que celui-ci peut transmettre ces paquets à une autre passerelle à laquelle il a
accès et ainsi de suite, jusqu’à ce que la destination soit atteinte.
Dans le cas d’un particulier, le choix du réseau sur lequel les paquets doivent être transmis est très facile
à faire puisqu’en général un paquet est soit à destination de la machine locale, soit à destination d’une
machine sur Internet. Pour un paquet destiné à la machine locale, le réseau virtuel local est utilisé. Tous
les autres paquets sont envoyés sur la connexion Internet. Cependant, il peut arriver qu’une machine ait
le choix entre plusieurs passerelles différentes pour envoyer un paquet dont la destination n’est pas sur
son propre réseau. Par exemple, les passerelles d’Internet peuvent être elles-mêmes connectées à
différents autres réseaux, qui sont eux-mêmes connect s à d’autres réseaux. Un paquet peut donc être
acheminé de plusieurs manières à sa destination, selon la topologie du réseau. L’ensemble des réseaux
empruntés par un paquet dans son voyage constitue ce qu’on appelle sa route.
Chaque passerelle contribue donc à déterminer la route des paquets en choisissant, pour chaque paquet,
l’interface réseau à utiliser pour transmettre ce paquet. Ce choix est fait en suivant un certain nombre de
règles basées sur l’adresse destination des paquets. Par exemple, si une passerelle reçoit un paquet dont
l’adresse destination est [Link], et qu’elle est elle-même connectée à un réseau possédant cette
machine, elle transmettra bien évidemment ce paquet sur ce réseau. Si en revanche elle ne peut localiser
la machine cible sur l’un de ses réseaux, elle l’enverra à une autre passerelle à laquelle elle a accès. Le
choix de cette passerelle est en général déterminé par des règles de la forme suivante : « Tous les paquets
destinés au sous-réseau [Link] doivent être envoyés vers la passerelle [Link] du réseau
[Link] ». Notez qu’à chaque étape de la route, seules les passerelles de l’étape suivante peuvent être

272
 Chapitre 9. Configuration du réseau

choisies comme relais.

Ainsi, si la passerelle est connectée à trois réseaux d’adresses respectives [Link], [Link] et
[Link], elle transférera le paquet à destination de [Link] à la passerelle [Link]. La
transmission effective du paquet à cette passerelle se fera ensuite selon le protocole réseau bas niveau
utilisé sur le réseau [Link]. Autrement dit, une passerelle est une machine qui, contrairement aux
machines classiques, accepte de recevoir des paquets qui ne lui sont pas directement adressés, et de les
traiter en les réémettant vers leur destination ou vers une autre passerelle, selon les règles de routage
qu’elle utilise.
Les règles utilisées par les passerelles sont stockées dans ce qu’on appelle des tables de routage. Les
tables de routage peuvent être configurées statiquement dans la configuration des passerelles, c’est-à-dire
initialisées dans les fichiers de configuration et ne jamais être modifiées. Cette technique convient
parfaitement pour les petits réseaux. Elle se révèle cependant insuffisante sur les passerelles d’Internet.
En effet, si les réseaux empruntés par une route sont saturés, voire hors service, il peut être intéressant
d’utiliser une autre route. Ces passerelles utilisent donc des tables de routage dynamiques, qui sont
automatiquement mises à jour en fonction de l’état du réseau. Bien que Linux puisse parfaitement
effectuer ce type de routage, c’est une configuration réservée à un usage spécifique de Linux. Ce
document ne traitera donc pas du routage dynamique.

Figure 9-5. Notion de route

Le problème des adresses IP est qu’elles ne sont pas très parlantes pour les êtres humains : que peut donc

273
 Chapitre 9. Configuration du réseau

signifier [Link] ? Pas grand chose... C’est pour cela qu’on affecte des noms de machines plus
humains, comme par exemple [Link]. Ces noms suivent une convention de
nommage bien précise. En général, le premier nom est le nom de la machine elle-même, et la suite du
nom constitue ce qu’on appelle le domaine dans laquelle la machine se trouve. Ainsi, dans l’exemple
précédent, krypton est le nom d’une machine, et [Link] est le nom de son domaine. En
général, il existe plusieurs machines dans un même domaine, on pourrait donc également avoir
[Link] par exemple (malheureusement pour mon exemple, l’étoile Altaïr ne se
trouve pas dans la galaxie d’Andromède, mais bon...). Souvent, les noms de domaines sont des noms de
sociétés. La dernière partie du nom de domaine permet également de déterminer la nature du domaine,
ou sa localisation. Par exemple, l’extension .com indique clairement que le domaine est de nature
commerciale (de surcroît, il s’agit sans doute d’une société américaine, l’extension .com étant réservée
aux États-Unis). De même, l’extension .gov est utilisée pour les organismes gouvernementaux
américains, et l’extension .edu pour les universités ou les écoles américaines. L’extension .org est
utilisée pour les organisations non commerciales. Enfin, les noms de domaines des autres pays que les
États-Unis utilisent quasiment systématiquement une extension indiquant leurs pays d’origine. Ainsi,
.fr représente la France, .uk les Royaumes-Unis, etc. Notez que la notion de domaine est a priori
distincte de la notion de réseau.
La question technique qui se pose avec ces conventions de nommage « humaines » est de savoir
comment déterminer, à partir d’un nom littéral, l’adresse IP de la machine correspondante. Cette
opération n’est pas simple, et en fait elle est effectuée de deux manières :

• soit la machine locale demande à une autre machine qu’elle connaît d’effectuer la recherche de
l’adresse du correspondant ;
• soit elle dispose d’une liste de noms et d’adresses lui permettant de déterminer directement les
adresses de ses interlocuteurs.
La première solution utilise ce qu’on appelle un serveur de noms (« DNS » en anglais, abréviation de
« Domain Name Service »), qui connaît toutes les machines du réseau soit directement, soit
indirectement (donc via un autre DNS). L’opération qui consiste à retrouver l’adresse IP d’une machine à
partir de son nom s’appelle la résolution de nom de domaine. Il est évident que si le serveur de noms ne
peut être contacté, il sera impossible d’utiliser les noms de machines. En revanche, il sera toujours
possible d’utiliser leurs adresses IP directement, si on les connaît. La deuxième solution ne souffre pas
de ce défaut, elle nécessite cependant de mettre à jour la liste des noms sur tous les postes régulièrement,
ce qui est beaucoup plus complexe que la gestion centralisée d’un DNS. On ne l’utilisera donc que pour
les petits réseaux.

Le protocole TCP
Nous avons vu que le protocole IP fournit les briques de bases de toute la communication réseau sous
Unix (et Internet). Ses principales fonctionnalités sont le découpage des informations en paquets de taille
suffisamment petite pour pouvoir transiter sur tous les types de réseaux physiques, la gestion des
destinations des paquets à l’aide des adresses IP, et le choix de la route permettant d’acheminer les
paquets à destination. En revanche, il est incapable d’assurer les services plus évolués comme la gestion
de l’ordre d’arrivée des paquets et la gestion de la fiabilité du transfert des informations. C’est donc à des
protocoles plus évolués, eux-mêmes encapsulés dans IP, d’effectuer ces tâches. L’un des protocoles les
plus importants est le protocole TCP (abréviation de l’anglais « Transfer Control Protocol »). Ce

274
 Chapitre 9. Configuration du réseau

protocole se charge d’établir les connexions entre deux ordinateurs, et assure la fiabilité des informations
transmises et l’arrivée des informations dans leur ordre d’envoi. Il existe d’autres protocoles, moins
connus que TCP mais tout aussi importants. On retiendra en particulier les deux protocoles suivants :

• UDP (abréviation de l’anglais « User Datagram Protocol »), qui permet d’émettre des datagrammes
sur le réseau, qui sont de simples paquets de données (c’est un protocole semblable à IP, destiné aux
applications) ;
• ICMP (abréviation de « Internet Control Message Protocol »), qui est utilisé essentiellement pour
transmettre des messages de contrôle du fonctionnement des autres protocoles (il est donc vital).

Les services réseau des machines sont organisés en couches logicielles, qui s’appuient chacune sur la
couche inférieure. Ainsi, TCP utilise IP, qui lui-même utilise le pilote qui gère l’interface réseau. Du fait
que ces couches s’appuient les unes sur les autres, on appelle souvent l’ensemble de ces couches une pile
(« stack » en anglais). Vous avez peut-être déjà entendu parler de la pile TCP/IP. Lorsqu’un service
réseau d’une machine n’est plus accessible, il se peut que ce service réseau ait planté. Si tout un
ensemble de services réseau ne fonctionne plus, c’est certainement une des couches logicielles qui est
plantée. Par exemple, une machine peut répondre à la commande ping (classiquement utilisée pour tester
les connexions réseau) et ne plus accepter la plupart des connexions réseau. Cela signifie simplement que
la couche TCP ne fonctionne plus, et que la couche ICMP (utilisée par ping) est toujours valide.
Évidemment, si la couche IP tombe en panne, la machine ne sera plus accessible du tout, sauf
éventuellement avec d’autres protocoles réseau complètement différents (IPX, Appletalk, etc.).
Seuls les mécanismes du protocole TCP seront détaillés dans la suite de ce document. Le protocole TCP
est en effet utilisé par un grand nombre de services, ce qui en fait certainement le plus connu.
Le protocole TCP utilise la notion de connexion. Une connexion est un canal de communication établi
entre deux processus par TCP. Comme les processus sont susceptibles d’utiliser plusieurs connexions
simultanément, TCP fournit la possibilité de les identifier par un numéro unique sur la machine, compris
entre 0 et 65535. Chaque numéro identifie ce qu’on appelle un port TCP. Quand un processus désire
établir une connexion avec un autre, il utilise un de ses ports et essaie de se connecter sur le port du
deuxième processus.
Il faut bien comprendre que les deux numéros de ports utilisés ne sont a priori pas les mêmes pour les
deux processus. Évidemment, il est nécessaire que les processus clients connaissent les numéros de port
des processus serveurs auxquels ils se connectent. Les numéros de ports sont donc affectés à des services
bien définis, et les serveurs qui fournissent ces services doivent bien entendu utiliser ces numéros de
ports. Ainsi, il est possible de déterminer de manière unique un programme serveur sur un réseau avec
l’adresse IP de la machine sur laquelle il fonctionne et le numéro de port qu’il écoute pour les
connexions extérieures. Les clients qui se connectent savent donc parfaitement à quel service ils accèdent
lorsqu’ils choisissent le numéro de port destination. Leur propre numéro de port est en général choisi par
le système, afin d’éviter tout conflit avec un autre processus de la même machine.

275
 Chapitre 9. Configuration du réseau

Figure 9-6. Connexions TCP

Une fois établie, une connexion TCP permet d’effectuer des communications bidirectionnelles. Cela
signifie que le client et le serveur peuvent tous deux utiliser cette connexion pour envoyer des données à
l’autre. Le client envoie ses données sur le port destination du serveur, et le serveur peut renvoyer les
résultats au client en utilisant le port de celui-ci. Les paquets TCP disposent donc toujours d’un port
source (c’est-à-dire le port TCP de l’émetteur), et d’un port destination (le port du récepteur). Ainsi, le
récepteur peut renvoyer sa réponse en utilisant le port source comme port de destination du paquet
renvoyé, et inversement.
Comme il l’a déjà été dit, le protocole TCP s’assure que les informations transmises arrivent à bon port
(c’est le cas de le dire !). Pour cela, il utilise un mécanisme d’accusés réception, qui indiquent à
l’émetteur si le destinataire a bien reçu chaque paquet envoyé. Si l’accusé réception n’est pas reçu dans
un temps fixé, le paquet est ré-émis. Un paquet reçu en double à cause d’un retard dans la
communication de l’accusé réception est tout simplement ignoré. La fiabilité des informations est
également assurée. Cette fiabilité est réalisée par un mécanisme de sommes de contrôle. Si le récepteur
constate que la somme de contrôle des données reçues n’est pas celle que l’émetteur a calculé, il rejette
le paquet parce qu’il sait que les informations ont été corrompues pendant la transmission. Enfin, TCP
s’assure que les informations émises en plusieurs passes sont bien reçues dans leur ordre d’émission.
Cette réorganisation se fait grâce à une numérotation des paquets (cette numérotation sert également à
détecter les paquets reçus en double). Elle peut paraître inutile, mais la vitesse d’arrivée des paquets est
hautement dépendante de la route IP qu’ils prennent pour parvenir à destination. Les paquets qui arrivent
en avance sont donc mémorisés jusqu’à ce que tous les paquets qui les précèdent soient reçus.

Les protocoles de haut niveau

TCP fournit donc les fonctionnalités requises pour la plupart des services réseau existant. Il est logique
que ceux-ci s’appuient sur lui pour effectuer leur travail. Cependant, il ne se charge que de communiquer
les informations, rien de plus. Des protocoles de plus haut niveau ont donc été créés. Leur valeur ajoutée
provient souvent du formatage et de la structuration des flux de données échangés.
La plupart des services réseau définissent donc un protocole qui leur est propre. Il est d’ailleurs assez
courant de confondre le service et le protocole, tellement ils sont intrinsèquement liés. Ainsi, le service
FTP utilise le protocole FTP (« File Transfer Protocol », protocole de transfert de fichiers), les serveurs
Internet utilisent essentiellement le protocole HTTP (« Hyper Text Transfer Protocol », protocole de
transfert d’hypertexte), le service de courrier électronique utilise les protocoles POP (« Post Office
Protocol ») pour la réception des courriers et SMTP (« Simple Mail Transfer Protocol ») pour leur envoi.
Cette liste de protocoles n’est pas exhaustive, et de nouveaux services apparaissent régulièrement. Les
protocoles de haut niveau ne seront donc pas décrits dans ce document.

276
 Chapitre 9. Configuration du réseau

Les protocoles de haut niveau transmettent, en général, toutes leurs données en clair sur le réseau. Cela
comprend non seulement les données applicatives, mais également les noms d’utilisateurs et les mots de
passe. Toute personne ayant physiquement accès au réseau ou à une machine par laquelle les paquets
passent peut donc, s’il le désire, récupérer tous les mots de passe avec une simplicité extrême (il existe
même des programmes spécialisés pour cela). Il est donc inconcevable d’utiliser tous ces protocoles sans
prendre de précautions particulières. Heureusement, il est possible d’encapsuler les protocoles dans un
réseau virtuel qui, lui, transmet les données sous forme chiffrée. L’outil le plus utilisé de nos jours est ssh
(abréviation de l’anglais « Secure SHell »), qui permet de se connecter sur une machine et de travailler à
distance en toute sécurité. Il en existe plusieurs implémentations, dont au moins une libre : OpenSSH.
Nous verrons comment configurer et utiliser OpenSSH pour améliorer la sécurité du réseau dans la la
section intitulée Utilisation de SSH.

Configuration du réseau sous Linux

La configuration du réseau nécessite donc la configuration du protocole IP et des services TCP, UDP et
ICMP (entre autres). Cette opération se fait en définissant l’adresse IP le masque de sous-réseau et les
routes à utiliser. Vient ensuite la configuration du nom de la machine locale, de son domaine, des noms
de machines qu’elle peut résoudre elle-même et des serveurs de DNS qu’elle doit utiliser pour les autres
noms.
Il est quasiment certain que votre distribution dispose d’un outil permettant d’effectuer la configuration
du réseau simplement. Connaissant à présent la signification des termes utilisés dans les réseaux TCP/IP,
vous devriez pouvoir parvenir à une configuration valide relativement simplement. Il est fortement
recommandé de consulter la documentation de votre distribution. Les commandes de configuration du
réseau sont souvent appelées dans les scripts de démarrage de la machine, ou dans les scripts de
changement de niveau d’exécution. Toutefois, il peut être utile de connaître ces commandes, ne serait-ce
que pour comprendre comment votre système fonctionne. Cette section a donc pour but de vous présenter
ces commandes, ainsi que les principaux fichiers de configuration du réseau utilisés sous Linux.

Configuration statique des interfaces réseau

La principale commande permettant de configurer le réseau est la commande ifconfig. Comme son nom
l’indique (« InterFace CONFiguration »), elle permet de configurer les interfaces réseau de la machine. Il
faut savoir qu’il existe plusieurs types d’interfaces réseau. Les plus courants sont les trois types
d’interfaces suivants :

• l’interface loopback, qui représente le réseau virtuel de la machine, et qui permet aux applications
réseau d’une même machine de communiquer entre elles même si l’on ne dispose pas de carte réseau ;
• les interfaces des cartes réseau (que ce soient des cartes Ethernet, TokenRing ou autres) ;
• les interfaces ppp, plip ou slip, qui sont des interfaces permettant d’utiliser les connexions sérielles,
parallèles ou téléphoniques comme des réseaux.

277
 Chapitre 9. Configuration du réseau

La configuration d’une interface comprend l’initialisation des pilotes nécessaires à son fonctionnement et
l’affectation d’une adresse IP à cette interface. La syntaxe générale que vous devrez utiliser est la
suivante :

ifconfig interface adresse netmask masque up

où interface est le nom de l’interface réseau que vous voulez configurer, adresse est l’adresse IP que
cette interface gérera, et masque est le masque de sous-réseau que vous utilisez. Les interfaces que vous
aurez à configurer seront certainement des interfaces Ethernet, auquel cas vous devrez utiliser les noms
eth0, eth1, etc. dans la commande ifconfig. Si vous désirez configurer l’interface loopback, vous
devrez utiliser le nom d’interface lo.
Le paramètre up donné à ifconfig lui indique que l’interface doit être activée. Cela signifie que dès que la
commande ifconfig s’achèvera, votre interface réseau sera active et fonctionnelle. On ne peut faire plus
simple... Bien entendu, il existe le paramètre inverse : down. Ce paramètre s’utilise tout simplement dans
la commande ifconfig avec la syntaxe suivante :

ifconfig interface down

où interface est toujours le nom de l’interface.

Un exemple de configuration très classique est le suivant :

ifconfig eth0 [Link] netmask [Link] up

Note : Prenez bien garde, lorsque vous écrivez vos adresses IP, à ne pas rajouter de 0
supplémentaire devant les nombres qui la constituent. En effet, il existe une convention en
informatique qui dit que les nombres préfixés d’un 0 sont codés en octal, c’est-à-dire en base 8. Il va
de soi qu’une adresse IP codée en octal n’utilise pas les mêmes nombres que lorsqu’elle est
exprimée en décimal, aussi éprouveriez-vous quelques difficultés pour diagnostiquer le non
fonctionnement de votre réseau si vous faisiez cette erreur !

Le noyau utilisera par défaut le nombre 255 pour les adresses de broadcast dans les composantes de
l’adresse IP qui ne fait pas partie de l’adresse de sous-réseau. Si vous désirez utiliser une autre adresse
(en général, l’alternative est de prendre l’adresse du sous-réseau), vous devrez utiliser l’option
broadcast adresse dans la commande ifconfig. Cependant, le comportement par défaut convient à la
plupart des réseaux. La commande de configuration donnée en exemple ci-dessus sera alors :

ifconfig eth0 [Link] netmask [Link] broadcast [Link] up

Enfin, il est possible d’affecter plusieurs adresses IP à certaines interfaces réseau. C’est en particulier le
cas pour toutes les interfaces réseau classiques, mais bien entendu cela n’est pas réalisable avec les
interfaces de type point à point comme les interfaces des connexions ppp. Lorsqu’une interface dispose
de plusieurs adresses, la première est considérée comme l’adresse principale de l’interface, et les
suivantes comme des alias. Ces alias utilisent comme nom le nom de l’interface réseau principale et le
numéro de l’alias, séparés par deux points (caractère ’:’). Par exemple, si l’interface eth0 dispose d’un

278
 Chapitre 9. Configuration du réseau

alias, celui-ci sera nommé eth0:0. Ainsi, pour fixer l’adresse d’un alias d’une interface réseau, on
utilisera la syntaxe suivante :

ifconfig interface:numéro add adresse netmask masque

où interface est toujours le nom de l’interface, numéro est le numéro de l’alias, adresse est
l’adresse IP à attribuer à cet alias, et masque est le masque de sous-réseau de cette adresse.
La commande ifconfig est en général appelée dans les scripts d’initialisation du système, qui ont été
générés par l’utilitaire de configuration réseau de votre distribution. Si vous effectuez un grep sur
« ifconfig » dans le répertoire /etc/rc.d/ (ou /sbin/init.d/, selon votre distribution), vous
trouverez la commande de démarrage du réseau. Il se peut qu’une variable d’environnement soit utilisée
à la place de l’adresse IP que vous avez choisie. Quoi qu’il en soit, vous devez sans aucun doute avoir les
lignes suivantes, qui permettent l’initialisation de l’interface loopback :

ifconfig lo [Link] netmask [Link] up

Définition des règles de routage

La deuxième étape dans la configuration du réseau est la définition des règles de routage. Il est possible
de définir plusieurs règles de routage actives simultanément. L’ensemble de ces règles constitue ce qu’on
appelle la table de routage. La règle utilisée est sélectionnée par le noyau en fonction de l’adresse
destination du paquet à router. Chaque règle indique donc un critère de sélection sur les adresses, et
l’interface vers laquelle doivent être transférés les paquets dont l’adresse destination vérifie cette règle.
La commande utilisée pour définir une route est, chose surprenante, la commande système route. Sa
syntaxe est donnée ci-dessous :

route opération [-net | -host] adresse netmask masque interface

où opération est l’opération à effectuer sur la table de routage. L’opération la plus courante est
simplement l’ajout d’une règle de routage, auquel cas add doit être utilisé. L’option suivante permet
d’indiquer si le critère de sélection des paquets se fait sur l’adresse du réseau destination ou plus
restrictivement sur l’adresse de la machine destination. En général, il est courant d’utiliser la sélection de
toutes les adresses d’un même réseau et de les router vers une même interface. Dans tous les cas,
adresse est l’adresse IP de la destination, que celle-ci soit un réseau ou une machine. Si la destination
est un réseau, il faut indiquer le masque de sous-réseau masque à l’aide de l’option netmask. Enfin,
interface est l’interface réseau vers laquelle doivent être envoyés les paquets qui vérifient les critères
de sélection de cette règle.
Par exemple, la règle de routage à utiliser pour l’interface loopback est la suivante :

route add -net [Link] netmask [Link] lo

Cette règle signifie que tous les paquets dont l’adresse de destination appartient au sous-réseau de classe
A [Link] doivent être transférés vers l’interface loopback. Cela implique en particulier que les paquets

279
 Chapitre 9. Configuration du réseau

à destination de la machine d’adresse IP [Link] (c’est-à-dire la machine locale) seront envoyés vers
l’interface loopback (ils reviendront donc sur la machine locale).
Une autre règle de routage classique est la suivante :

route add -net [Link] netmask [Link] eth0

Elle permet d’envoyer tous les paquets à destination du réseau de classe C [Link] vers la première
interface Ethernet. C’est typiquement ce genre de règle qu’il faut utiliser pour faire fonctionner un réseau
local.
Il n’est normalement pas nécessaire d’ajouter les règles de routage pour les réseaux auxquel la machine
est connectée. En effet, la configuration d’une carte réseau à l’aide de la commande ifconfig ajoute
automatiquement à la table de routage une règle pour envoyer les paquets à destination de ce réseau par
l’interface réseau qui y est connectée. Cependant, la commande route devient réellement nécessaire
lorsqu’il faut définir les passerelles à utiliser pour l’envoi des paquets destinés à une machine à laquelle
la machine locale ne peut accéder directement. Les règles de routage faisant intervenir une passerelle
sont semblables aux règles de routage vues ci-dessus, à ceci près que l’adresse IP de la passerelle à
utiliser doit être fournie. Pour cela, on utilise l’option gw (abréviation de l’anglais « Gateway »). La
syntaxe utilisée est donc la suivante :

route add [-net | -host] adresse netmask masque gw passerelle interface

où passerelle est l’adresse IP de la passerelle à utiliser pour router les paquets qui vérifient les critères
de cette règle. Les autres paramètres sont les mêmes que pour les règles de routage classique.
Par exemple, supposons qu’une machine soit connectée à un réseau d’adresse [Link], et que sur ce
réseau se trouve une passerelle d’adresse [Link] permettant d’atteindre un autre réseau, dont
l’adresse est [Link]. Une machine du réseau [Link] aura typiquement les règles de routage
suivantes :

route add -net [Link] netmask [Link] eth0

route add -net [Link] netmask [Link] gw [Link] eth0

La première règle permet, comme on l’a déjà vu, de communiquer avec toutes les machines du réseau
local. La deuxième règle permet d’envoyer à la passerelle [Link] tous les paquets à destination du
réseau [Link].
Inversement, si la passerelle utilise l’adresse [Link] sur le réseau [Link], les machines de ce
réseau qui voudront accéder au réseau [Link] devront spécifier la règle de routage suivante :

route add -net [Link] netmask [Link] gw [Link] eth0

Bien entendu, il est nécessaire que toutes les machines des deux réseaux utilisent ces règles de routage
pour que la communication entre les deux réseaux se fasse dans les deux sens.
Le problème de ces règles de routage est qu’elles spécifient l’adresse du réseau destination. Il est
évidement hors de question d’utiliser une règle de routage différente pour toutes les adresses de réseaux

280
 Chapitre 9. Configuration du réseau

possibles. Il est donc possible de définir ce qu’on appelle une passerelle par défaut, qui n’est rien d’autre
que la passerelle vers laquelle doivent être envoyés tous les paquets qui n’ont pas vérifié les critères des
autres règle de routage. La syntaxe à utiliser pour définir la passerelle par défaut est plus simple,
puisqu’il n’est plus nécessaire de préciser les critères de sélection :

route add default gw passerelle interface

où la signification des paramètres passerelle et interface est inchangée.

Ainsi, pour reprendre l’exemple précédent, supposons que la machine [Link] dispose d’une
connexion à Internet et soit configurée pour partager cette connexion avec les machines du réseau local.
Pour que toutes les machines du réseau local puisse profiter de cette connexion, il suffit de demander à ce
que tous les paquets qui ne vérifient aucune autre règle de routage soient envoyés à la passerelle
[Link]. Cela se fait avec la règle de routage suivante :

route add default gw [Link] eth0

Définition du nom de la machine

La configuration du nom d’un ordinateur n’est pas à proprement parler une opération indispensable, mais
elle permet de le nommer de manière plus conviviale qu’en utilisant son adresse IP. La commande de
base permettant de manipuler le nom de la machine locale est la commande hostname. Appelée telle
quelle, elle renvoie le nom actuel de la machine :

hostname

Cette commande permet également de modifier ce nom, simplement avec la syntaxe suivante :

hostname nom

où nom est le nom à utiliser. Il est d’usage de n’utiliser que le nom de la machine, sans son domaine. Le
nom de domaine est déterminé automatiquement par le système à partir des informations issues de la
configuration de la résolution des noms de domaine. Nous verrons cela dans le paragraphe suivant.
Cette commande est donc très simple à utiliser, et elle est en général appelée dans les scripts de
démarrage du système. La plupart des distributions utilisent le fichier /etc/HOSTNAME pour stocker le
nom de la machine. Vous êtes bien entendu libre de choisir le nom que vous voulez pour votre ordinateur,
mais vous devez vous assurer que ce nom est unique dans votre domaine !

Résolution des noms de domaine

La commande hostname ne permet de fixer que le nom de la machine locale. Pour les autres machines
du réseau, il faut mettre en place les mécanismes de résolution de noms de domaine. Comme il l’a déjà
été indiqué au début de ce chapitre, il existe deux solutions pour trouver l’adresse IP d’une machine à

281
 Chapitre 9. Configuration du réseau

partir de son nom : la consultation d’une liste de noms stockée en local, soit l’interrogation d’un serveur
de noms de domaine.
Le fichier /etc/[Link] permet de définir le comportement du système lors de la résolution d’un
nom. Sa structure est très simple, puisqu’il y a une option de recherche par ligne. Dans la plupart des cas,
les lignes suivantes sont suffisantes :

order hosts,bind
multi on

Elles permettent d’indiquer que la recherche des noms pour leur résolution doit se faire d’abord
localement, puis par appel aux DNS si la recherche précédente a échoué. C’est en général le
comportement désiré. La deuxième ligne permet de faire en sorte que toutes les adresses correspondant à
une machine soient renvoyées. Si l’on avait utilisé l’option multi off, seule la première adresse IP
trouvée aurait été renvoyée.
La liste de noms locale est stockée dans le fichier /etc/hosts (cela explique le nom hosts utilisé pour
l’option order dans le fichier /etc/[Link]). Votre ordinateur connaîtra directement l’adresse IP
de toutes les machines référencées dans ce fichier. Il est bon de placer ici une entrée pour les ordinateurs
les plus couramment utilisés sur le réseau. Chaque entrée commence par une adresse IP, et est suivie de
la liste des noms de la machine possédant cette adresse, séparés par des espaces. Pour ceux qui ne
disposent pas de réseau local, ce fichier doit être relativement simple : seule la ligne affectant l’adresse
[Link] à la machine locale (appelée « localhost ») doit s’y trouver.

[Link] localhost

De la même manière, le fichier /etc/networks contient les adresses des réseaux. Ce fichier est utilisé
par la commande route pour donner un nom aux différents réseaux. Chaque entrée est constituée du nom
du réseau, suivi de son adresse IP. Encore une fois, ce fichier se réduit à sa plus simple expression pour
ceux qui n’ont pas de réseau local, puisqu’il ne contiendra tout au plus qu’une entrée pour le réseau
« loopback », sur lequel se trouve l’adresse de retour [Link]. Cette entrée aura donc la forme
suivante :

loopback [Link]

La configuration des serveurs de noms est en revanche une opération nécessaire si l’on désire accéder à
des machines dont on ne connaît que le nom. Le fichier de configuration utilisé est cette fois le fichier
/etc/[Link]. Sa structure est encore une fois très simple, avec une option par ligne, chaque
option étant introduite par un mot clé.
Le mot clé domain permet d’indiquer le nom du domaine dont fait partie votre machine. Par exemple, si
votre nom de domaine est « [Link] », vous devrez utiliser la ligne suivante :

domain [Link]

282
 Chapitre 9. Configuration du réseau

Le mot clé search permet quant à lui de spécifier une liste de noms de domaines à ajouter par défaut
aux noms de machines non complètement qualifiés. Les éléments de cette liste doivent être séparés par
des espaces. La recherche d’une machine dont le nom ne comprend pas la partie de nom de domaine
s’effectue en ajoutant au nom de la machine les noms des domaines indiqués ici, jusqu’à ce que la
résolution du nom en adresse IP réussisse. Cette recherche commence bien entendu par le nom de
domaine local, s’il a été défini. Il est donc recommandé d’indiquer votre nom de domaine dans cette liste
de noms de domaines. Par exemple, si votre machine fait partie du domaine « [Link] », vous
devrez utiliser la ligne suivante :

search [Link]

Ainsi, si vous recherchez l’adresse de la machine « krypton », la requête au DNS se fera avec le nom
complètement qualifié « [Link] ». Vous êtes bien entendu libre d’ajouter d’autres
noms de domaines pour le cas où la résolution de nom échouerait sur ce domaine.
Enfin, l’option nameserver est essentielle, puisqu’elle permet de donner les adresses IP des serveurs de
DNS auxquels doivent être adressées les requêtes de résolution de noms. Par exemple, si vous disposez
de deux serveurs DNS, un primaire, d’adresse [Link], et un secondaire, d’adresse [Link],
vous utiliserez la ligne suivante :

nameserver [Link] [Link]

Cette ligne est évidemment obligatoire, faute de quoi la résolution des noms de machines en adresse IP
échouera pour toute machine qui ne se trouve pas dans votre fichier /etc/hosts.

Utilisation des protocoles DHCP et BOOTP

Généralement, la gestion des adresses IP des machines devient rapidement une tâche difficile sur les
grands réseaux, pour trois raisons. Premièrement, il faut toujours s’assurer que chaque machine dispose
bien d’une adresse qui lui est propre, ce qui peut être difficile si l’on ne s’organise pas en conséquence.
Deuxièmement, il faut que les fichiers /etc/hosts de toutes les machines soient à jour, ce qui nécessite
un travail proportionnel au nombre de machines administrées. Enfin, le nombre d’adresses IP disponibles
peut se réduire, ce qui peut devenir gênant à terme.
Afin de résoudre ces problèmes de configuration réseau, le protocole DHCP (abréviation de l’anglais
« Dynamic Host Configuration Protocol ») a été défini. Il s’agit d’un protocole qui permet aux machines
connectées sur un réseau d’interroger un « serveur d’adresses » du réseau capable de gérer une liste
d’adresses et de les affecter dynamiquement aux machines du réseau. En fait, ce protocole permet de
fournir plus d’informations que les simples adresses IP, comme par exemple la route par défaut que les
machines doivent utiliser, ainsi que les adresses des serveurs de noms du réseau.
Un autre protocole semblable à DHCP a également été développé dans le but de permettre la
configuration réseau des machines dès leur démarrage : le protocole BOOTP (abréviation de l’anglais
« BOOTstrap Protocol »). Ce protocole est évidemment plus léger que DHCP, mais permet aux machines
d’obtenir dynamiquement leur configuration réseau dès leur démarrage, avant même que ne soient

283
 Chapitre 9. Configuration du réseau

montés les systèmes de fichiers. Ce protocole est donc particulièrement utile pour faire démarrer des
machines sans disque, pour lesquelles le système de fichiers racine est monté en NFS.
La manière la plus simple de configurer les protocoles DHCP et BOOTP sur un poste client est d’utiliser
les fonctionnalités d’auto-configuration du noyau. Cependant, il est également possible d’effectuer cette
configuration au niveau utilisateur à l’aide de programmes complémentaires. Les deux sections suivantes
décrivent ces deux techniques.

Autoconfiguration des clients DHCP et BOOTP

La configuration des protocoles DHCP et BOOTP ne comporte aucune difficulté particulière lorsque l’on
utilise les fonctionnalités d’autoconfiguration du noyau. Ces fonctionnalités étant prises en charge au
niveau du noyau, il va vous falloir recompiler un nouveau noyau pour en bénéficier. Cette opération en
revanche est relativement technique, et doit être faite avec soin. La manière de procéder a été décrite en
détail dans la la section intitulée Compilation du noyau Linux dans Chapitre 7.
L’option à activer pour permettre l’utilisation du protocole BOOTP est l’option « IP: kernel level
autoconfiguration » du menu « Networking options ». Cette option vous permettra de sélectionner
le protocole d’auto-configuration réseau que le noyau devra utiliser lors de son amorçage. Vous devrez
alors choisir l’option « IP: DHCP support (NEW) » ou l’option « IP: BOOTP support (NEW) »
pour activer respectivement les protocoles DHCP et BOOTP.

Note : Vous remarquerez qu’il existe également un autre protocole d’auto-configuration du réseau
au démarrage : le protocole RARP. Ce protocole fournit les mêmes services que le protocole
BOOTP, mais est plus ancien. Il n’est donc plus conseillé de l’utiliser, sauf vous vous trouvez sur un
réseau pour lequel seul le protocole RARP est disponible.

Une fois ces options sélectionnées, vous pourrez recompiler votre noyau, l’installer et redémarrer la
machine. Lors du démarrage, le noyau doit chercher un serveur DHCP ou un serveur BOOTP sur le
réseau local pour effectuer la configuration réseau de votre carte réseau.

Note : Vous devrez peut-être également activer les options « NFS file system support » et
« Root file system on NFS » du menu « Network File Systems » si vous désirez faire démarrer
votre machine sur un système de fichiers racine monté en NFS lors du démarrage.

Configuration d’un client DHCP au niveau utilisateur

Il est également possible de configurer les clients DHCP au niveau utilisateur, à l’aide de programmes
complémentaires. Comme sur la plupart des machines Unix, le programme à utiliser est le programme
dhclient. Ce programme est généralement lancé dans les scripts de démarrage des machines, et envoie
des paquets de demande de configuration sur le réseau à l’adresse de diffusion générale [Link].
Ces paquets sont donc susceptibles d’être captées par toutes les machines du réseau, mais seuls les
serveurs DHCP y répondent. Les réponses obtenues sont alors analysés par dhclient, qui configure en
conséquence l’interface réseau et passe ensuite en arrière-plan.

284
 Chapitre 9. Configuration du réseau

Les informations envoyées par les serveurs DHCP peuvent être plus ou moins complètes, la base étant
bien sûr l’adresse IP de la machine et son masque de sous-réseau. Il est toutefois possible de donner plus
d’informations, comme par exemple les adresses des serveurs de noms, des routes par défaut et des
passerelles à utiliser.
Les adresses IP attribuées aux clients ne sont pas permanentes, car le protocole DHCP est avant tout
destiné à la configuration automatique des postes itinérants ou susceptibles de redémarrer souvent. Par
conséquent, ces adresses sont fournies dans le cadre d’un bail, dont la durée maximum est fixée par le
serveur. Dès que le bail obtenu par un client expire, celui-ci doit chercher à le renouveler. C’est encore le
programme dhclient qui s’en charge. C’est la raison pour laquelle celui-ci passe en arrière-plan après
avoir configuré l’interface pour la première fois : il attend la fin des baux de la machine sur laquelle il
tourne et cherche à les renouveler. Si un client ne renouvelle pas ce bail (parce qu’il est arrêté par
exemple), le serveur DHCP peut réutiliser son adresse IP et l’affecter à une autre machine. Bien que les
serveurs DHCP s’efforcent généralement de conserver les adresses IP des clients à chaque bail, un client
configuré par DHCP ne peut donc pas considérer que son adresse IP restera toujours la même. C’est la
contrepartie de la flexibilité.
Si aucun serveur DHCP ne peut être contacté lors du démarrage, dhclient abandonne temporairement et
réessaie au bout d’un temps aléatoire. Au bout d’un certain nombre d’essais non fructueux, il peut
décider de configurer les interfaces réseau avec les adresses IP des anciens baux obtenus par la machine.
Pour cela, il mémorise dans le fichier de configuration /var/db/[Link] les adresses IP de
ces anciens baux. Ce fichier est périodiquement réécrit avec la liste des adresses des baux valides afin
d’éviter qu’il ne se remplisse ad vitam eternam.
Bien entendu, les postes clients ne peuvent pas choisir leurs adresses IP sans vérification d’unicité. Dans
le cas de l’absence de serveur DHCP (et donc d’autorité centrale), les clients qui démarrent interrogent
les machines déjà présentes sur le réseau pour déterminer si l’adresse qu’ils envisagent de prendre est
bien libre. Dans le cas contraire, une autre adresse est essayée, et ainsi de suite. Ainsi, même en cas de
panne de tous les serveurs DHCP d’un réseau, les postes clients peuvent toujours travailler ensemble
sans conflit d’adresses IP.
Comme vous pouvez le constater, le comportement de dhclient est relativement complexe et dépend de
nombre de paramètres. Tous ces paramètres peuvent être définis dans le fichier de configuration
/etc/[Link]. Ce fichier contient en particulier les différentes durées intervenant dans le
choix des adresses IP, comme par exemple la durée minimale d’un bail, les durées entre chaque tentatives
de configuration, les informations qui doivent être récupérées des serveurs DHCP, ainsi que les valeurs
par défaut pour ces informations lorsque les serveurs ne les fournissent pas. Le fichier de configuration
[Link] est donc relativement complexe. Heureusement, dhclient utilise des options par défaut
qui conviennent dans la plupart des cas, aussi est-il fortement probable que votre fichier
[Link] soit vide. Si toutefois vous désirez en savoir plus, vous pouvez consulter la page de
manuel [Link].
La configuration DHCP pour les postes clients se réduit donc à l’essentiel : le lancement de dhclient.
Celui-ci s’utilise avec la syntaxe suivante :

dhclient interface0 [interface1 [...]]

où interface0, interface1, etc., sont les interfaces réseau qui doivent être configurées par DHCP.
On ne peut donc pas faire plus simple...

285
 Chapitre 9. Configuration du réseau

Note : Sous Linux, le programme dhclient utilise les fonctionnalité d’accès direct aux cartes réseau
et de filtrage des paquets. Ces deux fonctionnalités peuvent être activées dans la configuration du
noyau à l’aide des options « Packet socket », « Packet socket: mmapped IO » et « Socket
Filtering » du menu « Networking options ». L’option « IP: multicasting » de la liste des options
du protocole IP devra également être activée. Le détail de la configuration et de la compilation du
noyau a été vu dans la la section intitulée Compilation du noyau Linux dans Chapitre 7.
Le programme dhclient est assez facétieux depuis quelques versions. S’il refuse obstinément de
fonctionner, vous devrez sans doute vous rabattre vers le programme dhcpcd, beaucoup plus
simple, mais également beaucoup plus fiable. La plupart des distributions utilisent de dernier en lieu
et place de dhclient. Consultez la documentation de votre distribution pour déterminer la solution
qu’elle utilise.

Définition des protocoles de haut niveau

Comme nous l’avons vu plus haut, le protocole IP fournit les mécanismes de base pour la transmission
des paquets. Plusieurs protocoles de plus haut niveau ont été définis pour fournir des services à valeur
ajoutée, qui satisfont donc plus aux besoins des applications. Tous ces protocoles sont encapsulés dans le
protocole IP, ce qui signifie que leurs informations sont transmises en tant que données dans les paquets
IP.
En réalité, les paquets du protocole IP contiennent un champ permettant de signaler le type de protocole
de haut niveau dont ils transportent les informations. À chaque protocole est donc attribué un
identificateur numérique qui lui est propre, et qui permet aux services réseau d’interpréter les données
des paquets.
Tout comme les adresses IP, ces numéros identifiant les protocoles ne sont pas très intéressants pour les
humains, qui leur préfère évidemment le nom du protocole. Certains programmes réseau utilisent donc
ces noms pour identifier les protocoles. Pour leur permettre de faire l’association entre ces noms et les
identificateurs numériques, le fichier /etc/protocols est utilisé.
Le format de ce fichier est très simple. Il contient une ligne pour chaque protocole, constituée du nom du
protocole, de la valeur de son identificateur, et des autres noms que ce protocole peut avoir (c’est-à-dire
ses alias). Parmi ces protocoles, les plus importants sont les suivants :

Nom Numéro Alias

ip 0 IP
icmp 1 ICMP
tcp 6 TCP
udp 17 UDP

Comme on le voit, le protocole IP dispose lui-même d’un identificateur de protocole (qui vaut 0 en
l’occurrence). Cet identificateur est un identificateur de « pseudo protocole », parce qu’IP est en fait le
protocole de base. ICMP est identifié par le numéro 1, TCP par le numéro 6 et UDP par le numéro 27. Il
existe beaucoup d’autres protocoles, qui ne seront pas décrits ici. Bien entendu, le fichier

286
 Chapitre 9. Configuration du réseau

/etc/protocols fourni avec votre distribution doit déjà contenir la définition de la plupart des
protocoles.
De la même manière, la plupart des ports TCP et UDP sont affectés à des services bien définis, et certains
programmes réseau peuvent chercher à faire la correspondance entre les noms de ces services et les
numéros de ports. Cette correspondance est stockée dans le fichier de configuration /etc/services.
Les informations concernant les services sont données à raison d’une ligne par service. Chaque ligne suit
la syntaxe suivante :

nom port/protocole alias

où nom est le nom du service décrit par cette ligne, port est le numéro du port utilisé par ce service,
protocole est le nom du protocole utilisé par ce service (ce peut être « tcp » ou « udp »), et alias la
liste des autres noms sous lesquels ce service est également connu.
Vous trouverez les principaux services dans l’extrait donné ci-dessous :

Service Port/Protocole
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp
pop3 110/tcp
irc 194/tcp
irc 194/udp

Comme vous pouvez le constater, ces services n’ont pas d’alias. Ces informations sont données
uniquement à titre d’exemple. Il va de soi que le fichier /etc/services fourni avec votre distribution
contient la définition d’un grand nombre de services, et vous n’aurez en général pas à y toucher.

Les super-démons inetd et xinetd

La plupart des services réseau sont gérés par des programmes qui s’exécutent en permanence et qui
attendent des connexions sur un port TCP ou UDP. Ces programmes consomment relativement peu de
ressources car ils passent la plupart de leur temps à attendre ces connexions. Ils ne se réveillent que
lorsqu’un client se connecte effectivement et leur envoie une requête.
Cependant, ils peuvent être relativement nombreux, et si tous les services sont lancés simultanément, ils
peuvent finir par consommer une part non négligeable des ressources système. C’est pour cette raison
que les super-démons inetd (de l’anglais « InterNET Daemon ») et xinetd (de l’anglais « eXtended
INETD ») ont été créés. Ces démons sont à l’écoute des demandes de connexion des clients pour les
autres services réseau, et ne lancent ceux-ci que lorsqu’un client se connecte sur leurs ports. Une fois
lancés, les véritables démons reprennent la main et communiquent directement avec leurs clients. Ainsi,
inetd et xinetd écoutent les ports pour tout le monde, et sont la plupart du temps les seuls à fonctionner.
Les ressources système sont donc économisées et les services réseau sont démarrés et arrêtés à la
demande.

287
 Chapitre 9. Configuration du réseau

Le super-démon xinetd est appelé à remplacer inetd, qui lui est beaucoup plus ancien et nettement
moins souple. En pratique, un seul de ces super-démons doit être démarré sur une machine (il est inutile
de les lancer tous les deux, car les clients ne peuvent se connecter qu’à un seul d’entre-eux de toutes
manières). Les deux sections suivantes décrivent la configuration de ces super-démons.

Le super-démon inetd
Le super-démon inetd laisse de plus en plus la main au nouveau super-démon xinetd qui est beaucoup
plus puissant, mais reste toutefois très utilisé sur de nombreuses machines. Sa description n’est donc pas
inutile, car toutes les distributions n’utilisent pas encore xinetd.
Le super-démon inetd utilise le fichier de configuration /etc/[Link] pour déterminer les ports
sur lesquels il doit attendre des connexions de la part des clients, et pour trouver le service réseau qu’il
doit lancer lorsqu’une telle connexion arrive. Ce fichier est structuré en lignes, dont chacune décrit un
des services que le démon inetd prend en charge. Les informations données sur ces lignes sont les
suivantes :

• le nom du service (tel qu’il est défini dans la première colonne du fichier /etc/services) dont inetd
doit surveiller les requêtes ;
• le type de canal de communication réseau utilisé, en général « stream » (pour les communications en
mode connecté, donc en général celles qui utilisent le protocole TCP) ou « dgram » (pour les
communications basées sur les datagrammes, donc typiquement les communications utilisant le
protocole UDP) ;
• le protocole réseau utilisé (« tcp » ou «udp ») par ce service ;
• l’un des mots clés wait ou nowait, qui permettent d’indiquer si inetd doit attendre la fin de
l’exécution du démon gérant le service ou s’il peut attendre de nouvelles requêtes de la part des
clients ;
• le nom de l’utilisateur au nom duquel le démon gérant ce service doit fonctionner (en général, c’est
l’utilisateur root) ;
• le chemin sur le fichier exécutable de ce démon ;
• les éventuels paramètres en ligne de commande pour ce démon, en commençant par l’argument 0, qui
doit toujours être le nom du fichier exécutable du programme lui-même.

Par exemple, la ligne suivante permet de lancer le démon telnetd sur toute requête via le protocole TCP
pour le service telnet :

telnet stream tcp nowait root /usr/sbin/[Link] [Link]

Il est supposé ici que le démon en charge de ce service peut être lancé avec le programme
/usr/sbin/[Link].

Le démon inetd est capable de fournir lui-même un certain nombre de services de base, et il n’est pas
nécessaire de fournir un démon pour ces services. Dans ce cas, il faut utiliser le mot clé internal à la

288
 Chapitre 9. Configuration du réseau

place du nom du fichier exécutable du démon de ce service. Les paramètres doivent également être
remplacés par le mot clé internal.
En fait, il est fort peu probable que votre fichier de configuration /etc/[Link] définisse les
services comme indiqué dans cette section. En effet, un programme intermédiaire en charge d’assurer
des contrôles de sécurité est souvent intercalé entre inetd et les démons gérant les services. Nous verrons
ce que fait exactement ce programme dans une prochaine section.

Le super-démon xinetd
Le super-démon xinetd utilise un autre fichier de configuration que celui du super-démon inetd. Pour
xinetd, la définition des services mis à disposition des clients se fait dans le fichier de configuration
/etc/[Link]. Toutefois, contrairement au fichier [Link], le fichier [Link] peut
inclure d’autres fichiers de configuration et référencer des répertoires contenant les fichiers de
configuration spécifiques aux services. Ainsi, la configuration des services est beaucoup plus modulaire
et se fait plus facilement.
En pratique, il est d’usage de définir les options par défaut pour tous les services dans le fichier de
configuration /etc/[Link], et de décrire les différents services dans des fichiers
complémentaires stockés dans le répertoire /etc/xinetd.d/. Ce répertoire est alors inclus directement
dans le fichier [Link] à l’aide de la directive includedir dédiée à cet usage.
Les fichiers de configuration de xinetd sont constitués de sections permettant de décrire les services pris
en charge, ou tout simplement les options par défaut applicables à tous les services. La forme générale de
ces sections est la suivante :

service
{
option opérateur valeur [valeur [...]]
option opérateur valeur [valeur [...]]
...
}

où service est le nom du service (ou defaults pour les options par défaut), option est un mot-clé
identifiant une des options de ce service, et opérateur est l’un des opérateurs ’=’ (pour la définition de
la valeur d’une option ou l’écrasement de sa valeur précédente), ’+=’ (pour compléter la liste de valeurs
d’une option) ou ’-= (pour supprimer une valeur de la liste de valeurs d’une option). Les valeurs des
options peuvent être multiples, et leur nature dépend des options utilisées.
Les principales options utilisables dans ces sections sont les suivantes :

Option Signification
id Identificateur du service, pour le cas où plusieurs sections devraient être
définies pour un même service. Cette possibilité est utilisée lorsque l’on
désire fournir des options différentes pour un même service. L’entrée
choisie (et donc le jeu d’options choisi) dépend dans ce cas de critères
définis par exemple sur l’interface réseau ou sur les adresses des clients.

289
 Chapitre 9. Configuration du réseau

Option Signification
type Permet d’indiquer la nature du service décrit par cette section.
Généralement, cette option n’a pas à être donnée, sauf lorsque l’on veut
forcer la méthode d’implémentation d’un service. Par exemple, il est
possible de donner la valeur INTERNAL à cette option pour utiliser l’un des
services implémentés par xinetd en interne.
server Permet de donner le chemin sur l’exécutable du démon prenant en charge
le service décrit.
server_args Permet de donner les paramètres en ligne de commande du démon prenant
en charge le service. Notez que, contrairement à ce qui se fait avec inetd, il
ne faut généralement pas donner le nom de l’exécutable en premier
argument dans cette option. Cette règle peut toutefois être rendue fausse en
ajoutant la valeur NAMEINARGS dans l’option flags décrite ci-dessous.
socket_type Le type de canal de communication utilisé (« stream » ou « dgram »,
comme pour inetd).
protocol Le protocole réseau utilisé par le service (« tcp » ou « udp », comme pour
inetd).
port Le port sur lequel le service peut être trouvé. Cette option est facultative.
Si elle n’est pas indiquée, le numéro de port utilisé sera celui indiqué dans
le fichier de configuration /etc/services pour le service en cours de
configuration.
wait L’indicateur de capacité du démon à gérer plusieurs connexions
simultanément. Les valeurs que l’on peut donner à cette option sont
« yes » et « no », respectivement pour indiquer que le démon peut gérer
plusieurs connexions simultanément ou non. Dans ce dernier cas, le démon
xinetd lancera plusieurs instances du démon gérant le service si plusieurs
clients cherchent à se connecter simultanément. Le nombre maximum
d’instance peut toutefois être contrôlé à l’aide des options instances et
per_source décrites ci-dessous.
flags Les paramètres permettant de contrôler différents aspects du service. Les
options les plus courantes sont « IDONLY », qui permet de n’autoriser que
les connexions provenant de machines disposant d’un serveur
d’identification des clients, « NORETRY », qui permet d’éviter de réessayer
de lancer le démon du service si le lancement précédent a échoué, et
« NAMEINARGS», qui permet d’indiquer que le nom de l’exécutable doit
être spécifié en premier paramètre dans l’option server_args.
user Le compte utilisateur dans lequel le démon prenant en charge le service
doit être lancé. Cette option ne peut bien entendu pas être utilisée pour les
services gérés en interne par xinetd.
interface L’interface à laquelle le service est attaché. Cette option permet de définir
plusieurs configurations pour un même service et d’affecter ces différentes
configurations à des interfaces réseau distinctes. Pour l’heure, seul
l’adresse IP de l’interface réseau peut être spécifiée grâce à cette option, ce
qui impose d’avoir des adresses IP fixes.

290
 Chapitre 9. Configuration du réseau

Option Signification
only_from La liste des adresses des machines autorisées à se connecter. Il est possible
de spécifier les adresses IP explicitement ou à l’aide d’une adresse et d’un
masque de sous-réseau. Les noms de domaines peuvent également être
utilisés. Dans ce cas, le nom n’est pas transformé en adresse IP. Au
contraire, c’est l’adresse du client qui est retransformée en nom de
machine pour vérifier s’il a le droit de se connecter. Notez que l’absence
de ce champ indique que, par défaut, l’accès est accordé à toutes les
machines (sauf celles explicitement interdites de connexion par l’option
no_access décrite ci-dessous). En revanche, la présence de ce champ
mais sans valeur permet d’interdire l’accès à toutes les machines.
no_access La liste des adresses des machines qui n’ont pas le droit de se connecter.
Les adresses peuvent être spécifiées de la même manière que pour l’option
only_from. Si une adresse vérifie les critères des deux options
only_from et no_access, c’est l’option dont le critère est le plus précis
qui est choisie.
access_times La période pendant laquelle le service est accessible. Cette période peut
être exprimée sous la forme d’une liste d’intervalles
« heure:minute-heure:minute ».
instances Permet d’indiquer le nombre maximum d’instances d’un même démon que
xinetd peut lancer. Cette option permet donc de spécifier un nombre de
connexions maximum pour chaque service.
per_source Permet d’indiquer le nombre maximum d’instances d’un même démon que
xinetd peut lancer pour un même client (identifié par son adresse IP).
Cette option permet donc de limiter le nombre de connexions d’un client,
de manière indépendante du nombre de connexions total donné par
l’option instances.
cps Permet de limiter dans le temps le nombre de connexions entrantes pour
un service, afin d’éviter les attaques par déni de service. Cette option prend
deux paramètres, le premier étant le nombre maximum de demandes de
connexion par seconde que xinetd peut accepter. Si ce nombre est dépassé
le service est désactivé pendant le nombre de secondes indiqué par le
deuxième paramètre.
disabled Permet de désactiver globalement des services, en indiquant leurs noms en
paramètre. Par défaut, aucun service n’est désactivé. Cette option ne peut
être utilisée que dans la section defaults, car elle permet de désactiver
globalement et rapidement un ensemble de services.
enabled Permet de donner la liste des services pris en charge. Cette option
fonctionne de manière similaire à l’option disabled, à ceci près qu’elle
fonctionne en logique inverse. L’absence de cette option implique
l’activation de tous les services, sauf ceux qui sont listés dans l’option
disabled. En revanche, dès que cette option est définie, seuls les services
listés sont démarrés. Tout comme l’option disabled, cette option ne peut
être utilisée que dans la section globale defaults.

291
 Chapitre 9. Configuration du réseau

Option Signification
disable Permet de désactiver les services de manière unitaire. Cette option est
utilisée dans les sections des services, afin d’indiquer de manière plus fine
qu’avec les options enabled et disabled s’ils doivent être activés ou
non. Cette option peut prendre deux valeurs : « yes » ou « no ». La
première permet de désactiver le service et la deuxième de le garder
fonctionnel. Notez que les options enabled et disabled ont priorité
l’option disable. Ainsi, un service désactivé par l’une de ces options ne
peut pas être réactivé en attribuant la valeur no à l’option disable.
log_type Méthode d’enregistrement des événements du démon xinetd. Il est
possible d’utiliser le démon syslog pour enregistrer les événements de
connexion et de déconnexion des utilisateurs, ou directement un fichier
texte. Dans le premier cas, il faut utiliser la valeur SYSLOG suivie de la
classe d’enregistrement (généralement daemon) et du niveau de trace
(généralement info). Dans le deuxième cas, il faut spécifier la valeur
FILE et indiquer les limites basse et haute de la taille du fichier au delà
desquelles un avertissement est généré, puis les traces sont arrêtées.
log_on_success Informations enregistrées lors de l’acceptation d’une connexion. xinetd
peut enregistrer différentes informations lorsqu’une nouvelle connexion
est acceptée. Ces informations sont indiquées grâce à la liste des mots-clés
spécifiés par cette option. Les mots-clés utilisables sont « PID », pour
enregistrer l’identifiant de processus du démon qui traitera la requête,
« HOST », pour enregistrer le nom de la machine cliente, « USERID », pour
enregistrer le nom de l’utilisateur (si celui-ci peut être obtenu par le
service d’identification de sa machine), « EXIT », pour enregistrer la
terminaison du démon qui traite la requête, et « DURATION », pour
enregistrer la durée de la connexion.
log_on_failure Informations enregistrées lors d’un refus de connexion. Les informations
enregistrées lors d’un refus de connexion peuvent être spécifiées à l’aide
de cette option, de la même manière que les informations de connexion
peuvent être enregistrées à l’aide de l’option log_on_success. Les
mots-clés utilisables avec cette option sont « ATTEMPT », pour signaler
simplement que la tentative a échoué, « HOST », pour enregistrer le nom de
la machine depuis laquelle la tentative a été effectuée, et « USERID », pour
enregistrer le nom de l’utilisateur tel qu’indiqué par le service
d’identification de sa machine.

Toutes les options disponibles ne sont pas décrites dans le tableau précédent. Vous pourrez obtenir de
plus amples renseignements en consultant la page de manuel [Link].
La section « defaults » permet de définir les options par défaut applicables à tous les services. Les
options qui y sont définies peuvent toutefois être redéfinies ou précisées à l’aide des opérateurs =, += et
-= dans les sections des différents services. Les options utilisables dans la section defaults et que l’on
a vu ci-dessus sont les options bind, log_type, log_on_success, log_on_failure, instances,
per_source, only_from, no_access, disabled et enabled.

Généralement, le fichier /etc/[Link] ne contient que la section default et une ligne

292
 Chapitre 9. Configuration du réseau

d’inclusion du répertoire /etc/xinetd.d/, dans lequel se trouvent les fichiers de configuration des
différents services. L’exemple suivant présente donc un fichier [Link] typique :

# Définition des options par défaut :

defaults
{
# On interdit la connexion à tout le monde par défaut :
only_from =

# On désactive les services internes :

disabled = echo time daytime chargen discard

# On désactive les services d’administration de xinetd :

disabled += servers services xadmin

# On limite le nombre d’instances total des services :

instances = 15

# On définit les règles de suivi des connexions :

log_type = FILE /var/log/servicelog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID RECORD
}

# Inclusion des fichiers de configuration des services :

includedir /etc/xinetd.d

L’exemple suivant présente la définition du service telnet située dans le fichier de configuration
/etc/xinetd.d/telnet :

service telnet
{
socket_type = stream
# Le numéro de port et le protocole utilisés peuvent être omis
# car ils sont déjà définis dans /etc/services.

server = /usr/sbin/[Link]
user = root
wait = no
only_from = localhost
disable = no
}

Note : xinetd n’inclue pas les fichiers contenant un point (caractère ’.’) ni ceux finissant par un tilde
(caractère ’~’). En particulier, on évitera de mettre une extension aux fichiers de configuration des
services, puisque dans ce cas ils contiendraient un point et ne seraient pas lus.

293
 Chapitre 9. Configuration du réseau

Configuration de la connexion à Internet

Les connexions à Internet font partie des connexions réseau temporaires permettant de relier deux
machines. La machine locale se connecte en effet au serveur du fournisseur d’accès à Internet via la ligne
téléphonique. Bien entendu, ce serveur est considéré comme la passerelle par défaut pour tous les
paquets à destination d’Internet. Ce type de connexion a de particulier que les adresses IP des deux
machines sont, en général, déterminées dynamiquement, lors de l’établissement de la connexion. La
configuration réseau des connexions à Internet se fait donc légèrement différemment de la configuration
d’un réseau local normal. Heureusement, tous les détails de la configuration réseau sont pris en charge
automatiquement.

Le protocole PPP
Les connexions à Internet utilisent le protocole PPP (abréviation de l’anglais « Point to Point Protocol »),
qui permet à deux ordinateurs d’échanger des paquets TCP/IP au travers d’un canal de communication
simple (donc, en particulier, au travers d’une ligne téléphonique en utilisant un modem). Ce protocole est
géré par le noyau et par le démon pppd. Il permet d’effectuer la négociation initiale entre les deux
machines, ce qui comprend notamment l’identification, l’authentification et l’attribution des adresses IP.
Le démon pppd ne gère pas le modem directement, car il est supposé être utilisable sur d’autres types de
lignes que les lignes téléphoniques. La gestion du modem est donc relayée à un autre programme, qui se
nomme chat (il tient son nom du fait qu’il permet de dialoguer directement avec le modem). Le
programme chat ne connaît pas les différents types de modems qui existent sur le marché, il se contente
d’exécuter des scripts qui décrivent les informations à envoyer au modem et les réponses attendues en
retour. Cela permet de reporter la configuration spécifique aux modems dans des scripts de connexion.
L’écriture de ces scripts nécessite bien entendu de connaître les commandes que votre modem est
capable de comprendre. Notez également qu’il est indispensable ici que votre modem soit un vrai
modem (qu’il soit interne ou externe), et non pas un modem logiciel (ces modems sont des modèles bas
de gamme qui nécessitent un support logiciel pour interpréter les informations analogiques reçues sur la
ligne téléphonique). Renseignez-vous donc bien sur la nature du modem que vous achetez, si vous
voulez ne pas avoir de problèmes sous Linux...
La séquence des opérations lors d’une connexion est donc l’initialisation du modem et l’établissement de
l’appel téléphonique par le programme chat, puis le démarrage du démon pppd. Celui-ci effectue la
connexion sur le serveur du fournisseur d’accès et détermine l’adresse IP, les adresses des DNS, la
passerelle et la route à utiliser pour cette connexion. Une fois cela réalisé, toutes les fonctionnalités
réseau peuvent être utilisées via Internet, et votre ordinateur fait alors partie du réseau mondial.
L’identification et l’authentification peuvent se faire de différentes manières selon le fournisseur d’accès
à Internet utilisé. Un certain nombre de fournisseurs exige l’authentification lors de l’appel téléphonique,
avec un mécanisme de login classique. Pour ces fournisseurs, l’authentification est faite par le
programme chat, auquel il faut communiquer le nom d’utilisateur et le mot de passe. D’autres
fournisseurs utilisent un protocole d’authentification spécifique. Pour ceux-ci, l’authentification est
réalisée directement par le démon pppd, une fois que la ligne a été établie. Les deux principaux
protocoles d’authentification sont PAP (abréviation de l’anglais « Password Authentification Protocol »)
et CHAP (abréviation de « Challenge Handshake Authentification Protocol »). PAP réalise
l’authentification comme le mécanisme de login classique : le client envoie son nom et le mot de passe
correspondant en clair au serveur. CHAP utilise en revanche la notion de défi. Le serveur envoie une
requête contenant son nom, et le client doit s’identifier et authentifier son identité en lui renvoyant une

294
 Chapitre 9. Configuration du réseau

réponse contenant son propre nom et une valeur calculée à partir du mot de passe correspondant. Les
deux méthodes seront présentées ci-dessous. Si vous ne parvenez pas à vous connecter à Internet avec la
première de ces méthodes, tentez votre chance avec PAP ou CHAP. Sachez que pour utiliser ces
protocoles il est nécessaire de connaître, en plus de votre login et de votre mot de passe, le nom du
serveur utilisé. Cette information doit vous être communiquée par votre fournisseur d’accès à Internet. Si
vous avez le choix, utilisez de préférence le protocole CHAP, car il n’envoie jamais de mot de passe en
clair sur la ligne téléphonique.
La configuration de l’accès à Internet pour un fournisseur d’accès requiert donc la configuration du
réseau, la configuration de ppp, la configuration de chat et l’écriture des scripts de connexion. Ces étapes
seront détaillées ci-dessous. Nous supposerons dans la suite que vos paramètres de connexion sont les
suivants :

Paramètre Valeur
Fournisseur d’accès Internet [Link]
Nom de domaine [Link]
Adresse du DNS [Link]
Numéro de téléphone 08 36 76 30 18
Nom de login jdupont
Mot de passe gh25k;f
Nom de serveur (pour PAP et CHAP) serveurfai

Note : Les informations données dans le tableau ci-dessus sont fictives et ne servent qu’à donner un
exemple. Vous devez bien entendu les remplacer par les valeurs vous concernant en chaque endroit
où elles apparaissent dans la suite de ce document. Si par hasard une de ces informations
correspondait à un numéro de téléphone, un nom ou une adresse IP valide, ce serait une pure
coïncidence.
Certains fournisseurs d’accès refuseront de vous donner toutes ces informations, sous prétexte
qu’ils vous fournissent un kit de connexion pour Windows. Ce n’est pas trop grave, car il est possible
de leur extorquer ces informations malgré eux. Les seules informations réellement indispensables
sont le numéro de téléphone, le nom de login, le mot de passe et le nom de domaine. Les adresses
de DNS peuvent être déterminées automatiquement dans le cadre du protocole PPP, et le nom de
serveur est arbitraire et ne sert qu’à identifier la connexion.

Création d’une connexion à Internet

La première étape dans la création d’une connexion à Internet est avant tout l’ajout des serveurs DNS du
fournisseur d’accès à votre configuration réseau. Cela n’est pas toujours nécessaire, car il est possible de
configurer le démon pppd pour qu’il demande au fournisseur d’accès les adresses IP des DNS de celui-ci
lors de l’établissement de la connexion. Cependant, il est plus facile d’utiliser le mécanisme de connexion
à la demande si l’on indique les adresses des DNS du fournisseur d’accès dans la configuration réseau.
Pour l’exemple de connexion utilisé ici, vous devez simplement ajouter les lignes suivantes dans le
fichier /etc/[Link] :

295
 Chapitre 9. Configuration du réseau

search [Link]
nameserver [Link]

Si vous ne connaissez pas les adresses de DNS de votre fournisseur d’accès, vous pourrez l’obtenir en
regardant dans les traces du noyau lors de l’établissement d’une connexion. Nous verrons cela en détail
plus loin.
La deuxième étape est d’écrire un script de numérotation pour le programme chat. Ce script pourra être
placé dans le répertoire /etc/ppp/peers/, et pourra être nommé [Link] par exemple. Son
contenu sera le suivant :

REPORT CONNECT
ABORT ERROR
ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
"" ATZ
OK AT&F1
OK ATM0L0DT0836763018
CONNECT ""

Ce script contient le programme que chat doit exécuter pour appeler le fournisseur d’accès à Internet. Il
indique toutes les erreurs possibles susceptibles de faire échouer l’opération, puis il envoie les
commandes d’initialisation et de numérotation au modem. Vous devrez remplacer le numéro de
téléphone utilisé dans la commande DT<numéro> par le numéro de téléphone de votre fournisseur
d’accès à Internet.

Note : Dans les scripts pour chat, il est possible d’utiliser indifféremment l’apostrophe simple,
l’apostrophe double ou aucune apostrophe si la chaîne attendue de la part du modem ou à lui
envoyer ne contient aucun espace.
Si d’aventure ce script ne fonctionne pas, vous serez sans doute obligé de demander au programme
chat d’afficher tous les messages envoyés et reçus par le modem. Cela se fait normalement avec les
options -v et -s. Vous verrez alors les messages en provenance du modem, ce qui vous permettra
de déterminer comment modifier ce script.

Si votre fournisseur d’accès à Internet utilise un mécanisme de login classique, vous devez faire
l’identification directement dans le script chat. En général, serveur du fournisseur d’accès envoie la
demande de login dès que la connexion a été établie. Pour cela, il utilise une chaîne de caractères telle
que « login: », à laquelle le script chat doit répondre par votre nom d’utilisateur. Le serveur demande
alors le mot de passe avec une chaîne telle que « password: », demande à suite de laquelle le script chat
doit envoyer votre mot de passe. Ce n’est que lorsque ces deux informations auront été fournies que la
connexion sera réellement établie. Vous pouvez compléter le script chat pour répondre à ces deux
questions avec les deux lignes suivantes :

ogin: jdupont

296
 Chapitre 9. Configuration du réseau

ssword: gh25k;f

Vous devrez bien entendu remplacer le nom du login et le mot de passe par vos propres données dans ce
script. Notez qu’il n’est pas nécessaire (ni recommandé) de demander la réception de la chaîne complète
« login: », car une erreur de transmission sur la ligne peut encore arriver à ce stade et provoquer la
perte des premiers caractères envoyés par l’ordinateur distant. De plus, il se peut que la première lettre
soit en majuscule ou en minuscule, selon le fournisseur d’accès à Internet que vous utilisez. Il en va de
même pour la demande de mot de passe (« password: »).
Si, en revanche, votre fournisseur d’accès utilise le mécanisme d’authentification PAP ou CHAP, vous ne
devez pas ajouter ces lignes, car le serveur n’enverra pas la chaîne de caractères « login: ». Il tentera de
communiquer directement avec votre démon pppd pour réaliser l’authentification. Bien entendu, les défis
lancés par le serveur sont simplement constitués de la demande du login et de la demande du mot de
passe correspondant à ce login. Le démon pppd utilisera alors les « secrets » stockés dans le fichier
/etc/ppp/pap-secrets ou le fichier /etc/ppp/chap-secrets pour répondre à ces défis, selon que
le protocole utilisé par le serveur du fournisseur d’accès est PAP ou CHAP. C’est donc dans ces fichiers
que vous devrez enregistrer votre login et votre mot de passe. Le format de ces fichiers est très simple.
Les deux fichiers utilisent la même syntaxe pour les secrets. Vous devez simplement y ajouter une ligne
telle que celle-ci :

# Secrets for authentification using PAP/CHAP

# client server secret IP addresses
jdupont serveurfai gh25k;f

pour que l’identification et l’authentification se fasse correctement. Comme on le voit, le nom du serveur
est indiqué dans ce fichier : il permet de déterminer quel login et quel mot de passe doivent être utilisés
pour les protocoles PAP et CHAP.

Note : En fait, le protocole PPP ne permet pas d’identifier des utilisateurs, mais des machines.
Cependant, pour votre fournisseur, votre machine est identifiée par votre login, et il faut donc
indiquer ce nom comme nom de machine cliente dans les fichiers pap-secrets et chap-secrets.
Le nom de serveur n’est pas utilisé pour la connexion. Il ne sert qu’à déterminer quel secret doit être
utilisé pour une connexion donnée. Comme la plupart des gens n’ont qu’un seul fournisseur d’accès
à Internet, ce nom est purement et simplement facultatif. Dans ce cas, on peut parfaitement
remplacer le nom du serveur par une étoile. Ce caractère générique indique simplement que le
même secret doit être utilisé pour toutes les connexions.
Pour les connexions à Internet, il est souvent impossible de connaître a priori l’adresse IP que le
serveur donnera au client. On peut donc laisser vide la colonne contenant les adresses IP utilisables
par les clients.

Lorsque vous aurez écrit le script chat et éventuellement complété les fichiers de secrets de PAP ou de
CHAP, vous pourrez écrire le script de connexion à Internet. Ce script est très simple :

#!/bin/sh
# Script de connexion à Internet

297
 Chapitre 9. Configuration du réseau

# Effectue le ménage :
rm -f /var/spool/uucp/LCK* /var/lock/LCK* /var/run/ppp*.pid

# Établit la connexion :
/usr/sbin/pppd /dev/modem 115200 connect "/usr/sbin/chat -v \
-f /etc/ppp/peers/[Link]" defaultroute usepeerdns \
ipcp-accept-remote ipcp-accept-local

Prenez garde à écrire la ligne exécutant pppd et la ligne des options en une seule ligne, sans saut de ligne.
Notez que le caractère ’\’ placé en fin de ligne permet d’indiquer que la commande se poursuit sur la
ligne suivante. Ce script commence par faire le ménage sur les fichiers éventuellement laissés par les
anciennes connexions, et appelle pppd en lui demandant d’utiliser la connexion établie par le programme
chat avec la vitesse maximale de connexion indiquée. Lorsque la connexion est établie, le serveur du
fournisseur d’accès est enregistré comme passerelle par défaut dans la table de routage du noyau. L’envoi
et la réception des paquets IP en direction de l’Internet se fera donc en passant par cette passerelle. Les
adresses de DNS du fournisseur d’accès sont également récupérées et ajoutées dans le fichier
/etc/ppp/[Link]. Vous pourrez les déterminer simplement en consultant les fichiers de log de
votre distribution dans le répertoire /var/log/. Les deux dernières options permettent d’autoriser le
serveur du fournisseur d’accès à fixer les adresses IP locales et distantes.
Dans ce script de connexion, le programme chat est appelé avec le script de numérotation pour chat que
l’on a déjà écrit. Si l’on désire voir exactement ce qui se passe, on peut ajouter l’option -s à la
commande d’exécution de chat :

/usr/sbin/chat -v -s -f /etc/ppp/peers/[Link]

dans le script de connexion vu ci-dessus. Cela vous permettra de déboguer votre script de numérotation.
Vous remarquerez que le programme pppd utilise le fichier spécial de périphérique /dev/modem pour la
communication. Il va de soi que si ce fichier spécial n’existe pas, vous devrez le créer. La solution la plus
simple est de faire un lien symbolique vers /dev/ttS0 ou /dev/ttS1, selon que votre modem est
connecté sur le premier ou le deuxième port série de votre ordinateur.
La commande de lancement donnée ci-dessus suppose que le script de connexion
/etc/ppp/peers/[Link] réalise l’identification et l’authentification. Si vous utilisez l’un des
protocoles PAP ou CHAP, il faut demander à pppd d’effectuer ces deux opérations lui-même. Pour cela,
il faut ajouter des options dans la ligne de commande utilisée pour le lancer dans le script de connexion,
afin de préciser le nom du serveur et le nom d’utilisateur pour l’identification. La ligne complète à
utiliser pour PAP ou CHAP doit donc être celle-ci :

# Établit la connexion :
/usr/sbin/pppd /dev/modem 115200 connect "/usr/sbin/chat -v \
-f /etc/ppp/peers/[Link]" defaultroute usepeerdns \
ipcp-accept-remote ipcp-accept-local noauth \
remotename serveurfai user jdupont

Encore une fois, cette commande doit être écrite sur une seule ligne, ou sur plusieurs lignes séparées par
le caractère ’\’. L’option noauth signale qu’il n’est pas nécessaire que le serveur du fournisseur d’accès

298
 Chapitre 9. Configuration du réseau

s’authentifie en tant que tel (ce n’est pas nécessaire, car les fournisseurs d’accès ne jouent pas vraiment
aux pirates du web), et les deux options suivantes permettent respectivement d’indiquer le nom de ce
serveur ainsi que le nom d’utilisateur à utiliser pour le login. Lors de l’authentification, le démon pppd
lira le fichier de secret du protocole choisi par le fournisseur d’accès pour trouver le mot de passe à
utiliser. Notez encore une fois qu’il est facultatif de préciser le nom du serveur du fournisseur d’accès si
vous avez utilisé le caractère générique ’*’ dans les fichiers de secrets pour PAP et CHAP.
Il est possible de faire en sorte que la connexion à Internet s’établisse automatiquement dès qu’un
programme cherche à utiliser une adresse devant passer par la route par défaut. Toute demande à
destination d’une machine dont l’adresse est inconnue localement provoque dans ce cas l’établissement
de la connexion à Internet. Pour cela, il suffit simplement :

• d’ajouter l’option demand à la ligne de commande de pppd dans le script de connexion ;

• de lancer ce script en arrière plan dans un des scripts de démarrage du système.

Si vous désirez utiliser cette fonctionnalité, il est recommandé d’activer également la déconnexion
automatique, faute de quoi vous risqueriez de rester connecté involontairement. Cela se fait simplement
en ajoutant l’option idle n dans la ligne de commande de pppd, où n est le nombre de secondes
pendant lequel le lien PPP doit rester inactif avant que la connexion ne se coupe automatiquement. Un
choix judicieux est par exemple 600 (ce qui correspond à dix minutes).

Note : L’interface réseau est automatiquement créée lorsqu’on lance le démon pppd avec l’option
demand. Par conséquent, le démon pppd définira automatiquement une adresse IP locale pour cette
interface et une adresse IP distante pour la passerelle par défaut. Malheureusement, ces adresses
peuvent changer d’une connexion à une autre. En effet, la plupart des fournisseurs attribuent les
adresses IP en fonction du modem qui répond au client qui appelle et, en général, la connexion ne
se fait pas toujours sur le même modem (il peut y avoir plusieurs modems pour un même numéro de
téléphone). C’est pour cela qu’il faut ajouter les options ipcp-accept-remote et
ipcp-accept-local pour indiquer à pppd de modifier ces adresses lorsqu’il établira la connexion.
Le problème, c’est que les connexions TCP/IP utilisant ces adresses seront systématiquement
cassées à la suite de ce changement. C’est en particulier le cas pour le programme qui a initié
l’établissement de la liaison PPP. C’est pour cette raison qu’il est recommandé de demander une
adresse IP fixe à son fournisseur d’accès lorsqu’on veut utiliser la connexion à la demande. Hélas,
ce service peut faire l’office d’une facturation supplémentaire.
Même si l’on utilise l’option usepeerdns dans la ligne de commande de PPP, il est recommandé de
rajouter les adresses des DNS dans le fichier /etc/[Link]. En effet, en l’absence de DNS,
les noms de domaine ne seront pas résolus et aucune requête vers l’extérieur ne se fera. Par
conséquent, la route par défaut ne sera pas utilisée, et pppd n’établira donc pas la connexion
automatiquement. Notez que si vous définissez les DNS dans le fichier /etc/[Link], vous
pouvez vous passer de l’option usepeerdns dans la ligne de commande de pppd. Si vous désirez
procéder de cette manière, vous devrez vous assurer que l’ordre spécifié pour la résolution des
noms dans le fichier /etc/[Link] est bien le fichier /etc/hosts (option hosts) avant le DNS
(option bind), faute de quoi votre ordinateur se connectera systématiquement à Internet dès que
vous utiliserez un nom de machine local.
La plupart des options passées en ligne de commande peuvent être spécifiées dans le fichier
d’options /etc/ppp/options du démon pppd. Cela peut permettre de simplifier les scripts de
connexion.

299
 Chapitre 9. Configuration du réseau

Si l’on n’utilise pas les mécanismes de connexion / déconnexion automatiques, on devra se déconnecter
manuellement. Pour cela, rien de plus simple : il suffit de détruire le démon pppd. Cela peut être réalisé
automatiquement avec le script suivant :

#!/bin/sh
# Script de terminaison de la connexion PPP
#

# Détermine la connexion à fermer (fournie sur la ligne de commande,

# ppp0 par défaut) :
if [ "$1" = "" ]; then
DEVICE=ppp0
else
DEVICE=$1
fi

# Teste si la connexion indiquée est active :

if [ -r /var/run/$[Link] ]; then

# Détruit le processus ppp correspondant (son PID est stocké

# dans /var/run/) :
kill -INT ‘cat /var/run/$[Link]‘

# Effectue le ménage :
if [ ! "$?" = "0" ]; then
rm -f /var/run/$[Link]
echo "ERREUR: Un fichier de PID résiduel \
a dû être effacé manuellement"
exit 1
fi
rm -f /var/spool/uucp/LCK* /var/lock/LCK*
echo "La connexion PPP sur $DEVICE a été fermée correctement..."
echo

# Termine le script :
exit 0
fi

# La connexion indiquée n’est pas active :

echo "ERREUR: Il n’y a pas de connexion PPP sur $DEVICE"
exit 1

Connexion à l’ADSL
Les connexions ADSL ne requièrent pas d’appel téléphonique vers un modem du fournisseur d’accès.
Elles s’établissent donc d’une manière différente, généralement bien plus simple. Toutefois, la manière
de procéder dépend des fournisseurs d’accès et de la nature de votre modem ADSL. Il est donc difficile

300
 Chapitre 9. Configuration du réseau

de décrire de manière générique la manière dont une connexion ADSL se met en place sous Linux.
Seules les grandes lignes seront donc indiquées dans ce paragraphe.
Sachez pour commencer qu’il existe deux types de modems ADSL : les modems Ethernet et les modems
USB. Les premiers sont connectés à votre ordinateur via une carte Ethernet, alors que les seconds
utilisent un câble USB. Il va de soi que les modems USB requièrent des pilotes de périphériques
spécifiques à chaque type de modem, alors que les modems Ethernet se connectent directement à votre
carte Ethernet par un câble Ethernet (droit ou croisé selon votre modem). Si votre carte réseau est prise
en charge par Linux, vous n’aurez aucun problème pour vous connecter à Internet avec un modem
Ethernet, alors que les pilotes USB pour Linux sont rarement développés avec sérieux par les fabricants
de modem (ayant essuyé les plâtres avec le modem Sagem Fast800 fourni par Free à ses clients et
participé au débogage de celui-ci, je suis bien placé pour le savoir). De plus, les modems USB ne
peuvent pas être utilisés avec un routeur, appareil dont l’achat se justifie pleinement si vous disposez
d’un petit réseau familial et que vous désirez partager la connexion ADSL entre les différentes machines.
Pour terminer, les modems Ethernet sont alimentés, alors que les modems USB utilisent l’alimentation
du port USB, ce qui dans 50% des cas provoque des instabilités de la connexion Internet, si ce n’est de
l’ordinateur lui-même. Il est donc vivement conseillé de choisir un modem Ethernet si vous en achetez
un ou si votre fournisseur d’accès à Internet vous en propose.

Note : Même si, comme nous le verrons plus loin, Linux est parfaitement capable de réaliser un
partage de connexion à Internet, l’achat d’un routeur Ethernet reste intéressant car ces appareils
réalisent ces opérations de manière très simple d’une part, et permettent de ne pas avoir un
ordinateur sous Linux allumé en permanence pour faire office de passerelle d’autre part. L’achat d’un
modem routeur sans fil peut même être une bonne idée au niveau simplicité, même si cela vous
posera quelques problèmes de sécurité majeurs.
Les fournisseurs d’accès à Internet répugnent à fournir des modems Ethernet, car ils coûtent
généralement plus chers que les modems USB, et leur installation sous Windows est considérée
comme hors de portée de l’utilisateur moyen. Ils invoquent donc souvent des pénuries (fictives)
comme excuse pour ne pas en fournir. Ne vous laissez pas démonter et insister lourdement, c’est
votre droit en tant que client.

Même si vous utilisez un modem USB, il apparaîtra généralement comme une interface Ethernet dans le
système. L’installation des pilotes pour les modems USB étant extrêmement spécifique, cette étape ne
sera pas décrite plus en avant ici. La suite du document suppose donc que vous disposiez d’un modem
Ethernet, ou que votre modem soit accessible par l’intermédiaire d’une interface Ethernet simulée par le
pilote du modem.
Lorsque vous aurez branché votre modem et que vous pourrez y accéder via son interface Ethernet, vous
devrez établir la connexion avec votre fournisseur d’accès. Cela dépend encore une fois du fournisseur
d’accès, et parfois même, pour un même fournisseur, de la région dans laquelle vous vous trouvez.
Généralement, deux méthodes sont utilisées pour établir la connexion :

• soit les communications se font de manière totalement transparente via l’interface Ethernet du modem,
auquel cas la connexion s’établit aussi facilement que si vous vous connectiez à un réseau Ethernet
classique ;
• soit les communications sont encapsulées dans le protocole de communication PPP, via un protocole
du type PPPoE (« PPP over Ethernet ») ou PPPoA (« PPP over ATM »), auquel cas vous devrez
utiliser le démon pppd pour établir la connexion.

301
 Chapitre 9. Configuration du réseau

Dans le premier cas, la configuration est simpliste. Il suffit d’utiliser l’interface Ethernet du modem
comme interface de sortie dans la route par défaut, et éventuellement de mettre un client DHCP à
l’écoute sur cette interface si le fournisseur d’accès utilise ce protocole pour attribuer les adresses IP de
ses clients. La manière de procéder est décrite dans la section traitant de DHCP. Cette technique est celle
utilisée par le fournisseur d’accès Free en France en zone dégroupée. Pour ce fournisseur, les adresses IP
fournies étant fixes en zone dégroupée, la connexion à Internet se résume donc aux deux commandes
suivantes :

ifconfig eth0 adresse up

route add default eth0

où adresse est l’adresse IP que Free vous a attribuée. La connexion à Internet se fait donc dans ce cas
comme la configuration d’une simple carte réseau.
Dans le deuxième cas, le plus simple est d’utiliser le protocole d’encapsulation PPPoE. Comme con nom
l’indique, ce protocole permet d’encapsuler les paquets de la liaison PPP avec votre fournisseur Ethernet
directement dans des trames Ethernet, qui peuvent ensuite être envoyées via l’interface Ethernet du
modem. Cette solution peut être mise en place avec l’outil rp-pppoe de la société Roaring Penguin
([Link] ou directement avec un gestionnaire PPPoE au niveau du noyau.
La mise en place d’une connexion avec rp-pppoe est réellement très simple. En effet, un fichier d’options
pour PPP nommé [Link] et des scripts de connexion et déconnexion adsl-start et adsl-stop,
permettant de lancer le démon pppd avec les bonnes options et dans le bon contexte pour établir la
connexion, sont fournis. Les seules opérations à faire sont dans ce cas de s’assurer que les identifiants de
connexion (login et mot de passe) fournis par votre fournisseur d’accès sont bien enregistrés dans les
fichiers pap-secrets et chap-secrets, et que le fichier [Link] y fait bien référence (au niveau
de l’option USER). La manière de procéder ayant déjà été décrite ci-dessus, elle ne sera pas détaillée
outre mesure.
L’utilisation du gestionnaire PPPoE du noyau est encore plus directe, car il suffit simplement dans ce cas
de lancer le démon pppd en lui demandant de travailler avec l’interface réseau du modem. Pour utiliser
ce gestionnaire, vous devez activer, outre le support de PPP, l’option « PPP over Ethernet
(EXPERIMENTAL) » dans les options de configuration du noyau. Une fois les identifiants de connexion
écrits dans les fichiers pap-secrets ou chap-secrets, la connexion à Internet se fera simplement
avec la commande suivante :

pppd interface

où interface est le nom de l’interface réseau du modem.

Note : Il est recommandé de limiter la taille des paquets en réception et en émission à 1492 octets,
afin de prendre en compte les frais dûs à l’encapsulation PPPoE. Pour cela, il suffit de placer les
options suivantes dans le fichier d’options de pppd :

mtu 1492
mru 1492

Il est impératif de mettre en place un pare-feu si vous disposez d’une connexion ADSL. La manière
de procéder est décrite dans la la section intitulée Pare-feu et partages de connexion à Internet>.

302
 Chapitre 9. Configuration du réseau

Les autres outils de connexion

Vous en savez suffisamment à présent pour vous connecter à Internet avec Linux. Les opérations qui ont
été décrites ici sont légèrement compliquées, et vous les trouvez sans doute un peu lourdes. Cela est
naturel, car elles le sont effectivement. En fait, les opérations décrites ici vous montrent comment vous
connecter manuellement, mais elles ne constituent pas la manière de faire la plus facile. En effet, si vous
installez XWindow, vous pourrez utiliser des programmes graphiques permettant de vous connecter à
Internet, d’envoyer et recevoir des courriers électroniques (« mails »), de naviguer (« surfer ») et de lire
les groupes de discussions (« news »). Cependant, l’utilisation de ces outils ne sera pas décrite ici, car il
en existe trop pour que l’on puisse tous les présenter. Heureusement, ces outils sont prévus pour être très
simples d’emploi et leur configuration ne pose réellement aucun problème.

Configuration d’un cache de DNS

La résolution des noms de domaines est une opérations dont le coût est loin d’être négligeable au niveau
du temps de connexion aux serveurs, si ce n’est au niveau de la bande passante utilisée. En effet, il est
relativement courant qu’une page Web fasse de multiple références à des machines inconnues et dont les
adresses doivent être résolues. De ce fait, la résolution des noms de domaines peut parfois se mesurer en
secondes, surtout si les serveurs de noms des fournisseurs d’accès sont surchargés.
De plus, il est courant qu’un internaute reste toujours sur le même site pendant qu’il navigue sur Internet.
Il peut donc être très intéressant d’installer un serveur de nom local, que l’on configurera en tant que
cache de DNS. Cela permettra de réduire sensiblement les temps de connexions aux machines situées sur
Internet.

Note : Les « caches » sont des mécanismes permettant de stocker en local une copie de données
relativement difficiles à obtenir et qui varient très peu, afin de pouvoir en disposer plus rapidement.
Les caches sont utilisés très souvent en informatique, aussi bien au niveau des disques durs et des
processeurs qu’au niveau du réseau. Ils permettent d’augmenter considérablement les
performances, au détriment d’un ralentissement des opérations d’écriture des données, puisque
celles-ci invalident les données des caches et doit forcer leur mise à jour.

L’espace de nommage d’Internet est structuré hiérarchiquement en zones. Lors de la résolution d’un nom
de domaine, ce nom est décomposé en noms de zones et de sous-zones, en partant de la fin. À chaque
niveau, le client qui cherche à résoudre le nom interroge un serveur de noms de la zone courante, jusqu’à
ce qu’il obtienne l’adresse du nom de domaine. Lorsqu’il ne connaît aucun serveur de noms pour les
zones de premier niveau, il doit interroger l’un des serveurs de noms racines d’Internet. Ces serveurs sont
gérés par l’Internic et par quelques sociétés commerciales. Le nom de zone qui est associé aux serveurs
racines est le nom « . », qui constitue le nom de la zone racine.
Par exemple, lors de la résolution du nom de domaine « [Link] », les clients interrogent
d’abord les serveurs de noms racines pour obtenir les adresses des serveurs de noms capables de
résoudre les noms de la zone .com. Ensuite, ils interrogent ces serveurs pour obtenir les serveurs de
noms prenant en charge de la zone monrezo. Enfin, ils obtiennent l’adresse IP de la machine cible à

303
 Chapitre 9. Configuration du réseau

partir de ces serveurs. Bien entendu, ce processus peut être optimisé si l’on connaît déjà l’un des serveurs
de noms d’une zone. De fait, les serveurs de noms primaires ne sont utilisés que relativement rarement.
La mise en place d’un serveur de nom cache consiste donc à s’assurer que les clients l’interrogent en
premier, et à le configurer de telle sorte qu’il puisse interroger un autre serveur de nom lorsqu’il ne peut
répondre lui-même aux requêtes des clients. L’idéal est dans ce cas simplement de s’adresser aux
serveurs de noms du fournisseur d’accès à Internet, afin de bénéficier de son cache et de sa bande
passante pour les requêtes intermédiaires.
Le serveur de domaine le plus utilisé est sans doute le serveur BIND (« Berkeley Internet Name
Domain »). Il est généralement installé par toutes les distributions, et est souvent préconfiguré pour
réaliser un cache de DNS. Toutefois, les configurations utilisées ne délèquent pas forcément les requêtes
aux serveurs DNS des fournisseurs d’accès, et ne limitent pas toujours les accès aux seuls clients
autorisés. Nous verrons donc comment configurer BIND pour réaliser un cache.
BIND utilise un démon nommé named pour répondre aux requêtes des clients. Celui-ci utilise le fichier
de configuration /etc/[Link], dont vous trouverez un exemple réduit à sa plus simple expression
ci-dessous :

// Définition des options globales du démon :

options {
// Répertoire où les fichiers de données sont stockés :
directory "/var/named";

// Liste des adresses sur lesquelles on accepte de répondre

// aux requêtes DNS :
listen-on { [Link]; [Link]; };

// Serveurs de DNS auxquels les requêtes sont déléguées

// en cas de réponse inconnue :
forward first;
forwarders { [Link] ; [Link]; };
};

// Définition de la zone racine :

zone "." IN {
type hint;
file "[Link]";
};

Comme vous pouvez le constater, ce fichier est constitué de deux sections. La première section contient
les options globales de named. Elle permet d’indiquer le répertoire dans lequel celui-ci trouvera les
fichiers de données dont il a besoin, ainsi que les adresses réseau des interfaces réseau sur lesquelles il
devra se mettre à l’écoute pour répondre aux requêtes DNS. Les adresses indiquées dans la directive
listen-on permettent de faire en sorte que votre démon named ne réponde qu’à la machine locale et
aux machines situées sur un réseau local d’adresse [Link]/24. La directive forward permet
quant à elle de demander à named de s’adresser à un autre serveur DNS pour obtenir la réponse aux
requêtes dont il n’a pas encore la réponse. Les adresses de serveurs DNS à interroger dans ce cas sont
spécifiées à l’aide de la directive forwarders. Vous devrez y placer les adresses des serveurs DNS
primaires et secondaires de votre fournisseur d’accès.

304
 Chapitre 9. Configuration du réseau

L’option first de la directive forward signifie que les serveurs DNS du fournisseur d’accès doivent
être interrogés en premier, mais que si une requête ne peut être résolue par ces serveurs, bind devra
essayer de résoudre cette requête par ses propres moyens. Pour cela, il cherchera à décomposer le nom de
domaine et à interroger les serveurs de DNS en charge de chaque composante de ce nom, comme
expliqué ci-dessus. Il lui faut donc un point d’entrée, à partir duquel il pourra résoudre n’importe quel
nom de domaine. Ce point d’entrée est donné par la deuxième section du fichier /etc/[Link].
Cette deuxième section est la définition de la zone DNS racine du système DNS. Elle permet de définir le
point d’entrée pour les résolutions de n’importe quel nom, en décrivant la manière dont les noms doivent
être résolus à partir de la racine du système DNS. L’option hint de la directive type indique que les
informations obtenues à ce niveau ne seront que des adresses d’autres serveurs de noms (en l’occurrence
les serveurs de noms racines). La directive file indique que les adresses des serveurs de noms de cette
zone devront être obtenues par consultation du fichier [Link].
Ce fichier doit être situé, conformément à l’option directory de la section globale, dans le répertoire
/var/named/. Il est fourni par l’Internic, et contient la liste des serveurs DNS racines :

. 3600000 IN NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]
. 3600000 NS [Link].
[Link]. 3600000 A [Link]

Comme vous pouvez le constater, ce fichier contient les noms des serveurs DNS en charge de la zone
« . » (lignes dont le quatrième champ contient la chaîne de caractère « NS », pour « Named Server »),
ainsi que les adresses IP ce ces serveurs (lignes dont le quatrième champ contient le caractère « A »). Les
adresses des serveurs de noms racines pouvant évoluer dans le temps, il est nécessaire de le mettre à jour
régulièrement.

305
 Chapitre 9. Configuration du réseau

Une fois que vous aurez configuré et lancé le démon named, vous devrez encore indiquer au système
qu’il devra interroger ce démon pour effectuer la résolution des noms de domaines. Comme il l’a déjà été
indiqué dans les sections précédentes, cela se fait simplement en ajoutant une ligne nameserver
référençant la machine locale dans le fichier de configuration /etc/[Link] :

nameserver [Link]

Note : Le démon named ne permet de cacher que les résultats des requêtes DNS. Or, de nombreux
fichiers qui ne changent quasiment jamais sont récupérés de multiples fois lorsqu’un internaute
navique sur des pages Web. Il est donc très intéressant de mettre également ces fichiers en cache.
Nous verrons comment réaliser cela dans la section suivante.

Installation d’un proxy HTTP

Lors d’une connexion à Internet, bon nombre d’informations sont échangées entre le serveur et le client.
En particulier, lorsqu’on navigue, un certain nombre d’images et d’informations plus ou moins lentes à
télécharger transitent systématiquement. Or la plupart des gens visitent régulièrement les mêmes sites,
dont seulement quelques pages sont modifiées entre deux visites successives. Par conséquent, on peut se
demander pourquoi les pages complètes devraient être rechargées à chaque visite, si seulement quelques
informations ont été modifiées.
Cette question prend encore plus de sens lorsqu’on réalise un partage de connexion à Internet. Il est tout
à fait concevable que plusieurs clients du même réseau demandent plusieurs fois les mêmes
informations, ce qui provoque l’engorgement du lien partagé inutilement. C’est pour résoudre ce genre
de problème que les programmes que l’on nomme « proxies » ont été développés.
Un proxy n’est rien d’autre qu’un programme qui s’intercale entre des clients et un serveur. Il a pour
principale fonction de mémoriser les réponses les plus courantes renvoyées par le serveur, afin de
répondre à la fois plus rapidement aux clients et d’éviter de surcharger le serveur. Il existe différents
types de proxy, mais nous allons nous intéresser uniquement aux proxies Web, qui permettent donc de
stocker des pages Web en local afin de soulager une liaison trop faible.
Le principe de fonctionnement d’un proxy est le suivant. Les navigateurs utilisés par les clients se
connectent, en temps normal, directement sur le port 80 des serveurs Web. Leur configuration doit être
modifiée pour utiliser le proxy à la place. De leur point de vue, le proxy se comporte comme un serveur
Web capable de répondre aux requêtes des clients. Lorsqu’il peut le faire, il renvoie les données qu’il a
stockées dans son cache. Sinon, il va les chercher directement sur Internet à la place du client. Le cache
est maintenu de telle manière que les données obsolètes ou les données les moins utilisées sont
supprimées, afin de laisser la place aux données qui sont le plus souvent demandées et qui changent le
moins. Pour utiliser un proxy, il faut donc modifier la configuration des navigateurs des clients, afin de
donner l’adresse de la machine sur laquelle le proxy fonctionne, ainsi que le port sur lequel il peut être
contacté (généralement, c’est le port 8080).

Note : Il est également possible d’utiliser les mécanismes de translation d’adresse du noyau pour
rendre l’utilisation du proxy transparente aux clients. La manière de procéder sera décrite dans la
section traitant des mécanismes de filtrage du noyau.

306
 Chapitre 9. Configuration du réseau

Il existe plusieurs proxies sur le marché, mais le plus utilisé sous Linux est sans doute squid. C’est un
logiciel performant, puissant et libre, fourni avec la plupart des distributions modernes. Sa configuration
peut être relativement technique, mais nous n’allons pas entrer dans tous les détails. Il s’agit simplement
ici de donner un aperçu des fonctionnalités disponibles.
squid utilise le fichier de configuration /etc/[Link] pour lire ses options de fonctionnement. Ce
fichier contient en particulier les informations concernant le réseau, une liste de règles indiquant qui a le
droit de lui demander des pages Web, et l’emplacement du cache dans lequel les données du cache seront
enregistrées.
L’option la plus importante dans ce fichier de configuration est sans doute cache_dir, qui indique
l’emplacement du cache ainsi que sa taille et sa structure. La syntaxe de cette option est la suivante :

cache_dir répertoire taille n m

où répertoire est le répertoire dans lequel le cache sera stocké (usuellement /var/squid/cache/),
taille est la taille de ce cache en méga-octets, et n et m deux nombres donnant la structure de
l’arborescence du cache. La signification de ces deux nombres doit être expliquée un peu plus en détail.
Par défaut, squid essaie de répartir tous les objets qu’il place dans le cache de manière uniforme dans
plusieurs répertoires, afin d’accélérer les temps de recherche sur ces objets lorsqu’un client les demande.
Il utilise à cette fin une fonction de répartition (les programmeurs disent souvent une fonction de hash)
qui indique dans quel répertoire se trouve un objet. La recherche dans ce répertoire se fait donc plus
rapidement car, si la fonction de répartition est bien faite (et c’est le cas), les objets sont répartis de
manière équilibrée dans tous les répertoires du cache, qui sont donc tous relativement peu peuplés. En
fait, squid peut stocker tellement d’objets que le nombre de répertoires peut lui-même devenir très grand.
Il utilise donc un découpage à deux niveaux, les répertoires du deuxième niveau étant répartis dans les
répertoires du premier niveau. Le premier nombre spécifié dans l’option cache_dir indique le nombre
de répertoires du premier niveau, et le deuxième nombre indique le nombre de sous-répertoires dans
chacun de ces répertoires. En général, on utilise respectivement les valeurs 16 et 256 :

cache_dir /var/squid/cache 100 16 256

Cette ligne permet de cacher 100 Mo, en répartissant les objets dans 4096 répertoires répartis en 16
groupes de 256 répertoires.
Les options suivantes spécifient les paramètres réseau du cache :

• l’option http_port indique le port TCP que les clients doivent utiliser pour accéder au proxy ;
• l’option ftp_user permet de donner l’adresse email à utiliser comme mot de passe dans les
connexion FTP anonymes ;
• l’option cache_peer permet d’intégrer le proxy local dans une hiérarchie de proxies.
Les proxies peuvent en effet être organisés dans une structure arborescente. Lorsqu’un proxy d’un
niveau ne dispose pas d’une donnée demandée par un client, il peut contacter ses frères pour le cas où
ceux-ci auraient cette donnée dans leurs caches, ou demander à son proxy père de récupérer cette
donnée pour lui. Les proxies communiquent entre eux en utilisant un protocole dédié, le protocole ICP
(abréviation de l’anglais « Inter Cache Protocol »).

307
 Chapitre 9. Configuration du réseau

En général, les petits réseaux ne disposent que d’un seul proxy, l’option cache_peer est donc
souvent utilisée de la manière suivante :
cache_peer père parent port port_icp options

où père est le nom du cache père, port est son port, port_icp est le port à utiliser pour les
communications ICP, et options sont des options complémentaires. Parmi toutes les options
possibles, on utilisera le plus souvent l’option default, qui spécifie les valeurs par défaut des
options, et no-query, qui permet de dire au cache de ne pas utiliser le protocole ICP (dans ce cas, le
paramètre port_icp sera inutilisé) ;

• L’option prefer_direct permet d’indiquer au proxy s’il doit chercher avant tout à récupérer
lui-même les données qui lui manquent (valeur on) ou s’il doit contacter d’abord son proxy père
(valeur off). Si l’on a spécifié un proxy père à l’aide de l’option cache_peer, on aura intérêt à
utiliser la valeur off ;
• L’option dns_children permet de donner le nombre de processus en charge de cacher les requêtes
sur les DNS. squid peut en effet lancer des serveurs de cache de DNS permettant d’optimiser les
temps d’accès aux pages Web. Plus le réseau local est important, plus il faudra de tels processus, afin
que tous les clients puissent obtenir les adresses IP des machines à partir de leur noms. La valeur par
défaut est de 5 processus, ce qui devrait convenir dans la plupart des cas.
Les valeurs données par défaut à toutes ces options conviennent dans la plupart des cas. Elles sont
parfaitement documentées dans le fichier de configuration [Link].
Par défaut, squid n’autorise personne à accéder au cache. Il est donc nécessaire de donner les droits
nécessaires pour permettre aux machines de votre réseau d’accéder au cache. La gestion de la sécurité se
fait par l’intermédiaire de ce que l’on appelle des ACL (abréviation de l’anglais « Access Control List »).
Une ACL est simplement un critère permettant de classifier les requêtes que le proxy reçoit. Ces critères
sont définis à l’aide du mot clé acl, suivi du nom de la liste, suivi lui-même d’un critère que toutes les
requêtes concernées par cette ACL devront vérifier. Les critères sont eux-mêmes exprimés à l’aide d’un
mot clé qui indique sur quoi porte le critère et des options de ce critère. Les principaux mots clés que
vous pourrez utiliser sont les suivants :

• src, qui permet de filtrer les requêtes par les adresses des machines qui les ont émises, en indiquant
l’adresse de leur réseau, donnée sous la forme adresse/masque ;
• dst, qui permet de filtrer les requêtes par leurs adresses destination ;
• port, qui permet de sélectionner les requêtes s’adressant sur les ports fournis en paramètres ;
• proto, qui permet de spécifier la liste des protocoles utilisés par les requêtes ;
• method, qui permet de sélectionner les requêtes HTTP par la méthode utilisée dans la requête.

Ce tableau n’est pas exhaustif, mais il permet d’avoir une idée des capacités de filtrage des requêtes dont
dispose squid. Vous trouverez ci-dessous quelques exemples pratiques de définitions d’ACL :

# ACL caractérisant toutes les machines :

acl all src [Link]/[Link]

# ACL définissant la machine locale :

308
 Chapitre 9. Configuration du réseau

acl localhost src [Link]/[Link]

# ACL définissant les machines d’un réseau privé local :

acl localnet src [Link]/[Link]

# ACL caractérisant le proxy lui-même :

acl manager proto cache_object

# ACL spécifiant les ports acceptés par le proxy :

acl safe_ports port 80 21 443 563 70 210 1025-65535

# ACL définissant les requêtes de connexion :

acl connect method CONNECT

La définition des règles de sécurité utilise les ACL de manière séquentielle. Les règles doivent être
données les unes après les autres, suivant le format suivant :

ressource politique ACL

où ressource est un mot clé indiquant la ressource sur laquelle la règle de sécurité porte, politique
est l’action prise pour les requêtes vérifiant cette règle, et ACL une liste d’ACL permettant de spécifier les
requêtes concernées par cette règle. La ressource la plus utilisée est sans doute le protocole HTTP, que
l’on peut spécifier à l’aide du mot clé http_access. Les actions peuvent être l’acceptation (mot clé
allow) ou le refus (mot clé deny) de la requête. Enfin, les requêtes concernées par une règle sont celles
qui appartiennent à toutes les ACL de la liste d’ACL indiquée.
Vous trouverez ci-dessous quelques exemples de règles de sécurité courantes :

# Autorise les accès au gestionnaire de cache local :

http_access allow manager localhost

# Interdit les accès aux gestionnaires de cache étrangers :

http_access deny manager

# Interdit les accès pour toutes les requêtes provenant de port non autorisés :
http_access deny !safe_ports
http_access deny connect !safe_ports

# Autorise les accès aux clients de la machine locale :

http_access allow localhost

# Autorise les accès aux machines du réseau local :

http_access allow localnet

# Politique par défaut :

http_access deny all

Notez que si une requête ne correspond à aucune règle, la politique par défaut utilisée par squid est de
prendre l’action opposée à la dernière règle spécifiée. En pratique, il est plus sage de toujours indiquer

309
 Chapitre 9. Configuration du réseau

une politique par défaut pour toutes les requêtes restantes, par exemple en utilisant l’ACL all définie
ci-dessus.
L’exemple de jeu de règles de sécurité donné ci-dessous convient pour un réseau local d’adresses
[Link]. Vous pouvez bien entendu modifier les options de sécurité comme bon vous semble. Encore
une fois, rappelons que le fichier de configuration de squid est très bien documentée et que sa lecture est
relativement facile. Je ne saurais que trop vous recommander de le consulter si vous désirez en savoir
plus.

Pare-feu et partages de connexion à Internet

Supposons qu’une machine située sur un réseau local ait accès à Internet. Il peut être intéressant de faire
en sorte que les autres machines du réseau puissent également y accéder, en utilisant cette machine
comme passerelle. Cela est parfaitement réalisable et ne pose aucun autre problème que la définition des
règles de routage si toutes les machines ont une adresse IP attribuée par l’IANA. Cependant, cela est
rarement le cas, car les réseaux locaux utilisent normalement les adresses réservées à cet usage, qui ne
sont pas routables sur Internet. Dans ce cas, il est évident que les machines du réseau local ne pourront
pas envoyer de paquets sur Internet, et qu’a fortiori elles ne recevront jamais de paquets provenant
d’Internet. Heureusement, il existe une technique nommée masquerading, basée sur un mécanisme de
translation d’adresse (« NAT » en anglais, abréviation de « Network Address Translation »), qui permet
de modifier les paquets émis à destination d’Internet à la volée afin de pouvoir partager une connexion
Internet même avec des ordinateurs qui utilisent des adresses locales. Comme nous allons le voir,
partager une connexion à Internet avec d’autre ordinateurs d’un réseau local est un jeu d’enfant sous
Linux grâce à cette technique.
Il faut toutefois bien se rendre compte que le fait que fournir un accès à Internet à un réseau local pose
des problèmes de sécurité majeurs. Pour des réseaux locaux familiaux, les risques de piratages sont bien
entendu mineurs, mais lorsque la connexion à Internet est permanente ou lorsque les données circulant
sur le réseau local sont sensibles, il faut tenir compte des risques d’intrusion. Lorsqu’on utilise des
adresses IP dynamiques, il est relativement difficile d’accéder à des machines du réseau local, sauf si la
passerelle expose des services internes au reste du réseau. En revanche, si les adresses utilisées sont fixes
et valides sur Internet, le risque devient très important. Par ailleurs, une machine Linux connectée sur
Internet ouvre toujours des ports indésirés, même si elle est bien configurée. Par exemple, il est
impossible d’empêcher le serveur X d’écouter les demandes de connexion provenant d’Internet, même
s’il est configuré pour toutes les refuser. La configuration d’un ordinateur connecté à Internet doit donc
se faire avec soin dans tous les cas, et l’installation d’un pare-feu est plus que recommandée (un
« pare-feu », ou « firewall » en anglais, est un dispositif qui consiste à protéger un réseau local du « feu
de l’enfer » d’Internet, sur lequel tous les crackers sont supposés grouiller).
Les paragraphes suivants exposent les mécanismes de filtrage de paquets réseau de Linux, qui sont
utilisées tant pour définir les règles de protection contre les intrusions indésirables sur un réseau par
l’intermédiaire d’une passerelle que pour effectuer des traitements sur les paquets. Cependant, de tous
ces traitements, nous ne verrons que la translation d’adresse, car c’est sans doute celui que la plupart des
gens cherchent à utiliser.

310
 Chapitre 9. Configuration du réseau

Mécanismes de filtrage du noyau

Linux est capable de filtrer les paquets circulant sur le réseau et d’effectuer des translations d’adresses
depuis la version 2.0. Cependant, les techniques utilisées ont été profondément remaniées dans la version
2.4.0 du noyau, et une architecture extensible a été mise en place et semble répondre à tous les besoins de
manière simple : Netfilter.
Netfilter est simplement une série de points d’entrée dans les couches réseau du noyau au niveau
desquels des modules peuvent s’enregistrer afin d’effectuer des contrôles ou des traitements particuliers
sur les paquets. Il existe une entrée en chaque point clé du trajet suivi par les paquets dans les couches
réseau du noyau, ce qui permet d’intervenir de manière souple et à n’importe quel niveau. Un certain
nombre de modules permettant d’effectuer les traitements les plus courants sont fournis directement dans
le noyau, mais l’architecture Netfilter est suffisamment souple pour permettre le développement et l’ajout
des modules complémentaires qui pourraient être développés par la suite.
Les fonctionnalités fournies par ces modules sont regroupées par domaines fonctionnels. Ainsi, les
modules permettant de réaliser des pare-feu se chargent spécifiquement de donner les moyens de filtrer
les paquets selon des critères bien définis, et les modules permettant d’effectuer des translations
d’adresses ne prennent en charge que la modification des adresses source et destination des paquets à la
volée. Afin de bien les identifier, ces fonctionnalités sont regroupées dans ce que l’on appelle des tables.
Une table n’est en fait rien d’autre qu’un ensemble cohérent de règles permettant de manipuler les
paquets circulant dans les couches réseau du noyau pour obtenir une fonctionnalité bien précise. Les
tables les plus couramment utilisées sont les tables « filter », « mangle » et « nat », qui permettent
respectivement de réaliser des pare-feu, de marquer les paquets pour leur appliquer un traitement
ultérieur, et d’effectuer des translations d’adresses.
Les différentes tables de NetFilter s’abonnent chacune aux points d’entrée qui sont nécessaires pour
implémenter leur fonctionnalité, et les paquets qui passent au travers de ces points d’entrée doivent
traverser les règles définies dans ces tables. Afin de faciliter la définition des règles stockées dans les
tables, les règles sont regroupées dans des listes de règles que l’on appelle communément des chaînes.
Chaque table dispose donc toujours d’une chaîne de règles prédéfinie pour chacun des points d’entrée de
Netfilter qu’elle utilise. L’utilisateur peut bien entendu définir de nouvelles chaînes et les utiliser dans les
chaînes prédéfinies, ces chaînes apparaissent alors simplement comme des sous-programmes des chaînes
prédéfinies.
Les règles des tables de Netfilter permettent de spécifier les paquets qui les vérifient, selon des critères
précis, comme par exemple leur adresse source ou le type de protocole qu’ils transportent. Les règles
indiquent également les traitements qui seront appliqués à ces paquets. Par exemple, il est possible de
détruire purement et simplement tous les paquets provenant d’une machine considérée comme non sûre
si l’on veut faire un pare-feu. On pourra aussi envoyer ces paquets dans une autre chaîne, qui peuvent
indiquer d’autres règles et d’autres traitements.
Les critères de sélection de paquets des règles de filtrage se basent sur les informations de l’en-tête de
ces paquets. Rappelez-vous que chaque paquet de données émis sur le réseau transporte avec lui des
informations nécessaires au fonctionnement dudit réseau, entre autres les adresses source et destination
du paquet. Ce sont sur ces informations que la sélection des paquets est effectuée dans Netfilter. Dans le
cas d’un protocole encapsulé dans un autre protocole, comme par exemple un paquet TCP dans un
paquet IP, les informations du protocole encapsulé peuvent également être utilisées, si l’on a chargé des
modules complémentaires dans NetFilter. Par exemple, le numéro de port TCP peut faire partie des
critères de sélection d’une règle et donc de différencier le trafic des différents services réseau.
Les traitements que l’on peut appliquer à un paquet sont également fournis par des modules de Netfilter.

311
 Chapitre 9. Configuration du réseau

Les traitements les plus simples sont bien entendus fournis en standard avec le noyau. En général, on
peut chercher à réaliser les opérations suivantes sur un paquet :

• l’enregistrer, pour analyse ultérieure ;

• le rediriger vers un port local, pour traitement par un programme dédié (par exemple, par un serveur
proxy) ;
• l’accepter, l’abandonner ou le rejeter directement (le rejet se distingue de l’abandon par l’émission
d’une notification « hôte inaccessible » à la machine ayant émis le paquet) ;
• le modifier et, en particulier, effectuer une translation d’adresse ou le marquer pour le reconnaître dans
un traitement ultérieur ;
• l’envoyer dans une autre chaîne pour effectuer des vérifications complémentaires ;
• le faire sortir immédiatement de la chaîne courante.
De plus, les statistiques tenues par le noyau pour la règle ainsi vérifiée sont mises à jour. Ces statistiques
comprennent le nombre de paquets qui ont vérifié cette règle ainsi que le nombre d’octets que ces
paquets contenaient.
Lorsqu’un paquet arrive à la fin d’une chaîne (soit parce qu’il n’a pas été rejeté ou détruit par une règle
de filtrage de pare-feu, soit parce qu’il ne correspond aux critères d’aucune règle, ou soit parce qu’il est
arrivé à ce stade après avoir subi des modifications), le noyau revient dans la chaîne appelante et poursuit
le traitement du paquet. Si la chaîne au bout de laquelle le paquet arrive est une chaîne prédéfinie, il n’y a
plus de chaîne appelante, et le sort du paquet est déterminé par ce qu’on appelle la politique de la chaîne
prédéfinie. La politique (« policy » en anglais) des chaînes prédéfinies indique donc ce que l’on doit faire
avec les paquets qui arrivent en fin de chaîne. En général, on utilise une politique relativement stricte
lorsqu’on réalise un pare-feu, qui rejette par défaut tous les paquets qui n’ont pas été acceptés
explicitement par une règle de la chaîne.

Note : Certains paquets peuvent être découpés en plusieurs paquets plus petits lors de la traversée
d’un réseau. Par exemple, un paquet TCP un peu trop gros et initialement encapsulé dans un seul
paquet IP peut se voir éclaté en plusieurs paquets IP. Cela peut poser quelques problèmes aux
règles de filtrage, puisque dans ce cas les données spécifiques à TCP (par exemple les numéros de
ports) ne sont disponibles que sur le premier paquet IP reçu, pas sur les suivants. C’est pour cette
raison que le noyau peut effectuer une « défragmentation » des paquets lorsque cela est nécessaire,
et que les paquets transmis par la passerelle ne sont pas toujours strictement identitiques aux
paquets qu’elle reçoit.

Translations d’adresses et masquerading

Nous avons vu que grâce aux mécanismes de filtrage du noyau, il est possible de modifier les paquets à la
volée. Il peut être intéressant de modifier un paquet pour diverses raisons, les trois plus intéressantes
étant sans doute de le marquer à l’aide d’un champ spécial dans son en-tête afin de le reconnaître
ultérieurement, de modifier sa priorité pour permettre un traitement privilégié ou au contraire placer en
arrière plan ce type de paquet (libérant ainsi les ressources réseau pour d’autres types de connexion), et
de modifier ses adresses source et destination, pour effectuer une translation d’adresse. Nous allons nous

312
 Chapitre 9. Configuration du réseau

intéresser plus particulièrement aux différentes formes de translations d’adresses dans la suite de cette
section.
Une translation d’adresse n’est en fait rien d’autre qu’un remplacement contrôlé des adresses source ou
destination de tous les paquets d’une connexion. En général, cela permet de détourner les connexions
réseau ou de simuler une provenance unique pour plusieurs connexions. Par exemple, les connexions à
Internet peuvent être détournées vers un proxy fonctionnant sur la passerelle de manière transparente, en
modifiant les adresses destination des paquets émis par les clients. De même, il est possible de simuler un
seul serveur en remplaçant à la volée les adresses source des paquets que la passerelle envoie sur Internet.
On distingue donc deux principaux types de translations d’adresses : les translations d’adresse source et
les translations d’adresse destination. Parmi les translations d’adresse source se trouve un cas particulier
particulièrement intéressant : le « masquerading ». Cette technique permet de remplacer toutes les
adresses source des paquets provenant des machines d’un réseau local par l’adresse de l’interface de la
passerelle connectée à Internet, tout en conservant une trace des connexions réseau afin d’acheminer vers
leur véritable destinataire les paquets de réponse. Ainsi, une seule connexion à Internet peut être utilisée
par plusieurs machines distinctes, même si elles ne disposent pas d’adresses IP fournies par l’IANA.
Lorsqu’une machine du réseau local envoie un paquet à destination d’Internet, ce paquet est acheminé
vers la passerelle, qui est la route par défaut. Celle-ci commence par modifier l’adresse source de ce
paquet et mettre sa propre adresse à la place, puis le transfère vers la machine du fournisseur d’accès.
Tous les paquets émis par les machines du réseau local semblent donc provenir de cette passerelle, et
seront acheminés normalement à destination. En fait, la complication provient des paquets de réponse,
puisque les machines situées sur Internet croient que la machine avec laquelle elles communiquent est la
passerelle. Ces paquets sont donc tous envoyés à la passerelle directement, et celle-ci doit retrouver la
machine du réseau local à laquelle ils sont destinés. Cette opération est réalisée de différentes manières
selon les protocoles utilisés, et elle suppose que la passerelle conserve en permanence une trace des
connexions réseau effectuées par les machines du réseau local.
Pour TCP, ce suivi de connexion est réalisé en modifiant également le port source des paquets provenant
des machines locales. La passerelle utilise un port unique pour chaque connexion, qui va lui permettre de
retrouver la machine à laquelle un paquet est destiné lorsqu’elle en reçoit un provenant d’Internet. Par
exemple, si une machine locale fait une connexion à Internet, la passerelle alloue un nouveau numéro de
port pour cette connexion et modifie tous les paquets sortants comme ayant été émis par la passerelle
elle-même, sur ce port. Lorsque l’autre machine prenant part à la connexion, située sur Internet, envoie
un paquet de réponse, celui-ci sera à destination de la passerelle, avec comme port destination le port
alloué à cette connexion. La passerelle peut donc retrouver, à partir de ce port, l’adresse de la machine
destination réelle, ainsi que le port source que cette machine utilisait initialement. La passerelle modifie
donc ces deux champs du paquet, et le renvoie sur le réseau local. Finalement, la machine destination
reçoit le paquet sur son port, et ce paquet semble provenir directement d’Internet, comme si la connexion
avait été directe. Notez bien que la passerelle ne modifie pas les adresses source des paquets provenant
d’Internet, elle ne fait que les réacheminer vers la bonne destination.

313
 Chapitre 9. Configuration du réseau

Figure 9-7. Translation d’adresses avec suivi de port TCP

Ainsi, le masquerading est un mécanisme complètement transparent pour les machines du réseau local.
En revanche, pour les machines de l’Internet, il ne semble y avoir qu’un seul interlocuteur : la passerelle.
Celle-ci utilise des numéros de ports variés, mais cela ne les regarde pas. Les machines du réseau local
sont donc complètement « masquées » par la passerelle, d’où le nom de masquerading.
Tout ce travail effectué par la passerelle nécessite un traitement spécifique sur chaque paquet qu’elle
achemine, et consomme bien entendu des ressources système. Cependant, les débits utilisés pour les
connexions à Internet, même les plus rapides, sont très loin de mettre à genoux une passerelle sous
Linux, même sur les plus petites machines (386 et 486). Vous voilà rassurés, et peut-être aurez-vous
trouvé d’ici peu une utilité à l’un de ces dinosaures qui traînent encore dans votre garage...

Trajet des paquets dans le code de Netfilter

Il existe cinq points d’entrée au total pour les modules de Netfilter dans le code des couches réseau IP de
Linux. À chacun de ces points d’entrée, les paquets sont soumis aux différentes chaînes des tables qui s’y
intéressent. Comme on l’a déjà dit plus haut, chaque table dispose d’une chaîne prédéfinie pour chacun
des points d’entrée auxquels elle s’intéresse. Le nom de ces chaînes prédéfinies est le nom du point
d’entrée au niveau duquel elles sont appelées. Les paragraphes suivants décrivent ces cinq points
d’entrée, ainsi que l’ordre dans lequel les chaînes des différentes tables sont traversées par les paquets.
Les paquets réseau provenant de l’extérieur sont d’abord contrôlés par le noyau afin de détecter les
erreurs les plus simples. Les paquets mal formés ou corrompus sont systématiquement éliminés à ce
niveau, avant même d’atteindre le code de Netfilter. Les autres paquets commencent alors leur trajet dans
les couches de plus haut niveau. C’est à ce moment là qu’ils rencontrent le point d’entrée PREROUTING.
Les règles des chaînes PREROUTING des tables mangle et nat sont appliquées à ce moment. Ces chaînes
précèdent le code de routage, qui est en charge de déterminer le trajet que le paquet devra suivre par la
suite à partir de l’adresse destination des paquets. C’est donc dans ces chaîne que l’on pourra entre autres

314
 Chapitre 9. Configuration du réseau

modifier l’adresse destination des paquets, si l’on veut faire une translation d’adresse destination. Cette
opération se fait typiquement dans la table nat.
Les paquets qui passent le point d’entrée PREROUTING sont ensuite orientés par le code de routage de
Linux. S’ils sont à destination de la machine locale, ils rencontrent un autre point d’entrée : le point
d’entrée INPUT. Les règles des chaînes INPUT des tables mangle et filter sont exécutées à ce
moment. C’est donc à ce niveau que l’on peut empêcher un paquet d’entrer dans le système, ce qui se fait
naturellement dans la table filter.
Les autres paquets doivent être transférés vers une autre machine, souvent par une autre interface réseau.
Ils atteignent donc le point d’entrée FORWARD. Ce point d’entrée permet de contrôler les paquets qui
transitent au travers d’une passerelle. Les paquets y traversent les chaînes FORWARD des tables mangle et
filter, cette dernière étant justement dédiée au filtrage des paquets qui transitent par la passerelle.

Les paquets qui sont acceptés par les chaînes FORWARD retournent ensuite dans le code de routage du
noyau, afin de déterminer l’interface réseau par laquelle ils doivent être réémis. Une fois cela réalisé, ils
sont prêts à être réémis, mais ils doivent auparavant traverser les chaînes des tables abonnées au point
d’entrée POSTROUTING. Il s’agit bien sûr des chaînes POSTROUTING des tables mangle et nat. C’est
dans cette dernière chaîne que se font les translations d’adresse source.
Enfin, les paquets émis par la machine locale à destination de l’extérieur doivent impérativement passer
par le point d’entrée OUTPUT, qui exécute les chaînes OUTPUT des tables mangle, nat et filter. C’est
donc à ce niveau que l’on pourra modifier les adresses destination des paquets de la machine locale avant
leur routage et effectuer le filtrage des paquets sortants, dans les chaînes OUTPUT des tables nat et
filter. Les paquets qui se révèlent avoir le droit de sortir traversent alors de code de routage, puis, tout
comme les paquets qui ont été transférés, passent par le point d’entrée POSTROUTING.

Figure 9-8. Trajet des paquets dans le code de filtrage

Configuration du noyau et installation des outils

Les fonctionnalités de Netfilter sont toutes fournies par le noyau lui-même, aussi leur configuration
doit-elle se faire au niveau du noyau. La manière de procéder pour configurer le noyau a été indiquée
dans le paragraphe traitant de la compilation du noyau. Les options à activer pour mettre en place les
fonctionnalités de filtrage des paquets et de translation d’adresse sont les suivantes :

• « Network packet filtering (replace ipchains) », pour activer les fonctionnalités de

filtrage des paquets en général ;

315
 Chapitre 9. Configuration du réseau

• « Network packet filtering debugging », pour obtenir les messages de débogage du noyau.
Ces messages peuvent être très utiles pour mettre au point les règles de filtrage ;
• « Connection tracking (required for masq/NAT) » (menu « IP: Netfilter Configuration »),
pour permettre le suivi des connexions auxquelles appartiennent les paquets IP reçus par la passerelle.
Cette option est nécessaire pour réaliser un partage de connexion à Internet ;
• « FTP protocol support », pour permettre la gestion des connexions FTP, qui exigent un
traitement particulier pour les translations d’adresses ;
• « IP tables support (required for filtering/masq/NAT) », pour permettre la gestion
des tables de Netfilter ;
• « Packet filtering », pour inclure le support de la table « filter ». Cette option est nécessaire pour
réaliser un pare-feu ;
• « REJECT target support », pour permettre le rejet des paquets (par défaut, seul l’abandon des
paquets est fourni dans le code de filtrage) ;
• « Full NAT », pour inclure la table « nat » de Netfilter. Cette option est nécessaire pour réaliser un
partage de connexion à Internet ;
• « MASQUERADE target support », pour permettre le masquerading afin de réaliser un partage de
connexion à Internet.

Vous devrez ensuite compiler le noyau et les modules, et les installer comme indiqué dans la partie
traitant de la compilation du noyau.

Note : Le noyau de Linux dispose d’un paramètre global permettant de contrôler le routage des
paquets IP d’une interface réseau à une autre. Par défaut, ce paramètre est à 0, ce qui implique que
la transmission des paquets ne sera pas autorisée. Il faut donc activer ce paramètre à chaque
démarrage afin de pouvoir utiliser votre passerelle Linux. Cela peut être réalisé en écrivant la valeur
1 dans le fichier /proc/sys/net/ipv4/ip_forward du système de fichiers virtuel /proc/ :

echo "1" > /proc/sys/net/ipv4/ip_forward

La manipulation des chaînes et la manipulation des règles de Netfilter se fait grâce à l’outil iptables.
Cette commande doit normalement avoir été installée par votre distribution. Toutefois, si ce n’est pas le
cas, vous pouvez la compiler manuellement. Pour cela, il vous faudra récupérer l’archive des sources
d’iptables. Cette archive peut être trouvée sur Internet
([Link] La version courante est la 1.2.9, aussi l’archive se
nomme-t-elle [Link].bz2.
L’installation d’iptables ne pose pas de problème particulier en soi. Vous devrez d’abord décompresser
l’archive avec les deux commandes suivantes :

bunzip2 [Link].bz2
tar xf [Link]

316
 Chapitre 9. Configuration du réseau

puis modifier le fichier Makefile pour définir les répertoires d’installation dans les variables LIBDIR,
BINDIR et MANDIR. En général, les répertoires utilisés seront respectivement les répertoires
/usr/lib/, /usr/bin/ et /usr/man/. Une fois cela fait, il ne restera plus qu’à compiler le tout avec
la commande make et à faire l’installation avec la commande make install.

Utilisation d’iptables
Il est possible, grâce à iptables, d’effectuer toutes les opérations d’administration désirées sur les chaînes
des tables de Netfilter. Vous pourrez donc créer des nouvelles chaînes, les détruire, définir les politiques
par défaut, ainsi que manipuler les règles de ces chaînes (en ajouter, en supprimer ou en remplacer une).
En fait, iptables dispose d’un grand nombre d’options, et seules les options les plus importantes seront
présentées ici. Vous pouvez lire la page de manuel iptables si vous désirez plus de renseignements sur
la manipulation des chaînes et des règles de filtrage du noyau.

Manipulation des chaînes

Toutes les options peuvent être utilisées avec toutes les tables gérées par le noyau. La table sur laquelle
une commande s’applique peut être précisée à l’aide de l’option -t. Si cette option n’est pas fournie, la
table utilisée par défaut sera la table filter, qui est celle qui est normalement utilisée pour définir des
règles de filtrage des paquets dans un pare-feu.
La création d’une nouvelle chaîne se fait simplement avec l’option -N :

iptables [-t table] -N chaîne

où chaîne est le nom de la chaîne à créer. Il est interdit d’utiliser un des mots clés réservés par iptables.
En pratique, il est recommandé d’utiliser des noms de chaînes en minuscules, car les chaînes prédéfinies
sont en majuscules.
Une chaîne peut être détruite avec l’option -X :

iptables [-t table] -X chaîne

Une chaîne ne peut être détruite que lorsqu’elle ne contient plus de règle. De plus, il est impossible de
détruire les chaînes prédéfinies d’une table.
Vous pouvez lister l’ensemble des règles d’une chaîne avec l’option -L :

iptables [-t table] -L chaîne

Enfin, il est possible de supprimer toutes les règles d’une chaîne avec l’option -F :

iptables [-t table] -F chaîne

où chaîne est le nom de la chaîne dont on veut supprimer les règles.

317
 Chapitre 9. Configuration du réseau

Manipulation des règles

La syntaxe générale pour ajouter une règle dans une chaîne est la suivante :

iptables [-t table] -A chaîne [-s source] [-d destination] [-p protocole]
[-i itfsource] [-o itfdest] [-j cible]

où :

• table est la table dans laquelle se trouve la chaîne manipulée (par défaut, il s’agit de la table
filter) ;

• chaîne est le nom de la chaîne à laquelle la règle doit être ajoutée ;

• source est l’adresse source du paquet ;
• destination est l’adresse destination du paquet ;
• protocole est le protocole du paquet (spécifié avec son numéro de port ou par le nom du protocole
tel qu’il est déclaré dans le fichier /etc/services) ;
• itfsource est le nom de l’interface réseau source par laquelle le paquet doit arriver ;
• itfdest est le nom de l’interface destination par laquelle le paquet doit sortir ;
• et cible est la cible des paquets qui vérifient les critères de sélection de la règle.
Chacun des paramètres placé entre crochets dans la syntaxe est facultatif, mais il faut au moins qu’un
critère de sélection soit donné (sur les adresses source ou destination, ou sur le port ou l’interface).
Les adresses source et destination peuvent être indiquées directement par le nom des machines (comme
par exemple « [Link] ») ou par leurs adresses IP. Vous pouvez spécifier directement toutes
les adresses d’un réseau avec la syntaxe « réseau/masque ». Il est également possible d’utiliser la syntaxe
« réseau/n », où « n » est le nombre de bits mis à 1 dans le masque de sous-réseau. Ainsi, réseau/24 est
équivalent à réseau/[Link], réseau/16 à réseau/[Link], etc. Par extension,
« réseau/0 » peut être utilisé pour spécifier toutes les adresses possibles (dans ce cas, l’adresse donnée
pour le réseau n’est pas prise en compte).
La cible détermine les opérations qui seront appliquées à ces paquets. Les cibles autorisées dépendent de
la chaîne dans laquelle la règle est ajoutée, ainsi que des modules de Netfilter qui ont été compilés. Les
principales cibles sont les suivantes :

• ACCEPT, pour accepter le paquet qui vérifie le critère de sélection de la règle ;

• DROP, pour éliminer purement et simplement le paquet ;
• REJECT, pour rejeter le paquet (en signalant l’erreur à la machine émettrice). Cette cible n’est
utilisable que dans les chaînes INPUT, FORWARD et OUTPUT, ainsi que dans les chaînes utilisateurs
appelées à partir de ces chaînes ;
• QUEUE, pour envoyer le paquet à un programme utilisateur capable de communiquer avec NetFilter ;
• RETURN, pour sortir de la chaîne immédiatement, ou appliquer la règle de la politique par défaut pour
les chaînes prédéfinies ;

318
 Chapitre 9. Configuration du réseau

• REDIRECT, pour rediriger le paquet sur une autre machine, souvent la machine locale. Cette cible n’est
utilisable qu’avec la table nat, car il s’agit d’une translation d’adresse. On ne peut l’utiliser que dans
les chaînes PREROUTING et OUTPUT et les chaînes utilisateur appelées à partir de ces chaînes ;
• SNAT, pour permettre la modification de l’adresse source du paquet. Cette cible n’est bien entendu
accessible qu’au niveau de la table nat. Comme la modification de l’adresse source n’a de
signification que pour les paquets devant sortir de la passerelle, cette cible ne peut être utilisée que
dans la chaîne POSTROUTING et les chaînes utilisateur appelées à partir de cette chaîne ;
• DNAT, pour effectuer la modification de l’adresse destination du paquet, afin par exemple de le
détourner vers une autre machine que celle vers laquelle il devait aller. Cette cible n’est accessible que
dans la table nat, et n’est utilisable que dans les chaînes PREROUTING et OUTPUT ainsi que dans les
chaînes utilisateur appelées à partir de ces chaînes ;
• MASQUERADE, pour effectuer une translation d’adresse sur ce paquet, dans le but de réaliser un partage
de connexion à Internet. Cette cible n’est accessible que dans la chaîne POSTROUTING de la table nat,
ainsi que dans les chaînes utilisateur appelées à partir de cette chaîne.
Toute autre spécification de destination doit être le nom d’une chaîne utilisateur, avec les règles de
laquelle le paquet devra être testé. Si aucune cible n’est spécifiée, aucune action n’est prise et la règle
suivante est traitée. Cependant, les statistiques de la règle sont toujours mises à jour.
La suppression d’une règle d’une chaîne se fait avec la commande suivante :

iptables -D chaîne numéro

où chaîne est la chaîne dont on veut supprimer la règle, et numéro est le numéro de la règle à
supprimer dans cette chaîne. Il est également possible d’utiliser l’option -D avec les mêmes options que
celles qui ont été utilisées lors de l’ajout de la règle, si l’on trouve cela plus pratique.
Enfin, la politique d’une chaîne, c’est-à-dire la cible par défaut, peut être fixée avec l’option -P :

iptables -P chaîne cible

où chaîne est l’une des chaînes prédéfinie, et cible est l’une des cibles ACCEPT ou DROP. Remarquez
que l’on ne peut pas définir de politique pour les chaînes créées par l’utilisateur, puisque les paquets sont
vérifiés avec les règles restantes de la chaîne appelante lorsqu’ils sortent de la chaîne appelée.

Exemple de règles
Ce paragraphe a pour but de présenter quelques-unes des règles les plus classiques. Le but est ici de
présenter les principales fonctionnalités d’iptables et de réaliser un pare-feu simpliste.

Exemple de règles de filtrage

Les règles de filtrage peuvent être utilisées pour mettre en place un pare-feu afin de protéger votre réseau.
La définition des règles de filtrage constitue bien souvent l’essentiel du problème, et nécessite bien
entendu de parfaitement savoir ce que l’on veut faire. De manière générale, la règle d’or en matière de
sécurité informatique est de tout interdire par défaut, puis de donner les droits au compte-gouttes. C’est
exactement ce que permet de faire la politique des chaînes. On définira donc toujours la politique par

319
 Chapitre 9. Configuration du réseau

défaut des chaînes pour utiliser la cible DROP. Cela peut être réalisé simplement avec les trois
commandes suivantes :

# Définition de la politique de base :

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Suppression des règles existantes :

iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT

Ces règles commencent par définir les politiques de base pour toutes les tables en blindant la machine
pour qu’elle ne laisse rien entrer, ne rien passer et ne rien sortir. Toutes les règles des tables sont ensuite
détruites. Dans ce cas, on ne craint plus rien, mais on ne peut plus rien faire non plus (pas même en
local). Aussi faut-il redonner les droits nécessaires pour permettre l’utilisation normale de votre système.
Le minimum est d’autoriser la machine à communiquer avec elle-même, ce qui implique d’autoriser les
paquets provenant de l’interface loopback à entrer et à sortir :

# Communications locales :
iptables -A INPUT -d [Link]/8 -i lo -j ACCEPT
iptables -A OUTPUT -s [Link]/8 -o lo -j ACCEPT

Si l’on dispose d’un réseau local, il peut également être utile d’autoriser toutes les connexions avec les
machines de ce réseau :

# Connexions au réseau local :

iptables -A INPUT -s [Link]/24 -i eth0 -j ACCEPT
iptables -A OUTPUT -s [Link] -o eth0 -j ACCEPT

Comme vous pouvez le constater, ces règles ne permettent l’entrée des paquets prétendant provenir du
réseau local (c’est-à-dire les paquets ayant comme adresse source une adresse de la forme
[Link]/24) que par l’interface réseau connectée au réseau local (dans notre exemple, il s’agit de
l’interface réseau eth0). De même, seule la machine locale (à laquelle l’adresse [Link] est
supposée être affectée) peut émettre des paquets sur le réseau local.
Notez que ces règles sont beaucoup trop restrictives pour permettre un accès à Internet (et, a fortiori une
intrusion provenant d’Internet...). Il est donc nécessaire d’autoriser les connexions vers les principaux
services Internet. Pour cela, il faut ajouter les lignes suivantes :

# Autorise les communications sortantes

# pour DNS, HTTP, HTTPS, FTP, POP, SMTP, SSH et IPSec :
iptables -A OUTPUT -o ppp0 -p UDP --dport domain -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport domain -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport http -j ACCEPT

320
 Chapitre 9. Configuration du réseau

iptables -A OUTPUT -o ppp0 -p TCP --dport https -j ACCEPT

iptables -A OUTPUT -o ppp0 -p TCP --dport ftp -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport pop3 -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport smtp -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --dport ssh -j ACCEPT
iptables -A OUTPUT -o ppp0 -p AH -j ACCEPT
iptables -A OUTPUT -o ppp0 -p ESP -j ACCEPT

Il est supposé ici que la connexion Internet se fait via le démon pppd, et que l’interface réseau que
celui-ci a créé se nomme ppp0.
Vous pouvez constater que les règles présentées jusqu’ici se basaient uniquement sur les adresses source
et destination des paquets, ainsi que sur les interfaces réseau par lesquelles ils entraient et ressortaient.
Vous voyez à présent que l’on peut réaliser des règles beaucoup plus fines, qui se basent également sur
les protocoles réseau utilisés (que l’on peut sélectionner avec l’option -p) et, pour chaque protocole, sur
des critères spécifiques à ces protocoles (comme les ports source et destination, que l’on peut
sélectionner respectivement avec les options --sport et --dport). Vous pouvez consulter la page de
manuel d’iptables pour plus de détails à ce sujet.
Certains protocoles requièrent plusieurs connexions TCP/IP pour fonctionner correctement. La
connexion est amorcée avec une première connexion, puis une deuxième connexion est établie après
négociation. C’est en particulier le cas pour le protocole FTP, qui utilise une connexion de contrôle et
une connexion pour le transfert des données. De plus, le protocole FTP peut fonctionner dans deux
modes distinct (respectivement le mode dit « actif » et le mode dit « passif »), selon que c’est le serveur
contacté qui établit la connexion de données ou que c’est le client qui l’établit vers le serveur. Ces
connexions additionnelles ne doivent bien entendu pas être filtrées, pour autant, on ne sait pas avec
précision le port qui sera choisi pour elles, car ce port fait partie de la négociation lors de l’établissement
de la connexion. Heureusement, Netfilter dispose d’un mécanisme de suivi de connexions capable
d’analyser les données protocolaires (si le protocole n’est pas chiffré, bien entendu). La solution est donc
de lui indiquer qu’il doit laisser les paquets relatifs aux connexions établies au niveau protocolaire. La
règle à utiliser est la suivante :

# Autorise l’établissement des connexions protocolaires additionnelles :

iptables -A OUTPUT -o ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Vous découvrez ici l’option --match, qui permet de sélectionner des paquets selon certains critères. Le
critère choisi ici est bien entendu l’état des connexions. Des options complémentaires peuvent être
fournis à ce critère à l’aide de l’option --state. Dans le cas présent, nous acceptons tous les paquets
sortants qui appartiennent à une connexion établie (paramètre « :ESTABLISHED ») ou qui a été amorcée à
partir d’une autre connexion déjà établie (paramètre « RELATED »).
Les règles précédentes permettent à la machine locale de se connecter à Internet, mais la connexion ne
s’établira malgré tout pas, car aucun paquet réponse n’a le droit d’entrer. Il est donc nécessaire
d’autoriser l’entrée des paquets réponse provenant des serveurs auxquels on se connecte. Toutefois, il ne
faut pas tout autoriser. Seuls les paquets relatifs aux connexions dont la machine locale est initiatrice
doivent être autorisés. Cela est réalisable encore une fois grâce au mécanisme de suivi de connexions de
Netfilter. Pour notre exemple, la simple règle suivante suffit :

# Autorise les paquets entrants pour les connexions

321
 Chapitre 9. Configuration du réseau

# que l’on a établies :

iptables -A INPUT -i ppp0 --match state --state ESTABLISHED,RELATED -j ACCEPT

Elle dit que les paquets entrants des connexions établies et des connexions relatives aux autres
connexions sont autorisés. Tous les autres paquets seront refusés.
Si vous désirez laisser un service ouvert vers Internet, vous devrez ajouter des règles complémentaires
qui autorisent les paquets entrant et sortant à destination du port de ce service. Par exemple, si vous
voulez laisser un accès SSH ouvert, vous devrez ajouter les deux règles suivantes :

# Autorise les connexions SSH entrantes :

iptables -A INPUT -i ppp0 -p TCP --dport ssh -j ACCEPT
iptables -A OUTPUT -o ppp0 -p TCP --sport ssh -j ACCEPT

Enfin, il peut être utile d’accepter certains paquets du protocole ICMP, qui permet de contrôler l’état des
liaisons. En particulier, il faut pouvoir recevoir les paquets indiquant qu’une machine n’est pas
accessible, faute de quoi certaines connexions impossibles risqueraient d’être très longues à détecter. De
plus, il peut être intéressant de pouvoir envoyer des demandes de réponse aux machines pour vérifier leur
présence. Les règles suivantes pourront donc être ajoutées :

# Autorise les paquets ICMP intéressants :

iptables -A OUTPUT -p ICMP --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p ICMP --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p ICMP --icmp-type destination-unreachable -j ACCEPT

Notez qu’il n’est théoriquement pas nécessaire de répondre aux paquets echo-request. Je vous ai
toutefois laissé les deux règles pour le cas où le fournisseur d’accès utiliserait ces requêtes pour
déterminer si la liaison reste correcte.

Exemple de partage de connexion à Internet

Le masquerading est un cas particulier de translation d’adresse source. En effet, celle-ci est couplée à un
suivi des connexions afin d’effectuer la translation d’adresse destination des paquets de réponse renvoyés
par les serveurs sur Internet pour les acheminer vers la machine du réseau local qui a initié la connexion.
En pratique, seule la chaîne POSTROUTING de la table nat sera utilisée pour le masquerading, parce que
c’est à ce niveau que la translation d’adresse est effectuée. La mise en œuvre du masquerading se fait
extrêmement simplement, puisqu’il suffit de spécifier que tous les paquets du réseau local sortant de
l’interface réseau connectée sur Internet doivent subir le masquerading. En général, l’interface de la
connexion à Internet est une interface PPP, aussi la règle à utiliser est-elle simplement la suivante :

# Effectue la translation d’adresses :

iptables -t nat -A POSTROUTING -s [Link]/24 -o ppp0 -j MASQUERADE

Cette règle permet de réaliser la translation des adresses des machines du réseau local et à destination
d’Internet. Remarquez que les paquets provenant de la machine locale ne subissent pas le masquerading,
car c’est complètement inutile.

322
 Chapitre 9. Configuration du réseau

Il faut ensuite autoriser les paquets provenant des machines du réseau local à traverser la passerelle. Cela
se fait avec des règles similaires à celles vues dans la section précédente, mais adaptées pour être
utilisées dans la chaîne FORWARD de la table filter :

# Autorise le trafic DNS, HTTP, HTTPS,

# FTP, POP, SMTP et SSH au travers de la passerelle :
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p UDP --dport domain -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport domain -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport http -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport https -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport ftp -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport pop3 -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport smtp -j ACCEPT
iptables -A FORWARD -s [Link]/24 -i eth0 -o ppp0 -p TCP --dport ssh -j ACCEPT

# Autorise l’établissement des connexions protocolaires additionnelles :

iptables -A FORWARD -s [Link]/24 -i eth0 -o eth0 --match state \
--state ESTABLISHED,RELATED -j ACCEPT

# Autorise le trafic en retour pour les connexions établies par les clients :
iptables -A FORWARD -i ppp0 -d [Link]/24 --match state \
--state ESTABLISHED,RELATED -j ACCEPT

# Autorise le trafic ICMP :

iptables -A FORWARD -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type echo-reply -j ACCEPT
iptables -A FORWARD -p ICMP --icmp-type destination-unreachable -j ACCEPT

Enfin, le routage des paquets étant, par défaut, désactivé sous Linux, il faut le réactiver. Si votre
distribution ne le fait pas, vous aurez donc également à ajouter une ligne telle que celle-ci :

# Activation du routage :
echo "1" > /proc/sys/net/ipv4/ip_forward

dans vos scripts de démarrage de votre système.

Certains routeurs et certaines passerelles d’Internet sont bogués et ne répondent pas correctement aux
messages ICMP. Cela a pour conséquence, entre autres, que la taille maximum des paquets transmis via
la passerelle peut ne pas être déterminée correctement. En effet, les clients de la passerelle utiliseront
généralement la taille maximum utilisable pour communiquer avec la passerelle, et cette taille peut
malheureusement être supérieure à la taille maximum des paquets pour atteindre certains sites Web. Les
messages d’erreurs ICMP étant filtrés, personne ne peut s’en apercevoir, et certaines connexions peuvent
rester bloquées ad vitam eternam. Pratiquement parlant, cela se traduit par l’impossibilité, pour certains
clients bénéficiant du partage de connexion à Internet, d’accéder à certains sites Web ou à certains gros
fichiers d’une page (images par exemple).
Pour pallier ce problème Linux propose une technique approximative, dont le but est de fixer une option
des paquets TCP d’établissement de connexion, afin de limiter la taille des paquets suivants de la
connexion à la taille maximum déterminée pour la route vers les ordinateurs cibles. Ainsi, les clients se
limitent d’eux-même, pourvu que la taille maximum des paquets de la route soit correctement

323
 Chapitre 9. Configuration du réseau

déterminée, bien entendu. Il est recommandé d’activer cette fonctionnalité, ce qui se fait à l’aide de la
commande suivante :

# Restreint la taille des paquets des connexions TCP

# lors de leur établissement :
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o ppp0 \
--clamp-mss-to-pmtu

Cette règle un peu compliquée permet de modifier le champ MSS (« Maximum Segment Size ») des
paquets d’établissement des connexions TCP (paquets disposant des flags TCP SYN ou RST) qui
traversent la passerelle, et de forcer ce champ à la valeur de la taille maximum des paquets sur le chemin
(« Path Maximum Transmission Unit » dans l’option --clamp-mss-to-pmtu).

Note : Les chaînes et leurs règles ne sont pas enregistrées de manière permanente dans le
système. Elles sont perdues à chaque redémarrage de la machine, aussi faut-il les redéfinir
systématiquement. Cela peut être réalisé dans les scripts de démarrage de votre système. Vous
pouvez également utiliser les commandes iptables-save et iptables-restore pour sauvegarder
toutes les chaînes et leurs règles dans un fichier et les restaurer au démarrage.
N’oubliez pas que votre passerelle doit définir une route par défaut pour que tous les paquets qui ne
sont pas destinés au réseau local soient envoyés par l’interface réseau connectée à Internet. Cette
route par défaut est établie automatiquement lorsque vous vous connectez à Internet à l’aide de
PPP. Dans les autres cas, vous aurez à la définir manuellement.

Configuration des clients

La configuration des autres machines du réseau est très simple. Vous devrez tout d’abord définir la
machine possédant la connexion à Internet comme passerelle par défaut de tous vos postes clients. Cette
opération peut se réaliser de différentes manière selon le système d’exploitation utilisé par ces machines.
Sous Linux, il suffit d’utiliser la commande suivante :

route add default gw passerelle eth0

où passerelle est l’adresse de votre passerelle vers Internet sur le réseau local. Cette commande
suppose que l’adaptateur réseau utilisé est eth0
La deuxième étape est ensuite de donner accès aux postes clients au DNS de votre fournisseur d’accès.
Cela permettra en effet d’utiliser les noms de machines autres que ceux de votre réseau local. Encore une
fois, la manière de procéder dépend du système utilisé. Sous Linux, il suffit d’ajouter les adresses IP des
serveurs de noms de domaine de votre fournisseur d’accès dans le fichier de configuration
/etc/[Link].

Si les clients ont des difficultés à accéder à certaines pages Web, c’est que le MTU (« Maximum
Transmission Unit », taille maximum des paquets réseau) est trop élevé. Ceci se corrige généralement tel
qu’on l’a indiqué dans la définition des règles de la passerelle. Toutefois, si les ordinateurs qui
bénéficient du partage de connexion à Internet continuent d’avoir des problèmes, c’est que le MTU de la
route permettant d’accéder aux sites Web posant problème n’a pas pu être déterminé correctement. Dans
ce cas, il faut le trouver soi-même, et le fixer dans la configuration réseau des clients. Pour cela, le plus

324
 Chapitre 9. Configuration du réseau

simple est d’utiliser la commande ping avec son option -s sur les clients, avec plusieurs tailles de
paquets possible. La taille maximum est de 1500 octets sur Ethernet. En général, une taille de 1400
octets convient :

ping -s 1400 adresse

Une fois le MTU correctement déterminé, il suffit de fixer cette valeur lors de la configuration des
interfaces réseau des clients :

ifconfig interface mtu taille

interface représente ici l’interface à configurer, et taille la taille maximum trouvée à l’aide de ping.

Note : La taille effective du MTU est en réalité la taille fournie à la commande ping plus vingt-huit
octets, car les paquets utilisés contiennent toujours l’en-tête ICMP en plus des données générées
par ping.

Configuration de la sécurité du réseau

La sécurité d’un réseau n’est pas quelque chose à prendre à la légère, surtout lorsqu’on commence à
transmettre des données personnelles sur le réseau. Internet n’est absolument pas sûr, car nombre de
personnes curieuses, peu discrètes ou franchement mal intentionnées ont un accès privilégié aux
machines qui s’y trouvent. Il est donc essentiel de prendre les problèmes sécuritaires très au sérieux,
d’autant plus que Linux est un système disposant d’un grand nombre de fonctionnalités serveur.
Bien qu’il soit impossible de réaliser un système sûr à 100%, la situation actuelle est franchement
catastrophique et si cela continue comme cela, la seule chose de sûre, c’est qu’on va aller droit dans le
mur. Entre ne rien faire du tout et se fixer un niveau de sécurité raisonnable permettant de limiter les
dégâts, il y a un grand pas. Cette section n’a donc pas pour but de vous transformer en expert en sécurité
(n’en étant pas un moi-même, je serais bien incapable d’en écrire une ayant cet objectif), mais de vous
présenter les principes de base et le minimum requis pour laisser les mauvaises surprises aux autres.
L’un des principes de base de la sécurité est de ne faire confiance à personne. Ce n’est pas un
comportement paranoïaque, mais simplement du bon sens : la plupart des surprises désagréables dans le
monde environnant proviennent du mauvais jugement des personnes. De plus, mêmes des personnes de
bonne foi peuvent être manipulées par un tiers sans qu’elles s’en rendent compte.
Partant de se constat, et quand bien même on serait capable de garantir la fiabilité d’un système à 100%,
il est nécessaire de limiter et de cloisonner les services fournis, et d’en restreindre l’accès aux personnes
habilitées. Cela est d’autant plus important que la plupart des démons ont besoin d’avoir les privilèges du
compte root pour s’exécuter. Cela peut être dramatique si d’aventure une personne mal intentionnée
découvrait le moyen de les détourner de leur fonction initiale et de leur faire accomplir des tâches au
nom de l’administrateur. Bien entendu, les démons sont des programmes très bien écrits, qui vérifient
généralement toutes les requêtes demandées par les clients avant de les satisfaire. Cependant, tout
programme peut comporter des failles et laisser ainsi un accès indésiré au sein du système. Autant
éliminer directement le problème en ne lançant que les services réellement nécessaires sur votre machine.

325
 Chapitre 9. Configuration du réseau

De plus, il va de soi que lorsqu’il y a un loup dans la bergerie, tout peut aller très mal très vite. La
sécurité doit donc être mise en place en profondeur, c’est-à-dire que l’on ne doit pas négliger la
sécurisation d’un réseau local sous prétexte qu’il est protégé par des dispositifs en amont. En effet, ces
dispositifs peuvent très bien être défaillants, et dans ce cas, l’intrus se retrouve directement en terrain
conquis. C’est pour cela qu’il faut prévoir plusieurs remparts pour se protéger.
En outre, rien n’est jamais figé dans le domaine de la sécurité. De nouvelles attaques sont développées
régulièrement, et de nouvelles failles sont découvertes dans les logiciels quasiment quotidiennement. Il
est donc nécessaire de réaliser un tant soi peu de veille et de mettre à jour les systèmes régulièrement.
Enfin, la sécurité ne peut se concevoir que dans un contexte global, en prenant compte l’environnement
dans lequel on se trouve. Il est tout à fait inutile d’utiliser des systèmes d’authentification par analyse de
code génétique pour protéger des documents ultra sensibles, si ces documents peuvent être sortis
simplement par les poubelles.
En résumé, les principes fondamentaux de la sécurité sont les suivants :

• il faut limiter le nombre des services lancés au strict minimum ;

• il faut en restreindre l’accès aux seules personnes autorisées ;
• il faut être proactif, se tenir au courant et mettre à jour les logiciels dès l’apparition des correctifs de
sécurité ;
• il faut prévoir plusieurs systèmes de sécurité ;
• il faut prendre en compte les problèmes de sécurité de manière globale.

De tous ces points, nous ne traiterons ici que ceux qui concernent un système de particulier. La mise à
jour des logiciels et des antivirus reste bien entendu extrêmement importante (surtout si des machines
Windows sont placées sur le réseau), mais n’appelle pas beaucoup de commentaires. La description de la
réalisation d’un pare-feu a également déjà été faite dans la section précédente. Nous ne présenterons
donc que la manière de limiter les services lancés et l’accès à ces services. Cela n’est toutefois pas
suffisant pour dormir tranquille car, et c’est sans doute là l’un des plus gros problèmes, la plupart des
protocoles réseau ne chiffrent pas leur données et laissent passer toutes les informations en clair sur le
réseau, y compris les mots de passe ! Nous verrons donc également les principales techniques de
cryptographies existantes afin de rendre les communications plus sûres.

Limitation des services et des accès

Réduction du nombre des services

Les services réseau d’un système Linux sont nombreux, mais la plupart du temps inutiles pour l’emploi
que l’on veut faire de son ordinateur. Par conséquent, il vaut mieux tout simplement ne pas les proposer
au monde extérieur, simplement en ne lançant pas les démons correspondants. Pour cela, il suffit de
commentant les lignes des services inutiles dans le fichier /etc/[Link] ou d’ajouter une ligne
« disable = true » dans les fichiers de configuration des services inutiles du répertoire
/etc/xinetd.d/ si votre distribution utilise le super-démon xinetd. Faire le ménage dans ces fichiers
et dans les fichiers d’initialisation du réseau réduit donc de 90% les risques d’une intrusion dans votre
système.

326
 Chapitre 9. Configuration du réseau

Définition de règles de contrôle d’accès

Restreindre le nombre de services accessibles n’est toutefois pas suffisant, il faut également restreindre le
nombre des personnes et des machines auxquels les services réseau restants sont proposés. Sur une
machine de particulier, l’équation est souvent simple : personne ne doit pouvoir s’y connecter par le
réseau, pour quelque service que ce soit ! Bien entendu, certains particuliers possèdent un réseau privé et
devront donc affiner cette règle pour ne permettre les connexions que sur le réseau local. Il faut donc être
capable d’empêcher les accès provenant de certaines machines, considérées comme peu fiables. La règle
est encore une fois très simple : doit être considérée comme dangereuse tout machine étrangère au réseau
local.
La manière de procéder dépend du super-démon utilisé. En effet, alors que xinetd permet de définir les
adresses des machines autorisées à se connecter de manière précise, inetd ne permet pas de le faire
lui-même et requiert l’aide d’un autre démon, le démon tcpd.

Restrictions d’accès avec tcpd

Le principe de fonctionnement du démon tcpd est le suivant : il s’intercale entre le super-démon inetd et
les démons que celui-ci est supposé lancer lorsqu’un client le demande. Ainsi, il lui est possible
d’effectuer des vérifications de sécurité primaires, principalement basées sur les adresses IP des clients.
Comme vous pouvez sans doute le constater dans le fichier /etc/[Link] de votre système, tcpd
est lancé par inetd pour quasiment tous les services, et reçoit en paramètres de la ligne de commande le
nom du démon à lancer si la machine cliente en a l’autorisation, ainsi que les paramètres à communiquer
à ce démon. L’accès à quasiment tous les services est donc contrôlé par tcpd.
tcpd utilise les deux fichiers de configuration /etc/[Link] et /etc/[Link] pour
déterminer si une machine a le droit d’accéder à un service donné. Le premier de ces fichiers indique
quelles sont les machines autorisées à utiliser certains services locaux. Le deuxième fichier indique au
contraire les machines qui ne sont pas considérées comme sûres et qui doivent se voir refuser toute
demande de connexion sur les services locaux.
Le format de ces deux fichiers est identique. Il est constitué de lignes permettant de définir les règles
d’accès pour certains démons. Chaque ligne utilise la syntaxe suivante :

démons : machines [: commande]

où démons est une liste de noms de démons, séparés par des virgules, et machines est une liste de noms
de machines ou d’adresses IP, également séparés par des virgules. commande est un paramètre optionnel
permettant de faire exécuter une action à tcpd lorsque la règle indiquée par cette ligne est prise en
compte.
Une règle définie par une de ces lignes est utilisée dès qu’une des machines indiquées dans la liste des
machines tente une connexion à l’un des services de la liste des services. Si la règle se trouve dans le
fichier /etc/[Link], la connexion est autorisée et le service est lancé par tcpd. Si elle se trouve
dans le fichier /etc/[Link], la connexion est systématiquement refusée. Si aucune règle n’est
utilisée, la connexion est acceptée par défaut.
Les listes de machines peuvent contenir des noms de machines partiels, et utiliser des caractères
génériques. Il est également possible d’interdire la connexion à toutes les machines d’un domaine en ne
donnant que le nom de domaine (précédé d’un point). Enfin, des mots clés spéciaux permettent de
représenter des ensembles de machines. Par exemple, le mot clé ALL représente toutes les machines et

327
 Chapitre 9. Configuration du réseau

LOCAL représente toutes les machines du réseau local. Le mot clé ALL permet également de représenter
l’ensemble des démons dans la liste des démons.
Par exemple, le fichier /etc/[Link] devrait contenir la ligne suivante :

# Exemple de fichier /etc/[Link] :

ALL : ALL

Cela permet de garantir que, par défaut, aucune demande de connexion n’est acceptée, ce qui est un
comportement sain. Les machines ayant le droit de se connecter doivent être spécifiées au cas par cas
dans le fichier /etc/[Link], comme dans l’exemple suivant :

# Exemple de fichier /etc/[Link] :

telnetd, ftpd : LOCAL

Cela permet d’autoriser les connexions telnet et ftp pour toutes les machines du réseau local uniquement.
Vous trouverez de plus amples renseignements sur le fonctionnement de tcpd dans la page de manuel
hosts_access(5).

Note : Comme vous pouvez le constater si vous comparez les lignes du fichier de configuration
/etc/[Link] utilisant tcpd et celles qui ne l’utilisent pas, la liste des paramètres passés à tcpd
par inetd est différente de celle utilisée pour les démons lancés directement. En effet, elle ne
comprend pas le nom de tcpd lui-même, alors que pour les démons, elle contient le nom du démon
en premier paramètre. Cette différence provient du fait que le premier argument passé en ligne de
commande est le nom du programme lui-même, sauf pour tcpd. En effet, tcpd suppose que ce
paramètre contient le nom du démon dont il contrôle l’accès, et non son propre nom.
La sécurité basée sur tcpd suppose que les adresses IP source des paquets reçus sont
effectivement les adresses IP des machines qui les ont envoyées. Malheureusement, cette
hypothèse ne peut pas être vérifiée pour les adresses autres que les adresses des réseaux
considérés comme sûrs (par exemple le réseau local), car le protocole IP n’inclut aucun mécanisme
d’authentification. Par conséquent, n’importe qui peut tenter de communiquer avec votre machine au
nom d’une autre machine (technique nommée « IP spoofing » en anglais), qu’il aura au préalable
mis hors d’état de se manifester (par exemple par une attaque de type DoS, « Denial of Service » en
anglais). tcpd tente par défaut de contrôler ce genre de pratique en vérifiant que le nom indiqué par
la machine qui se connecte correspond bien à l’adresse IP qu’elle utilise. Ainsi, pour passer cette
protection, il faut d’abord infecter un DNS. Cependant, ce genre d’attaque (dite d’interposition) reste
courant, surtout sur les réseaux dont les DNS sont insuffisamment protégés (une étude récente a
montré que c’était le cas de trois DNS sur quatre en France). Par conséquent, vous ne devez pas
vous reposer uniquement sur tcpd et les techniques de pare-feu si vous devez créer un site
réellement sûr. En particulier, vous devriez vous intéresser aux réseaux virtuels et au chiffrement
des données, choses que l’on décrira dans la la section intitulée Utilisation de SSH. Le protocole
Ipv6 intégrera des mécanismes d’authentification et sera donc nettement plus sûr. Bien entendu,
cela dépasse le cadre de ce document.
Le démon tcpd peut également être utilisé avec le démon xinetd. Toutefois, une telle utilisation est
superflue, étant donné que xinetd permet de définir ses propres règles de contrôle d’accès.

328
 Chapitre 9. Configuration du réseau

Restrictions d’accès avec xinetd

Le super-démon xinetd intègre d’office un mécanisme de contrôle d’accès similaire à celui utilisé par
tcpd. Grâce aux options only_from et no_access, il est possible de spécifier pour chaque service les
machines qui sont autorisées à l’utiliser, ou inversement les machines qui doivent être explicitement
rejetées.
Il faut toutefois prendre garde au fait que, comme pour tcpd, ne rien dire signifie accepter les connexions
provenant de toutes les machines. La règle d’or est donc, encore une fois, de tout interdire par défaut et
d’autoriser au compte-gouttes les accès aux services ouverts. Pour cela, il suffit d’ajouter la ligne
suivante :

only_from =

dans la section de définition des options par défaut de xinetd. Avec cette ligne, contrairement à ce qui se
passe si rien n’est spécifié, les accès ne sont autorisés qu’à partir d’aucune machine. Autrement dit, ils
sont toujours interdits.
Il faut ensuite redonner les droits sur les machines autorisées service par service. Ainsi, les connexions
par telnet peuvent être autorisées sur le réseau local (supposé sûr) grâce à la ligne suivante :

only_from += [Link]/24 [Link]

dans la section décrivant le service telnet de la configuration de xinetd.

On prendra garde également au fait que xinetd implémente quelques services internes permettant de
l’administrer par le réseau. Il est évident que ces services doivent être désactivés. Ces services sont
respectivement les services servers, sercices et xadmin. Leur désactivation se fait classiquement en
ajoutant la ligne suivante :

disabled = servers services xadmin

dans la section defaults du fichier de configuration /etc/[Link].

Contrôle des utilisateurs au niveau des services

Certains services ne peuvent pas être supprimés complètement, tout simplement parce que l’on peut en
avoir besoin. Dans ce cas, il faut au moins s’assurer que l’accès à ces services n’est autorisé que pour les
utilisateurs qui en ont réellement besoin. La règle est cette fois que l’utilisateur root ne doit pas avoir
accès aux services réseau par une connexion non locale. En effet, un pirate attaque toujours par le réseau
et, même s’il arrive à trouver le mot de passe d’un utilisateur normal, il lui restera encore pas mal de
boulot pour trouver le mot de passe de l’utilisateur root (attention cependant, si vous êtes dans cette
situation, il vaut mieux réagir très très vite).
Le service le plus sensible est bien entendu le service de login. Il est possible de fournir le service de
login aux connexions extérieures, et il est évident que cela constitue déjà un point d’entrée pour qui peut
trouver un mot de passe valide. Il est impératif ici d’interdire une telle connexion à l’utilisateur root. Il
reste toutefois concevable que cet utilisateur puisse se connecter sur la console locale (c’est-à-dire, avec
votre clavier et votre écran...). Il est donc nécessaire de choisir les terminaux à partir desquels
l’utilisateur root pourra se connecter. Ces informations sont stockées dans le fichier de configuration
/etc/securetty.

329
 Chapitre 9. Configuration du réseau

Le format de ce fichier est très simple, puisqu’il est constitué de la liste des terminaux à partir desquels
l’utilisateur root peut se connecter, à raison d’un terminal par ligne. Un fichier de configuration
/etc/securetty typique contient donc la liste des terminaux virtuels de la machine :

# Exemple de fichier /etc/securetty

tty1
tty2
tty3
tty4
tty5
tty6

Il est fortement déconseillé de placer dans ce fichier les autres terminaux (en particulier, les terminaux
série ttyS0 et suivants).
Un autre service sensible est le service de téléchargement de fichiers. Il est recommandé d’interdire aux
utilisateurs privilégiés les transferts de fichiers par FTP. En effet, si une personne parvient à accéder au
système de fichiers, il peut supprimer tous les mécanismes de sécurité. De la même manière que l’on a
interdit à l’utilisateur root de se connecter sur les terminaux distants, il faut lui interdire (ainsi qu’aux
autres comptes sensibles) les connexions par FTP.
Cette opération peut être réalisée en ajoutant le nom de chaque utilisateur sensible dans le fichier de
configuration /etc/ftpusers. Ce fichier a la même structure que le fichier securetty, puisqu’il faut
donner un nom d’utilisateur par ligne :

# Exemple de fichier /etc/ftpusers

root
uucp
mail

Bien entendu, la liste des utilisateurs privilégiés de votre système dépend de la distribution que vous avez
installé. Le fichier /etc/ftpusers fourni avec cette distribution est donc, en général, approprié.

Chiffrement des communications

Les protocoles réseau de haut niveau ne garantissent en général pas la confidentialité des données qu’ils
transmettent sur le réseau, ce qui signifie qu’elles peuvent être lues par tout le monde. Il n’en garantissent
pas non plus l’intégrité, chacun pouvant les modifier à volonté et fausser ainsi la communication. Ces
défauts sont incurables, car ils sont en réalité inhérents au protocole IP lui-même. En effet, ce protocole a
été conçu initialement pour assurer l’acheminement des informations, et les protocoles de haut niveau
basés sur lui se contentent généralement de la garantie de livraison.

Note : La condidentialité des données est le fait que seules les personnes autorisées peuvent y
accéder. L’intégrité des données est le fait que les données n’ont pas été altérées ou modifiées de
manière non autorisée. Enfin, l’authenticité des données est le fait que les données sont certifiées
comme provenant bien de celui qui prétend en être l’émetteur.

330
 Chapitre 9. Configuration du réseau

Généralement, le moyen le plus sûr pour garantir la confidentialité des données est de les chiffrer de telle
sorte que seuls les destinataires autorisés puissent les déchiffrer et donc y accéder. C’est pour cette raison
que la cryptographie, ou science du chiffrement, est souvent utilisée pour résoudre les problèmes de
sécurité informatique. Mais la cryptographie fournit également les techniques nécessaires pour assurer
l’intégrité des données, généralement en calculant une empreinte ou condensé cryptographique des
données. En effet, les algorithmes de calcul des empreintes sont conçus pour fournir des résultats très
différents même si les données ne sont modifiées que très légèrement. Ainsi, si une personne mal
intentionnée modifie un tant soit peu les données, le recalcul de l’empreinte associée indiquera tout de
suite la supercherie. Enfin, l’authenticité des données peut être assurée en faisant en sorte que leur
émetteur puisse prouver son identité. Cela se fait généralement en exigeant qu’il puisse répondre à une
question dont on sait que lui seul connaît la réponse. Toute la difficulté est alors de trouver un système
d’authentification où celui qui pose la question ne doit lui-même pas en connaître la réponse (faute de
quoi celui qui pose la question pourrait se faire passer pour celui qui doit répondre !).

Note : Il est évident que pour garantir la confidentialité et l’authenticité des données, il faut garantir
l’authenticité des interlocuteurs. En effet, sans cela, une tierce personne pourrait s’intercaler entre
deux interlocuteurs et faire croire à chacun qu’il est l’autre. Même dans un canal de communication
chiffré, cette personne serait en mesure de déchiffrer les messages dans les deux sens, voire même
de les modifier et d’en recalculer les empreintes. Cette technique d’interposition s’appelle l’attaque
du « man in the middle » (« l’homme du milieu » en Français)

Il est donc nécessaire, du fait des faiblesses des protocoles réseau standards, de recourir à des solutions
cryptographiques pour fournir les services de confidentialité, d’authenticité et d’intégrité des données.
Parmi ces solutions, les plus utilisées sont sans doute le protocole SSH (abréviation de l’anglais « Secure
SHell ») et l’extension IPSec au protocole IP. Cette extension a initialement été développée pour le
successeur du protocole IP, à savoir le protocole IPv6, mais a également été adaptée pour fonctionner
avec l’implémentation actuelle d’IP.

Principes de base de cryptographie

Tout d’abord, commençons par quelques définitions, beaucoup d’articles disponibles actuellement
utilisant un vocabulaire imprécis. Le chiffrement (également appelé à tord cryptage), est l’opération qui
consiste à transformer une information en clair en une information codée afin d’éviter qu’elle ne puisse
être utilisée par une personne non autorisée. Le déchiffrement est l’opération inverse du chiffrement, qui
permet donc de retrouver l’information initiale à partir de l’information codée. Le décryptage est
l’opération qui consiste à déchiffrer une information sans y être autorisé. La cryptographie est la science
qui se charge d’étudier la manière de chiffrer les informations. La cryptoanalyse est l’étude des moyens
de décryptage. Cette science va de paire avec la cryptographie, puisqu’elle permet de déterminer la
fiabilité des techniques mises en œuvre pour le chiffrement. Enfin, un pirate (également appelé
« cracker ») est une personne désirant s’introduire de manière illicite dans un système, ou désirant
détourner une application de son contexte d’utilisation normal. Il ne faut pas confondre les crackers avec
les hackers, qui sont des personnes extrêmement compétentes en informatique et qui ne font rien de mal
(par exemple, les développeurs du noyau Linux sont souvent des hackers).
Il existe un grand nombre de techniques de cryptographie, qui sont plus ou moins efficaces. La première
technique, qui est aussi la plus simple et la moins sûre, est celle qui consiste à utiliser un algorithme de

331
 Chapitre 9. Configuration du réseau

chiffrement réversible (ou une une paire d’algorithmes ayant un effet inverse l’un de l’autre) pour
chiffrer une information. Dans ce cas, la sécurité des données est assujettie au maintien au secret de
l’algorithme utilisé. Il est évident que ce type de technique n’est pas utilisable avec les logiciels dont les
sources sont diffusées (comme Linux), puisque l’algorithme est alors connu de tout le monde. C’est
également la technique la moins sûre, parce qu’il est en général très facile de déterminer cet algorithme.
Un exemple d’un tel algorithme est le codage classique qui consiste à décaler toutes les lettres de
l’alphabet (A devient B, B devient C, etc.).
Une autre technique se base sur un algorithme connu de tout le monde, mais dont l’effet est paramétré
par une clef tenue secrète. Le déchiffrement des informations ne peut se faire que si l’on connaît cette
clef. Les algorithmes de ce type sont souvent qualifiés de « symétriques », en raison du fait que la clef
utilisée pour le déchiffrement est la même que celle utilisée pour le chiffrement. Cette technique n’est
satisfaisante que dans la mesure où les personnes qui communiquent peuvent s’échanger cette clef de
manière sûre. La clef utilisée ne devant être connue que des personnes autorisées à participer à la
communication, cet échange doit se faire soit de visu, soit dans un canal déjà chiffré (mais dans ce cas, il
faut échanger la clef de déchiffrement du canal, et on se retrouve devant le problème de l’œuf et de la
poule), soit à l’aide d’un protocole d’échange de clef sûr. Les algorithmes de ce type sont également
connus sous le nom d’algorithmes à clef secrète en raison de cette particularité. Il existe un grand
nombre d’algorithmes à clef secrète, les plus connus étant DES, AES et IDEA.

Figure 9-9. Algorithme de chiffrement symétrique

La technique la plus sûre actuellement, et aussi la plus rusée, est d’utiliser un algorithme de chiffrement
asymétrique. À la différence des algorithmes symétriques, les algorithmes asymétriques utilisent deux
clefs différentes et duales pour le chiffrement et le déchiffrement. Ces algorithmes se basent sur des
fonctions mathématiques dont la fonction inverse est extrêmement difficile à déterminer sans une
information également difficile à calculer. Cette information fait office de clef permettant de retrouver
l’information en clair. Toute la ruse ici est que la clef servant au déchiffrement peut ne plus être échangée
du tout, ce qui supprime la nécessité de réaliser un échange de clefs généralement risqué. En fait, seule la

332
 Chapitre 9. Configuration du réseau

clef de chiffrement doit (et peut sans crainte) être publiée. C’est en raison de cette propriété que les
algorithmes asymétriques sont également appelés algorithmes à clef publique.
Le principe des algorithmes asymétriques est le suivant. Une clef publique, utilisée pour chiffrer les
informations, est fournie à tout le monde, et seul celui qui dispose de la clef privée associée à cette clef
publique peut déchiffrer le texte. Toute personne qui désire communiquer avec le propriétaire de la clef
publique utilise celle-ci pour chiffrer les informations qu’il doit lui transférer. Ainsi, du fait que seul le
destinataire dispose de la clef de déchiffrement (sa clef privée), il est le seul à pouvoir récupérer ces
informations. Il est donc possible d’échanger des informations de manière sûre avec tous les intervenants
en utilisant simplement leurs clefs publiques respectives. Aucun échange d’information sensible n’est
effectué en clair. Les algorithmes à clef publique les plus connus sont RSA et DSA.

Figure 9-10. Algorithmes de chiffrement asymétriques

La gestion des clefs des algorithmes à clef publique est techniquement laborieuse, de même que les
calculs mis en œuvre par les algorithmes utilisés. Il est donc courant d’amorcer une communication avec
un algorithme à clef publique, comme RSA par exemple, puis de l’utiliser pour échanger une clef secrète
permettant de poursuivre la communication avec un algorithme symétrique. Il existe également des
algorithmes spécialisés dans les échanges de clefs dans un canal non sûr, comme par exemple
l’algorithme Diffie Hellman.
Enfin, il existe des algorithmes de chiffrement à sens unique qui ne permettent pas de retrouver
l’information initiale, mais qui sont utilisés pour calculer une empreinte des informations à transférer.
Cela permet d’identifier l’information de manière unique. Ces algorithmes sont donc souvent utilisés
pour garantir l’intégrité des données diffusées dans un environnement peu sûr. Pour cela, celui qui réalise
la diffusion chiffre un condensé des informations diffusées avec sa clef privée. Tout le monde peut donc
déchiffrer ce condensé avec la clef publique de cette personne, et vérifier que le message qu’ils reçoivent
a bien la même empreinte. Chacun a donc la certitude que le message provient bien de son auteur, car
toute modification du message changerait son empreinte d’une part, et il est impossible de chiffrer cette
nouvelle empreinte sans connaître la clef privée de l’expéditeur. Les algorithmes de calcul d’empreinte

333
 Chapitre 9. Configuration du réseau

les plus connus sont MD5 et SHA.

Note : Notez que les algorithmes de chiffrement à clef publique nécessitent toujours que l’on soit sûr
que l’on utilise la bonne clef publique pour s’adresser à une personne. Or, rien ne nous garantit que
la clef publique d’une personne diffusée sur le réseau provienne bien de cette personne ! Il est donc
toujours nécessaire d’échanger les clefs publiques de main à main, avec vérification de l’identité de
la personne avec qui l’échange se fait. Il est également possible de recourir à une tierce personne
digne de confiance et dont on connaît déjà la clef publique pour garantir que la clef que l’on reçoit
est bien celle de la personne qui prétend en être le propriétaire. On peut ainsi construire ce qu’on
appelle un « réseau de confiance », dans lequel chacun sait que quelqu’un en qui il a confiance,
directement ou indirectement, a authentifié ses interlocuteurs.
Bien entendu, tout cela est contraignant. Mais, contrairement aux algorithmes de chiffrement à clef
secrète, il n’est pas grave de perdre les clefs échangées avec les algorithmes asymétriques, puique
ces clefs sont destinées à être publiques...

Utilisation de SSH
SSH est en réalité un protocole de communication réseau chiffré couplé d’une suite d’outils permettant
de l’utiliser. SSH a été initialement développé par une société commerciale, qui diffusait les outils en
Open Source et gratuitement pour les particuliers. Ces outils n’étaient toutefois absolument pas libres.
Une implémentation libre a donc été développée pour le système FreeBSD, puis portée pour les autres
systèmes d’exploitation, dont Linux. Cette implémentation est celle qui est utilisée par la plupart des
distributions actuellement, il s’agit de « OpenSSH ». Nous ne décrirons ici que l’utilisation d’OpenSSH.
Pour garantir la confidentialité des données, SSH utilise des techniques de cryptographie avancées. Ces
techniques permettent de s’assurer que personne ne peut lire les informations qui circulent sur le réseau
d’une part, et de garantir l’authentification des machines auxquelles on se connecte d’autre part. De plus,
SSH permet de rediriger les protocoles réseau non chiffrés dans son propre canal de communication, et
résout donc la plupart des problèmes de sécurité. SSH a donc pour but premier de remplacer les
applications non sûres permettant de se connecter à distance sur une machine ou d’y exécuter des
commandes. Les applications ainsi rendues obsolètes sont, entre autres, telnet, rlogin et rsh. Enfin, SSH
est également utilisable pour chiffrer automatiquement les connexions X11, ce qui permet d’utiliser
l’environnement graphique X Window à distance en toute sécurité.

Note : Officiellement, il est interdit d’utiliser en France des techniques de chiffrement aussi poussées
que celles mises en œuvre par SSH, sauf à demander une dérogation. Il y a de fortes pressions
pour permettre la légalisation de ces techniques, mais elles n’ont pas encore abouti. Plus
précisément, le gouvernement a pris position pour une libéralisation de l’usage de la cryptographie,
mais la loi n’a pas encore été votée. Les sinistres événements du 11 novembre 2001 risquent fort de
retarder encore, si ce n’est de compromettre, cette libéralisation. En effet, l’argument principal des
opposants à cette légalisation est qu’elle permettrait aux truands de chiffrer leurs communications.
L’argument est bien entendu fallacieux : comme s’ils attendaient d’en avoir le droit pour le faire...
En fait, il existe une implémentation gratuite (mais non libre) de SSH qui a été déclarée et qui peut
donc être utilisée en France. Il s’agit de la version de Bernard Perrot, nommée « SSF », que l’on
pourra trouver à l’adresse [Link] Si vous désirez
absolument être sans reproche vis à vis de la loi actuellement en vigueur en France, vous devriez
remplacer la version d’OpenSSH fournie avec votre distribution (dont l’usage est donc illégal) par
SSF. Sachez cependant que SSF restreint la taille des clefs de sessions à 128 bits seulement d’une

334
 Chapitre 9. Configuration du réseau

part (condition sine qua non pour qu’on puisse l’utiliser), qu’il n’est pas utilisable commercialement,
et qu’il est susceptible de ne pas être à jour en ce qui concerne les correctifs de bogues et les failles
de sécurité que l’on a pu trouver récemment dans SSH ou OpenSSH. La sécurité apportée par SSF
est donc très relative, mais c’est mieux que rien du tout.

Il existe deux versions du protocole réseau SSH, qui ont tous deux été adoptés en tant que standards. La
première version souffrait d’un trou de sécurité majeur, qui depuis a largement pu être utilisé. Il ne faut
donc surtout pas utiliser cette version et se rabattre systématiquement sur le protocole SSHv2. Ce
protocole permet de garantir l’authentification des machines et des utilisateurs et est nettement plus
fiable. Aucune attaque n’a permis de le casser à ce jour, sachez toutefois qu’il existe encore des points
douteux dans ce protocole qui permettraient, en théorie, de parvenir à s’immiscer dans une
communication ou d’en décrypter une partie.
Sachez également que les différentes implémentations de SSH, aussi bien libres que commerciales, sont
soumises au même régime que les autres programmes : elles peuvent avoir des bogues et des trous de
sécurité qu’un attaquant peut utiliser. De nombreuses attaques ont été découvertes ces derniers temps,
aussi est-il recommandé de s’assurer que l’on dispose de la dernière version d’OpenSSH. La dernière
version stable est la 3.7.1p1 (les versions antérieures doivent être évitées à tout prix). Cela dit, mener une
attaque contre SSH relève le niveau de difficulté nettement au dessus de ce qui est nécessaire pour
pénétrer un système qui ne l’utilise pas.

Principes de base de l’authentification SSH

La grande difficulté dans les mécanismes d’authentification est d’être capable de prouver son identité
sans fournir suffisamment d’information pour que quelqu’un d’autre puisse se faire passer pour soi par la
suite. La technique du mot de passe utilisée par les systèmes Unix est absolument insuffisante pour des
communications réseau, car elle requiert justement de fournir ce mot de passe. Même si les mots de
passe ne sont pas stockés en clair sur la machine (ce qui est la moindre des choses), il est possible de se
faire passer pour une tierce personne. En effet, les mécanismes d’authentification comparent souvent une
empreinte du mot de passe avec l’empreinte stockée dans les fichiers de définition des mots de passe,
mais rien n’empêche un intrus de capter cette empreinte et de l’utiliser directement pour s’authentifier si
l’on utilise la même technique en réseau. Il n’a même pas besoin de connaître le mot de passe en clair
(cette technique est connue sous le nom d’attaque par « rejeu », car l’attaquant se contente dans ce cas de
rejouer la séquence d’authentification). Une solution contre le rejeu est de demander à la personne que
l’on cherche à authentifier de chiffrer un message aléatoire avec son mot de passe ou son empreinte, et de
vérifier que le résultat qu’il renvoie est bien celui attendu, en chiffrant le même message de son côté.
Cette technique est toutefois toujours vulnérable à l’attaque de l’homme du milieu, et elle souffre de
l’énorme défaut que l’on doit stocker l’empreinte de son mot de passe sur tous les ordinateurs auxquels
on désire se connecter. Cela multiplie d’autant les points de faiblesse : si un pirate s’introduit sur une
seule machine, il obtient toutes les empreintes des mots de passe et peut donc se faire passer pour tout le
monde !
SSH ne transmet donc ni les mots de passe, ni leurs condensés, en clair sur le réseau. Il établit d’abord un
canal de communication chiffré à l’aide d’un des algorithmes d’échange de clef (la technique utilisée
dépend de la version utilisée du protocole SSH). Une fois le canal chiffré établi, la machine serveur est
authentifiée à l’aide de sa clef publique. Pour que cela fonctionne, il faut bien entendu que la clef
publique de la machine serveur soit connue du client et ait été authentifiée comme étant bien celle de ce
serveur. Inversement, le client peut être authentifié par le serveur. SSH fournit plusieurs possibilités pour

335
 Chapitre 9. Configuration du réseau

cela, les deux plus courantes étant l’authentification par mot de passe et l’authentification par un
algorithme à clef publique.
L’authentification par mot de passe est strictement la même que celle utilisée pour le login Unix
classique, à la différence près que les informations du mot de passe sont transmises dans le canal chiffré,
vers un serveur authentifié. La sécurité de ce mot de passe est donc garantie, et l’attaque de l’homme du
milieu de fonctionne plus. Ce type d’authentification permet donc d’utiliser SSH exactement comme les
commandes classiques rsh ou telnet. L’utilisation de SSH est donc complètement transparente pour les
utilisateurs.
Cela dit, il est possible de faciliter encore plus l’authentification des clients tout en augmentant le niveau
de sécurité, en utilisant également l’authentification par clef publique pour les utilisateurs. Dans ce mode
d’authentification, chaque utilisateur dispose également d’un couple de clefs privée et publique. Les clefs
publiques de ces utilisateurs sont diffusées dans les comptes des utilisateurs au niveau du serveur. Ainsi,
il n’est plus nécessaire de fournir un mot de passe, car le serveur peut authentifier l’utilisateur du seul fait
qu’il est le seul à connaître sa clef privée. La connexion est donc automatique (une fois le serveur
correctement configuré, bien entendu) et aucun échange d’information sensible comme le mot de passe
n’est réalisé (même si le fait que cet échange était réalisé dans un canal chiffré par SSH était déjà une
bonne garantie).
Les clefs privées et publiques sont bien entendu stockées sur disque, dans les fichiers de configuration
des serveurs et des clients. Il va de soi que si les clefs publiques peuvent être lues, il est impératif que les
clefs privées ne soient lisibles que par leurs propriétaires. Les droits d’accès sur les fichiers de
configuration doivent donc être fixées de manière correcte pour garantir la sécurité du système. En fait, le
point faible du mécanisme d’authentification des clients est toujours au niveau des utilisateurs, qui
peuvent perdre leur clef privée ou la communiquer à d’autres sans même savoir qu’ils font une erreur
fondamentale (de la même manière qu’ils peuvent choisir un mot de passe trop facile à trouver ou
simplement le communiquer à une tierce personne). C’est pour cela qu’il est possible de chiffrer les clefs
privées avec un algorithme de chiffrement symétrique. L’utilisateur doit, dans ce cas, fournir une phrase
clef à chaque fois qu’il désire réaliser une connexion SSH.

Compilation et installation d’OpentSSH

Comme nous l’avons dit plus haut, il est recommandé d’utiliser la dernière version d’OpenSSH, à savoir
la version 3.7.1.p1. Il est probable que votre distribution fournisse une mise à jour sur son site, et il est
recommandé d’utiliser ces mises à jours.
Si, toutefois, vous désirez effectuer l’installation à partir des fichiers sources, vous pourrez procéder
comme suit. Il vous faudra récupérer l’archive des fichiers sources en premier lieu sur le site OpenSSH
([Link] Pour Linux, il faut prendre l’archive 3.7.1p1, le ’p’ signifiant ici qu’il s’agit
d’un portage des sources pour Linux. Une fois cela fait, vous pourrez exécuter la commande suivante
dans le répertoire des sources :

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-tcp-wrappers --with-pam

Cette commande permet de configurer OpenSSH pour qu’il remplace la version existante dans votre
système. Elle indique également que le support du démon tcpd doit être activé, ainsi que celui des
modules d’authentification PAM (options « --with-tcp-wrapppers » et « --with-pam »). Bien
entendu, si votre distribution n’utilise pas ces fonctionnalités, vous devez supprimer ces options.

336
 Chapitre 9. Configuration du réseau

La compilation et l’installation en soi ne posent pas de problème particulier. Pour les réaliser, il vous
suffira d’exécuter les deux commandes suivantes :

make
make install

Vous constaterez que le programme d’installation génère automatiquement des fichiers de clefs
publiques et privées pour votre machine. Nous verrons dans les sections suivantes comment ces clefs
peuvent être utilisées.

Note : Vous devrez créer un compte utilisateur « sshd » non privilégié avant d’installer SSH. Ce
compte est en effet utilisé par le démon sshd pour réaliser les communications réseau une fois la
phase d’authentification réalisée. Cela permet de garantir que, même en cas d’exploitation d’une
éventuelle faille de sécurité du démon sshd, l’accès à la machine sera extrêmement limité.

Configuration d’OpenSSH côté serveur

OpenSSH utilise un démon nommé sshd pour prendre en charge les requêtes de connexion de la part des
clients. Ce démon est à l’écoute des demandes de connexion et effectue les opérations d’authentification
du serveur auprès des clients. Il vérifie également les droits du client avant de le laisser utiliser la
connexion chiffrée.
Le démon sshd utilise un fichier de configuration général /etc/sshd_config et plusieurs fichiers
contenant les clefs publiques et privées de la machine pour les différents protocoles cryptographiques
utilisés par les clients. Les protocoles disponibles sont le protocole RSA pour la version 1 du protocole
SSH, et les protocoles RSA et DSA pour la version 2. Comme il existe deux fichiers pour les clefs du
serveur (un premier fichier lisible par tous les utilisateurs, pour la clef publique, et un fichier lisible
uniquement par l’utilisateur root, pour la clef privée), il peut exister au total six fichiers de clefs. Ces
fichiers sont nommés respectivement /etc/ssh_host_key et /etc/ssh_host_key.pub pour les
clefs privées et publiques du protocole de version 1, et /etc/ssh_host_rsa_key,
/etc/ssh_host_rsa_key.pub, /etc/ssh_host_dsa_key et /etc/ssh_host_dsa_key.pub
respectivement pour les algorithmes RSA et DSA du protocole SSH de version 2.
Normalement, les fichiers de clefs du serveur ont été créés automatiquement lors de l’installation de
SSH. Cependant, si vous installez SSH à partir d’une archive de distribution, ils peuvent ne pas être
présents, et vous devrez générer ces clefs vous-même. Pour cela, il faut utiliser la commande
ssh-keygen, dont la syntaxe est la suivante :

ssh-keygen [-t type]

où type est le type de clef à générer pour le protocole de version 2. Les types disponibles sont rsa et
dsa. Pour le protocole de version 1, il ne faut pas utiliser l’option -t, les clefs générées étant forcément
des clefs RSA.
Lorsque l’on invoque la commande ssh-keygen, celui-ci demande le chemin du fichier dans lequel la clef
privée doit être écrite. Le fichier contenant la clef publique aura le même nom, mais portera l’extension
.pub. Vous devez donc saisir le chemin du fichier correspondant au type de clef généré. ssh-keygen
demande ensuite le mot de passe à utiliser pour le chiffrement de la clef privée. Dans le cas d’un serveur,

337
 Chapitre 9. Configuration du réseau

il ne faut pas utiliser de mot de passe, car dans ce cas le démon sshd ne pourrait pas accéder à la clef
privée de la machine. Il faut donc, dans ce cas, valider simplement sans rien taper.
Une fois les fichiers de clefs du serveur générés, vous pouvez vous intéresser au fichier de configuration
sshd_config. Ce fichier de configuration contient un certain nombre d’options qui indiquent les
paramètres que le démon doit utiliser. Vous trouverez ci-dessous un exemple de fichier de configuration :

# Paramètres de connexion :
Port 22
ListenAddress [Link]
KeepAlive yes

# Protocoles utilisables :
Protocol 2

# Chemin sur les fichiers de clefs :

HostKey /etc/ssh_host_rsa_key
HostKey /etc/ssh_host_dsa_key

# Paramètres des messages de traces :

SyslogFacility AUTH
LogLevel INFO

# On définit les modes d’authentification utilisables :

# Authentification par clef publique :

RSAAuthentication no
PubkeyAuthentication yes

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no

# Authentification par mot de passe :

PasswordAuthentication no
PermitEmptyPasswords no

# Options générales :

# L’utilisateur root ne doit pouvoir se loguer qu’en local :

PermitRootLogin no

# Utilise le compte non privilégié sshd

# pour les communications réseau :
UsePrivilegeSeparation yes

# On n’autorise la connexion que pour les utilisateurs dont

# les fichiers de configuration sont correctement protégés :
StrictModes yes

# Encapsulation automatique du protocole X :

X11Forwarding yes

338
 Chapitre 9. Configuration du réseau

X11DisplayOffset 10

# Affichage des informations habituelles au login :

PrintMotd no
PrintLastLog yes

Comme vous pouvez le constater, un grand nombre d’options sont disponibles. Les options Port et
ListenAddress permettent de définir l’adresse IP sur laquelle le démon sshd se mettra en attente de
demandes de connexion, ainsi que le port TCP utilisé pour cela. L’adresse [Link] signifie ici qu’il doit se
mettre en attente sur toutes les adresses de la machine. L’option KeepAlive permet de demander au
démon de vérifier régulièrement que la liaison est toujours valide, afin de fermer les connexions
automatiquement en cas d’arrêt du client. L’option Protocol permet de spécifier les versions utilisables
du protocole SSH. La version 1 étant obsolète, on spécifiera systématiquement la valeur 2 ici. L’option
HostKey permet, comme son nom l’indique, de donner les noms des fichiers contenant les clefs pour les
différents protocoles d’authentification. Les options SyslogFacility et LogLevel permettent
d’indiquer le type et le niveau des messages de traces générés par le démon sshd dans le fichier de traces
du système.
Viennent ensuite les options spécifiques aux différents modes d’authentification. Les options
RSAAuthentication et PubkeyAuthentication permettent d’activer et de désactiver
l’authentification par clef publique des clients, respectivement pour les protocoles SSH de version 1 et 2.
Les options IgnoreRhosts, RhostsRSAAuthentication et HostbasedAuthentication
permettent de contrôler un protocole d’authentification basé sur l’identité des machines. Ce type
d’authentification n’a pas été présenté car il est extrêmement peu sûr, et il faut impérativement désactiver
ces fonctionnalités. Enfin, les options PasswordAuthentication et PermitEmptyPasswords
permettent d’activer ou de désactiver l’authentification par mot de passe. Vous êtes libre d’utiliser ou non
ces fonctionnalités.
Le fichier de configuration peut également contenir des options complémentaires. Les plus importantes
pour la sécurité sont sans doute PermitRootLogin et StrictModes, qui permettent d’interdire la
connexion par le réseau à l’utilisateur root d’une part, et d’interdire la connexion aux utilisateurs qui
n’ont pas bien fixé les droits d’accès sur leurs fichiers de configuration personnels dans leur compte local
(il est donc impossible de garantir que ces fichiers n’ont pas été trafiqués par d’autres utilisateurs pour
accéder à leur compte). L’option UsePrivilegeSeparation permet de demander au démon sshd de
n’effectuer les communications réseau que dans le compte spécial sshd, compte auquel on n’affectera
que le minimum de droits. Cette technique permet de protéger le système contre l’exploitation d’une
éventuelle faille de sécurité dans le démon sshd. L’option X11Forwarding permet d’activer
l’encapsulation automatique du protocole X et peut être relativement pratique. Le numéro de display
auquel les utilisateurs devront connecter leurs applications sera alors décalé du nombre indiqué par
l’option X11DisplayOffset. Cette option est utile pour éviter les conflits avec les serveurs X locaux.
Vous trouverez de plus amples informations sur le protocole X11 et l’environnement graphique dans le
Chapitre 10. Enfin, les options PrintMotd et PrintLastLog permettent de spécifier les informations
affichées par le démon sshd lorsque la connexion des clients est acceptée. Il existe bien d’autres options,
vous pourrez obtenir de plus amples renseignements dans la page de manuel du démon sshd.

Utilisation d’OpenSSH côté client

Les clients peuvent se connecter à un serveur SSH à l’aide de la commande ssh. Cette commande

339
 Chapitre 9. Configuration du réseau

s’utilise exactement de la même manière que les commandes rsh ou rlogin. La syntaxe de la commande
ssh est la suivante :

ssh [-l nom] machine [commande]

ou :

ssh nom@machine [commande]

où nom est ici le nom d’utilisateur à utiliser pour la connexion, et machine la machine distante. Si aucun
nom d’utilisateur n’est spécifié, le nom de l’utilisateur sur la machine local est pris par défaut. Il est
possible d’exécuter une commande sur la machine distante en la spécifiant après le nom de la machine.
Si aucune commande n’est spécifiée, un shell interactif est lancé.
Selon le mode d’authentification du client choisi par le serveur, il peut être nécessaire ou non de définir
des clefs pour le client. Tout comme pour les clefs publiques et privées d’un serveur, la génération de ces
clefs se fait à l’aide de la commande ssh-keygen. Cependant, contrairement à ce qui se passait pour le
serveur, les chemins par défaut proposés pour stocker les clefs sont ici corrects, et il est vivement
recommandé de saisir un mot de passe pour chiffrer la clef privée. Les fichiers de clefs générés par
ssh-keygen sont les fichiers identity et [Link] pour le protocole d’authentification RSA de
la version 1 du protocole SSH, et les fichiers id_rsa, id_rsa.pub, id_dsa et id_dsa.pub
respectivement pour les protocoles RSA et DSA de la version 2 du protocole SSH. Tous ces fichiers sont
stockés dans le répertoire .ssh/ du répertoire personnel de l’utilisateur qui les génère. Il va de soi que
les fichiers des clefs privées doivent ne doivent pas être lisibles pour les autres utilisateurs, et que les
fichiers des clefs publiques ne doivent pas pouvoir être écrits si l’on veut éviter qu’un usurpateur prenne
notre place sur notre propre machine.
Afin de bénéficier de l’authentification des serveurs auxquels on se connecte, il faut placer les clefs
publiqes de ces derniers dans le fichier .ssh/known_hosts. Si, lors d’une connexion à un serveur, la
clef publique de celui-ci n’est pas connue, ssh vous le signalera. Il indiquera un message d’erreur
indiquant que le serveur auquel on se connecte n’est pas forcément celui qu’il prétend être, et affiche un
condensé de sa clef publique. Vous devrez vous assurer que ce condensé est bien celui de la clef publique
du serveur auquel vous vous connectez, et ce par un moyen sûr (déplacement physique et connection en
local par exemple). Si vous acceptez cette clef, ssh la placera pour vous dans votre fichier
known_hosts, ce qui vous permettra de vous connecter par la suite en toute quiétude. Attention, le
fichier known_hosts ne doit pas être accessible en écriture aux autres utilisateurs, car dans ce cas un
pirate pourrait capter toutes vos communications !
Si le mode d’authentification utilisé est le mot de passe, ssh vous demandera de saisir le mot de passe du
compte distant. Dans ce cas, ssh se comporte exactement comme rsh, à ceci près que votre mot de passe
ne circulera pas en clair sur le réseau (quel progrès !).
Si, en revanche, le mode d’authentification utilisé est une authentification par clef publique, alors vous
devrez avoir défini vos clefs privées et publiques. Pour que le démon sshd de la machine distante accepte
la connexion, vous devrez placer vos clefs publiques dans le fichier authorized_keys du répertoire
./ssh/ du répertoire du compte distant. Cela permettra au démon sshd de s’assurer que c’est bien vous
qui vous connectez. Attention, le fichier authorized_keys ne doit pas être accessible en écriture, faute
de quoi un autre utilisateur de la machine distante pourrait se connecter en votre nom. Il est également
impératif de réaliser l’écriture soi-même dans ce fichier par un moyen sûr (déplacement physique). En
aucun cas la communication de votre clef publique à l’administrateur distant ne pourra être considérée

340
 Chapitre 9. Configuration du réseau

comme un moyen sûr pour écrire cette clef : en effet, un pirate pourrait tout aussi bien lui demander
d’écrire sa propre clef dans votre fichier !
Vous constaterez qu’un certain nombre de précautions doivent être prises pour les manipulations de clefs.
Comme il l’a déjà été indiqué plus haut, le point faible est bel et bien l’authentification des clients. Cela
concerne en premier lieu le client bien entendu, dont le compte peut être piraté, mais c’est aussi un trou
de sécurité énorme pour le serveur, car une fois le loup dans la bergerie, il peut faire beaucoup de dégâts
et chercher à accroître ses droits (jusqu’à devenir root) par d’autres techniques.

Création d’un tunnel SSH

L’un des principaux avantages de SSH est qu’il est possible de l’utiliser pour encapsuler n’importe quel
protocole réseau TCP dans le canal de communication d’une connexion sécurisée. Un tel canal est
communément appelé un « tunnel », en raison du fait qu’il est utilisé par les informations sensibles pour
traverser un réseau non sûr. Grâce aux tunnels SSH, il est possible d’utiliser tous les protocoles classiques
sans avoir à s’inquiéter de la confidentialité des informations transmises. SSH permet même de réaliser
cette opération automatiquement pour le protocole X du système de fenêtrage X Window, ce qui est très
commode si l’on désire afficher localement les fenêtres graphiques des programmes lancés sur le serveur.
Encapsuler le protocole X dans SSH est donc extrêmement aisé. En effet, il suffit simplement de donner
la valeur « yes » à l’option X11Forwarding dans le fichier de configuration du serveur
/etc/sshd_config et dans le fichier de configuration des clients (les valeurs par défaut pour tous les
utilisateurs peuvent être définies dans le fichier de configuration /etc/ssh_config et être redéfinies
par chaque utilisateur dans le fichier config de leur répertoire .ssh/). Si ces options sont activées, SSH
se charge de fixer la variable d’environnement DISPLAY de la machine distante à un serveur X virtuel de
cette machine. Les programmes X se connectent alors à ce serveur, et celui-ci effectue automatiquement
le transfert des communications vers le serveur X du client. Il ne faut donc pas, quand on utilise SSH,
modifier manuellement la variable d’environnement DISPLAY. Vous trouverez plus d’information sur X
Window dans le Chapitre 10.
Pour les autres protocoles, les opérations ne sont pas réalisées automatiquement par SSH. Il faut donc
établir un réseau privé virtuel manuellement. Le principe est le suivant : les programmes clients sont
paramétrés pour se connecter sur un port local différent de celui utilisé habituellement pour leur
protocole. Ainsi, ils ne s’adressent pas directement au serveur distant, mais plutôt à un proxy local établi
par SSH pour l’occasion. Ce proxy établit un canal de communication chiffré avec le démon sshd de la
machine distante. Toutes les informations du protocole encapsulé passent alors par le canal chiffré, et le
démon sshd de la machine distante retransmet ces informations au service distant auquel le client devait
se connecter.
Tout ce mécanisme ne fonctionne que parce qu’il est possible de rediriger les clients sur un port réservé
par SSH sur leur machine locale. Cette redirection peut être initiée aussi bien du côté serveur que du côté
client, lors de la connexion. Du côté du client, la redirection de port peut être réalisée avec la commande
suivante :

ssh -Llocal:serveur:port machine [commande]

où local est le port de la machine locale auquel il faudra se connecter pour accéder au service distant,
fonctionnant sur le port port de la machine serveur. Cette commande ouvre une session SSH sur la
machine machine (qui, normalement, est la même que serveur), et réalise la redirection du flux
destiné au port local dans le canal de cette session.

341
 Chapitre 9. Configuration du réseau

Il faut bien comprendre que cette redirection se fait en plus de la connexion SSH, et que la syntaxe
donnée ci-dessus ouvre une connexion sur la machine distante (ou exécute la commande spécifiée en
paramètre, s’il en est spécifiée une). Si l’on désire simplement établir un tunnel, on peut refermer la
session juste après avoir lancé le programme qui doit utiliser ce tunnel. En effet, SSH maintient le tunnel
ouvert tant qu’un programme détient une connexion sur le port redirigé. On peut aussi exécuter une
commande sleep sur un délai arbitraire, qui permettra de se connecter sur le port redirigé et qui se
terminera automatiquement.
Du côté serveur, la syntaxe est similaire. Cette fois, la commande permet d’indiquer le port que le client
devra utiliser pour accéder à un service non sécurisé du serveur. La syntaxe à utiliser est la suivante :

ssh -Rport:client:local machine [commande]

où port est le port que le client devra utiliser, client est la machine cliente, et local est le port local
utilisé par le service que l’on veut exposer de manière sécurisée au client. Encore une fois, cette
commande ouvre une connexion SSH, il faut donc spécifier la machine à laquelle on se connecte (en
l’occurrence, le client). Une commande peut être spécifiée de manière optionnelle, s’il n’y en a pas, un
shell sera lancé sur la machine distante.

Note : Prenez bien conscience que SSH ne s’assure du chiffrement que des données transmises
sur le réseau. Si la machine cliente ou la machine serveur ne sont pas correctement configurées, un
pirate peut espionner les communications réseau internes à cette machine. Pour éviter ce type de
risque, il faut utiliser des protocoles réseau eux-mêmes chiffrés. Autrement dit, une fois sorti du
tunnel SSH, vous vous exposez à nouveau aux risques d’intrusion.
Il existe d’autres méthodes de tunneling sous Linux, qui sont sans aucun doute plus ergonomiques
que SSH. En effet, non seulement les tunnels SSH ne peuvent pas être créés automatiquement (ils
nécessitent une connexion), mais en plus les connexions SSH se terminent dès que le dernier client
disparaît. En fait, les fonctionnalités de SSH sont un plus, mais elles ne sont pas destinées à
remplacer des solutions plus adaptées pour réaliser des tunnels. Vous trouverez plus d’informations
sur les réseaux privés virtuels ci-dessous.

Utilisation d’IPSec
Le protocole IPSec est une extension du protocole IP qui permet de répondre aux besoins
d’authentification et de confidentialité, grâce aux techniques de cryptographie. Les principes utilisés sont
les mêmes que pour SSH, mais ils sont mis en pratique au plus bas niveau, ce qui fait que tous les
protocoles de haut niveau en bénéficient automatiquement.

Fonctionnement d’IPSec
IPSec définit des protocoles complémentaires permettant d’encapsuler les données transférées dans les
paquets IP et assurant les services d’authentification et de confidentialité. Le protocole AH (abréviation
de l’anglais « Authentication Header ») permet, comme son nom l’indique, d’assurer que les machines
sont bien celles qu’elles prétendent être. Cela permet de supprimer tous les risques d’attaque de l’homme
du milieu. Le protocole AH permet également d’assurer l’intégrité des données. En revanche, il n’en
assure pas la confidentialité. Le protocole ESP (abréviation de l’anglais « Encapsulating Security
Payload ») permet d’assurer cette confidentialité. En revanche, contrairement à ce que de nombreuses

342
 Chapitre 9. Configuration du réseau

documentations affirment, il ne permet pas d’assurer l’authenticité des interlocuteurs, ce qui fait que la
confidentialité peut être brisée par une attaque de l’homme du milieu. Il est donc nécessaire d’utiliser les
deux protocoles si les interlocuteurs ne sont pas authentifiés de manière physique. Ces deux protocoles
permettent également de prévenir les attaques par rejeu au niveau protocolaire, car ils utilisent un numéro
de séquence dont la prédétermination est très difficile pour chaque paquet échangé.

Note : En réalité, le protocole ESP peut également assurer l’authenticité des données, même s’il ne
permet pas d’assurer l’authenticité des interlocuteurs. Cette fonctionnalité peut être utile si
l’authenticité des machines est assurée par un autre mécanisme. Toutefois, cette condition n’est
généralement pas vérifiée et il faut utiliser le protocole AH pour authentifier les machines. De ce fait,
le mécanisme d’authentification d’ESP est rarement utilisé.

AH et ESP peuvent être utilisées dans deux modes différents : le mode transport et le mode tunnel.
Le mode transport est le mode de communication natif, dans lequel les en-têtes des protocoles AH et ESP
sont insérés entre l’en-tête IP et ses données. De ce fait, les protocoles de haut niveau sont simplement
encapsulés dans les protocoles AH et ESP. Le mode tunnel, quant à lui, permet de créer un réseau virtuel
complet, en encapsulant la communication entre les interlocuteurs dans un canal chiffré. Ce sont donc les
paquets IP de la communication qui sont eux-mêmes encapsulés dans les protocoles AH et ESP.
IPSec utilise les algorithmes de cryptographie symétriques pour assurer ces fonctionnalités. Par exemple,
l’authenticité des machines et l’intégrité des données sont garanties par le protocole AH grâce à la
génération de condensés cryptographiques paramétrés par une clef privée. Seule les machines partageant
cette clef peuvent donc communiquer avec ce protocole, et toute modification des données serait détectée
lors de la vérification de la signature. De même, ESP assure la confidentialité des données en les chiffrant
avec un algorithme de chiffrement à clef privée.
Chaque canal de communication IPSec peut utiliser ses propres paramètres. Bien entendu, il est hors de
question de transférer ces paramètres (et encore moins les clefs privées utilisées !) dans chaque paquet
IP ! IPSec identifie donc ces paramètres par un numéro d’identification (appelé «« Security Parameter
Index », « SPI » en abrégé), grâce auquel chaque interlocuteur peut retrouver les paramètres de la
connexion chiffrée. L’association entre le SPI et ces paramètres est appelée une « SA » (abréviation de
l’anglais « Security Association »). Les associations de sécurité sont stockées sur chaque machine dans
une base de données que l’on appelle la SAD (de l’anglais « SA Database »).
Les associations de sécurité ne permettent que de définir la manière dont les communications doivent
être protégées. Cela dit, une machine n’est pas obligée de chiffrer toutes ses connexions, et l’on peut
parfaitement vouloir ne chiffrer les communications qu’entre deux machines seulement, ou que pour
certains protocoles seulement. Il est donc également nécessaire de définir quelles communications
doivent être chiffrées. Cela se fait grâce à une politique de sécurité (« Security Policy » en
anglais, « SP » en abrégé). Les politiques de sécurité sont également stockées dans une base de données
sur chaque machine, base de données que l’on appelle la « SPD » (abréviation de « SP Database »).
Bien entendu, la définition des clefs secrètes, des associations et des politiques de sécurité peut devenir
une opération très lourde sur de grands réseaux. En effet, il est nécessaire de définir des clefs privées
pour chaque couple de machines. Par conséquent, un protocole de gestion des clefs et des associations de
sécurité a été défini pour automatiser l’établissement des connexions. Ce protocole est le protocole
« ISAKMP » (abréviation de l’anglais « Internet Security Association and Key Management Protocol »).
Comme SSH, ce