You are on page 1of 367

Administration reseau sous Linux

Copyright
c 1992-1995 Olaf Kirch
A Britta
UNIX est une marque deposee de X/Open.
Linux n'est pas une marque deposee, et n'a aucun lien avec UNIXTM ou X/Open.
Copyright c 1995 Olaf Kirch
Kattreinstr. 38, 64295 Darmstadt, Germany
okir@monad.swb.de

Adaptation francaise Rene Cougnenc (rene@renux.frmug.fr.net)


TABLE DES MATIE RES v

Table des matieres


Preface xvii
1 Introduction aux reseaux 1
1.1 Historique: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1
1.2 Reseaux UUCP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2
1.2.1 Comment utiliser UUCP : : : : : : : : : : : : : : : : : : : : : : 3
1.3 Reseaux TCP/IP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4
1.3.1 Introduction aux reseaux TCP/IP : : : : : : : : : : : : : : : : 5
1.3.2 Ethernet : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6
1.3.3 Autres types de materiel : : : : : : : : : : : : : : : : : : : : : : 7
1.3.4 Le protocole Internet : : : : : : : : : : : : : : : : : : : : : : : : 8
1.3.5 IP sur lignes serie : : : : : : : : : : : : : : : : : : : : : : : : : 10
1.3.6 Le protocole TCP : : : : : : : : : : : : : : : : : : : : : : : : : 10
1.3.7 Le protocole UDP : : : : : : : : : : : : : : : : : : : : : : : : : 11
1.3.8 Les ports : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
1.3.9 Les sockets : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
1.4 Le reseau sous Linux : : : : : : : : : : : : : : : : : : : : : : : : : : : : 13
1.4.1 Orientations du developpement : : : : : : : : : : : : : : : : : : 14
1.4.2 Ou se procurer le code : : : : : : : : : : : : : : : : : : : : : : : 14
1.5 Maintenance du systeme : : : : : : : : : : : : : : : : : : : : : : : : : : 15
1.5.1 Securite du systeme : : : : : : : : : : : : : : : : : : : : : : : : 15
vi TABLE DES MATIE RES
2 Le reseau TCP/IP 19
2.1 Interfaces reseau : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19
2.2 Adresses IP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20
2.3 Resolution des adresses : : : : : : : : : : : : : : : : : : : : : : : : : : 21
2.4 Routage IP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 22
2.4.1 Reseaux IP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 22
2.4.2 Sous-reseaux : : : : : : : : : : : : : : : : : : : : : : : : : : : : 23
2.4.3 Passerelles : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 24
2.4.4 La table de routage : : : : : : : : : : : : : : : : : : : : : : : : 25
2.4.5 Valeurs metriques : : : : : : : : : : : : : : : : : : : : : : : : : 27
2.5 Le protocole ICMP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 28
2.6 DNS : Le Domain Name System : : : : : : : : : : : : : : : : : : : : : : 29
2.6.1 Resolution de noms : : : : : : : : : : : : : : : : : : : : : : : : 29
2.6.2 Introduction du DNS : : : : : : : : : : : : : : : : : : : : : : : : 30
2.6.3 Recherche de noms avec le DNS : : : : : : : : : : : : : : : : : 32
2.6.4 Serveurs de noms : : : : : : : : : : : : : : : : : : : : : : : : : : 33
2.6.5 La base de donnees DNS : : : : : : : : : : : : : : : : : : : : : : 34
2.6.6 Requ^etes inverses : : : : : : : : : : : : : : : : : : : : : : : : : : 36

3 Con guration de l'equipement reseau 39


3.1 Peripheriques, pilotes, etc.
: : : : : : : : : : : : : : : : : : : : : : : : : 39
3.2 Con guration du noyau : : : : : : : : : : : : : : : : : : : : : : : : : : 42
3.2.1 Options du noyau dans Linux 1.0 et au-dela : : : : : : : : : : : 43
3.2.2 Options du noyau a partir de Linux 1.1.14 : : : : : : : : : : : : 44
3.3 Tour d'horizon des pilotes reseau de Linux : : : : : : : : : : : : : : : : 46
3.4 Installation Ethernet : : : : : : : : : : : : : : : : : : : : : : : : : : : : 47
3.4.1 C^ablage Ethernet : : : : : : : : : : : : : : : : : : : : : : : : : : 47
3.4.2 Cartes supportees : : : : : : : : : : : : : : : : : : : : : : : : : 48
3.4.3 Autodetection des cartes Ethernet : : : : : : : : : : : : : : : : 49
3.5 Le pilote PLIP : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 51
3.6 Les pilotes SLIP et PPP : : : : : : : : : : : : : : : : : : : : : : : : : : 52
TABLE DES MATIE RES vii

4 Con guration des ports serie 53


4.1 Programmes de communication pour modems : : : : : : : : : : : : : : 53
4.2 Introduction aux peripheriques serie : : : : : : : : : : : : : : : : : : : 54
4.3 Acceder aux ports serie : : : : : : : : : : : : : : : : : : : : : : : : : : 55
4.4 Les ports serie : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 56

5 Con guration du reseau TCP/IP 59


5.1 Montage du systeme de chiers proc : : : : : : : : : : : : : : : : : : : 60
5.2 Installation des binaires : : : : : : : : : : : : : : : : : : : : : : : : : : 60
5.3 Un nouvel exemple : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 61
5.4 Assignation du nom de machine : : : : : : : : : : : : : : : : : : : : : : 61
5.5 Assignation des adresses IP : : : : : : : : : : : : : : : : : : : : : : : : 62
5.6 Creation de sous-reseaux : : : : : : : : : : : : : : : : : : : : : : : : : : 63
5.7 Redaction des chiers hosts et networks : : : : : : : : : : : : : : : : : 65
5.8 Con guration des interfaces reseau : : : : : : : : : : : : : : : : : : : : 66
5.8.1 L'interface loopback : : : : : : : : : : : : : : : : : : : : : : : : : 67
5.8.2 Interfaces Ethernet : : : : : : : : : : : : : : : : : : : : : : : : : 69
5.8.3 Routage par une passerelle : : : : : : : : : : : : : : : : : : : : 71
5.8.4 Con guration d'une passerelle : : : : : : : : : : : : : : : : : : : 72
5.8.5 L'interface PLIP : : : : : : : : : : : : : : : : : : : : : : : : : : 72
5.8.6 Les interfaces SLIP et PPP : : : : : : : : : : : : : : : : : : : : 74
5.8.7 L'interface dummy : : : : : : : : : : : : : : : : : : : : : : : : : 74
5.9 Tout sur ifcon g : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 74
5.10 La commande netstat : : : : : : : : : : : : : : : : : : : : : : : : : : : : 77
5.10.1 Achage de la table de routage : : : : : : : : : : : : : : : : : : 78
5.10.2 Achage des statistiques sur une interface : : : : : : : : : : : : 79
5.10.3 Achage des connexions : : : : : : : : : : : : : : : : : : : : : : 79
5.11 Test des tables ARP : : : : : : : : : : : : : : : : : : : : : : : : : : : : 80
5.12 L'avenir : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 82

6 Con guration du serveur de noms et du resolver 83


6.1 La bibliotheque resolver : : : : : : : : : : : : : : : : : : : : : : : : : : 84
viii TABLE DES MATIE RES
6.1.1 Le chier host.conf : : : : : : : : : : : : : : : : : : : : : : : : : 84
6.1.2 Variables d'environnement du resolver : : : : : : : : : : : : : : 85
6.1.3 Con guration des recherches DNS |resolv.conf : : : : : : : : : 86
6.1.4 Fiabilite du Resolver : : : : : : : : : : : : : : : : : : : : : : : : 88
6.2 Utilisation de named : : : : : : : : : : : : : : : : : : : : : : : : : : : : 88
6.2.1 Le chier named.boot : : : : : : : : : : : : : : : : : : : : : : : : 89
6.2.2 Les chiers de la base de donnees : : : : : : : : : : : : : : : : : 91
6.2.3 Redaction des chiers de reference : : : : : : : : : : : : : : : : 95
6.2.4 Veri cation de la con guration du serveur de noms : : : : : : : 96
6.2.5 Autres outils pratiques : : : : : : : : : : : : : : : : : : : : : : : 100

7 IP sur ligne serie | SLIP 101


7.1 Generalites: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 101
7.2 Mode d'emploi de SLIP : : : : : : : : : : : : : : : : : : : : : : : : : : 102
7.3 Le probleme des reseaux IP prives : : : : : : : : : : : : : : : : : : : : 104
7.4 Utilisation de dip : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 104
7.4.1 Exemple de script : : : : : : : : : : : : : : : : : : : : : : : : : 105
7.4.2 Manuel de reference de dip : : : : : : : : : : : : : : : : : : : : 107
7.5 Utilisation en mode serveur : : : : : : : : : : : : : : : : : : : : : : : : 111

8 Le protocole Point-a-Point | PPP 113


8.1 Sous les P, le protocole : : : : : : : : : : : : : : : : : : : : : : : : : : : 113
8.2 PPP sous Linux : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 114
8.3 Utilisation de pppd : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 115
8.4 Les chiers d'options : : : : : : : : : : : : : : : : : : : : : : : : : : : : 116
8.5 Appel telephonique par le programme chat : : : : : : : : : : : : : : : : 117
8.6 Deboguer votre con guration PPP : : : : : : : : : : : : : : : : : : : : 119
8.7 Options de con guration IP : : : : : : : : : : : : : : : : : : : : : : : : 119
8.7.1 Choix des adresses IP : : : : : : : : : : : : : : : : : : : : : : : 120
8.7.2 Routage via une liaison PPP : : : : : : : : : : : : : : : : : : : 121
8.8 Protocole de contr^ole de liaison : : : : : : : : : : : : : : : : : : : : : : 122
8.9 La securite sous PPP : : : : : : : : : : : : : : : : : : : : : : : : : : : : 124
TABLE DES MATIE RES ix

8.10 Authenti cation sous PPP : : : : : : : : : : : : : : : : : : : : : : : : : 124


8.10.1 CHAP ou bien PAP ? : : : : : : : : : : : : : : : : : : : : : : : 124
8.10.2 Le chier de secrets CHAP : : : : : : : : : : : : : : : : : : : : 126
8.10.3 Le chier de secrets PAP : : : : : : : : : : : : : : : : : : : : : 127
8.11 Con guration d'un serveur PPP : : : : : : : : : : : : : : : : : : : : : 128

9 Aspects importants du reseau 131


9.1 Le super serveur inetd : : : : : : : : : : : : : : : : : : : : : : : : : : : 131
9.2 Contr^ole d'acces par tcpd : : : : : : : : : : : : : : : : : : : : : : : : : 134
9.3 Les chiers services et protocols : : : : : : : : : : : : : : : : : : : : : : 135
9.4 RPC : appel de procedure distante : : : : : : : : : : : : : : : : : : : : 137
9.5 Con guration des commandes en (( r )) : : : : : : : : : : : : : : : : : : 139

10 NIS : Network Information System 143


10.1 Initiation a NIS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 144
10.2 NIS contre NIS+ : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 147
10.3 Le c^ote client de NIS : : : : : : : : : : : : : : : : : : : : : : : : : : : : 147
10.4 Installer un serveur NIS : : : : : : : : : : : : : : : : : : : : : : : : : : 148
10.5 Securite du serveur NIS : : : : : : : : : : : : : : : : : : : : : : : : : : 149
10.6 Con guration d'un client NIS avec NYS : : : : : : : : : : : : : : : : : 150
10.7 Choisir les bonnes cartes : : : : : : : : : : : : : : : : : : : : : : : : : : 151
10.8 Utilisation des cartes passwd et group : : : : : : : : : : : : : : : : : : : 153
10.9 NIS et les mots de passe shadow : : : : : : : : : : : : : : : : : : : : : 155
10.10Utilisation du code NIS traditionnel : : : : : : : : : : : : : : : : : : : 156

11 NFS, le systeme de chiers par reseau 159


11.1 Veri cations avant usage : : : : : : : : : : : : : : : : : : : : : : : : : : 161
11.2 Monter un volume NFS : : : : : : : : : : : : : : : : : : : : : : : : : : 162
11.3 Les demons NFS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 164
11.4 Le chier exports : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 164
11.5 Montage automatique : l'automonteur : : : : : : : : : : : : : : : : : : 166
x TABLE DES MATIE RES
12 Ma^triser Taylor UUCP 169
12.1 Transferts UUCP et execution a distance : : : : : : : : : : : : : : : : 171
12.1.1 Fonctionnement interne de uucico : : : : : : : : : : : : : : : : : 172
12.1.2 La ligne de commandes de uucico : : : : : : : : : : : : : : : : : 173
12.2 Fichiers de con guration : : : : : : : : : : : : : : : : : : : : : : : : : : 173
12.2.1 Petite introduction a Taylor UUCP : : : : : : : : : : : : : : : : 174
12.2.2 Informations a posseder au prealable : : : : : : : : : : : : : : : 177
12.2.3 Le nom du site : : : : : : : : : : : : : : : : : : : : : : : : : : : 178
12.2.4 Fichiers de con guration Taylor : : : : : : : : : : : : : : : : : : 179
12.2.5 Options de con guration generale | le chier con g : : : : : : 180
12.2.6 Informations sur les sites UUCP voisins | le chier sys : : : : 180
12.2.7 Peripheriques disponibles | le chier port : : : : : : : : : : : : 184
12.2.8 Appeler un numero | le chier dial : : : : : : : : : : : : : : : 186
12.2.9 UUCP sur TCP : : : : : : : : : : : : : : : : : : : : : : : : : : 187
12.2.10Utiliser une connexion directe : : : : : : : : : : : : : : : : : : : 188
12.3 Les erreurs a eviter | securite sous UUCP : : : : : : : : : : : : : : : 188
12.3.1 Execution de commandes : : : : : : : : : : : : : : : : : : : : : 188
12.3.2 Transferts de chiers : : : : : : : : : : : : : : : : : : : : : : : : 189
12.3.3 Relais : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 190
12.4 Con gurer votre systeme en serveur UUCP : : : : : : : : : : : : : : : 191
12.4.1 Con guration de getty : : : : : : : : : : : : : : : : : : : : : : : 191
12.4.2 O rir des comptes UUCP : : : : : : : : : : : : : : : : : : : : : 191
12.4.3 Protection contre les escrocs : : : : : : : : : : : : : : : : : : : : 192
12.4.4 Soyez parano | le test de sequence d'appels : : : : : : : : : : 193
12.4.5 UUCP anonyme : : : : : : : : : : : : : : : : : : : : : : : : : : 194
12.5 Protocoles UUCP de bas niveau : : : : : : : : : : : : : : : : : : : : : : 195
12.5.1 Presentation des protocoles : : : : : : : : : : : : : : : : : : : : 195
12.5.2 Optimisation du protocole de transmission : : : : : : : : : : : 196
12.5.3 Selection des protocoles : : : : : : : : : : : : : : : : : : : : : : 197
12.6 En cas de probleme...: : : : : : : : : : : : : : : : : : : : : : : : : : : : 198
12.7 Les chiers de trace : : : : : : : : : : : : : : : : : : : : : : : : : : : : 199
TABLE DES MATIE RES xi

13 Le courrier electronique 203


13.1 Qu'est-ce qu'un message ? : : : : : : : : : : : : : : : : : : : : : : : : : 204
13.2 Comment le courrier est-il delivre ?: : : : : : : : : : : : : : : : : : : : 207
13.3 Adresses electroniques : : : : : : : : : : : : : : : : : : : : : : : : : : : 208
13.4 Le routage du courrier : : : : : : : : : : : : : : : : : : : : : : : : : : : 209
13.4.1 Routage du courrier sur l'Internet : : : : : : : : : : : : : : : : 209
13.4.2 Routage du courrier dans le monde UUCP : : : : : : : : : : : : 210
13.4.3 Melanger UUCP et RFC 822 : : : : : : : : : : : : : : : : : : : 212
13.5 Format des cartes et du chier pathalias : : : : : : : : : : : : : : : : : 213
13.6 Con guration de elm : : : : : : : : : : : : : : : : : : : : : : : : : : : : 215
13.6.1 Con guration generale par elm.rc : : : : : : : : : : : : : : : : : 216
13.6.2 Jeux de caracteres nationaux : : : : : : : : : : : : : : : : : : : 216
14 Mise en route de smail 219
14.1 Con guration UUCP : : : : : : : : : : : : : : : : : : : : : : : : : : : : 220
14.2 Con guration reseau : : : : : : : : : : : : : : : : : : : : : : : : : : : : 221
14.2.1 Redaction des chiers de con guration : : : : : : : : : : : : : : 222
14.2.2 Mise en route de smail : : : : : : : : : : : : : : : : : : : : : : : 223
14.3 Si le courrier ne passe pas : : : : : : : : : : : : : : : : : : : : : : : : : 224
14.3.1 Compilation de smail : : : : : : : : : : : : : : : : : : : : : : : 226
14.4 Modes de distribution du courrier : : : : : : : : : : : : : : : : : : : : : 226
14.5 Options diverses du chier con g : : : : : : : : : : : : : : : : : : : : : 227
14.6 Routage et distribution : : : : : : : : : : : : : : : : : : : : : : : : : : 228
14.7 Routage des messages : : : : : : : : : : : : : : : : : : : : : : : : : : : 228
14.7.1 La base de donnees paths : : : : : : : : : : : : : : : : : : : : : 230
14.8 Gestion des adresses locales : : : : : : : : : : : : : : : : : : : : : : : : 231
14.8.1 Utilisateurs locaux : : : : : : : : : : : : : : : : : : : : : : : : : 232
14.8.2 Renvoi de courrier : : : : : : : : : : : : : : : : : : : : : : : : : 232
14.8.3 Les alias: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 233
14.8.4 Listes de di usion : : : : : : : : : : : : : : : : : : : : : : : : : 234
14.9 Transport par UUCP : : : : : : : : : : : : : : : : : : : : : : : : : : : : 234
14.10Transport par SMTP : : : : : : : : : : : : : : : : : : : : : : : : : : : : 235
xii TABLE DES MATIE RES
14.11Quali cation de noms : : : : : : : : : : : : : : : : : : : : : : : : : : : 235

15 Sendmail+IDA 237
15.1 Introduction a Sendmail+IDA : : : : : : : : : : : : : : : : : : : : : : : 237
15.2 Apercu des chiers de con guration : : : : : : : : : : : : : : : : : : : 238
15.3 Le chier sendmail.cf : : : : : : : : : : : : : : : : : : : : : : : : : : : : 238
15.3.1 Exemple de chier sendmail.m4 : : : : : : : : : : : : : : : : : : 239
15.3.2 Parametres couramment utilises dans sendmail.m4 : : : : : : : 239
15.4 Presentation des tables de Sendmail+IDA : : : : : : : : : : : : : : : : 245
15.4.1 La table mailertable : : : : : : : : : : : : : : : : : : : : : : : : 245
15.4.2 La table uucpxtable : : : : : : : : : : : : : : : : : : : : : : : : : 246
15.4.3 La table pathtable : : : : : : : : : : : : : : : : : : : : : : : : : 247
15.4.4 La table domaintable : : : : : : : : : : : : : : : : : : : : : : : : 248
15.4.5 Le chier aliases : : : : : : : : : : : : : : : : : : : : : : : : : : 248
15.4.6 Tables rarement utilisees : : : : : : : : : : : : : : : : : : : : : : 249
15.5 Installation de sendmail : : : : : : : : : : : : : : : : : : : : : : : : : : 250
15.5.1 Extraction de la distribution binaire : : : : : : : : : : : : : : : 250
15.5.2 Generation du chier sendmail.cf : : : : : : : : : : : : : : : : : 251
15.5.3 Tests du chier sendmail.cf : : : : : : : : : : : : : : : : : : : : 252
15.5.4 Tests d'integration de sendmail.cf et des tables : : : : : : : : : 254
15.6 Trucs et astuces du parfait petit administrateur : : : : : : : : : : : : : 256
15.6.1 Renvoyer le courrier a une machine relais : : : : : : : : : : : : 256
15.6.2 Forcer du courrier dans des sites mal con gures : : : : : : : : : 256
15.6.3 Forcer le courrier a partir par UUCP : : : : : : : : : : : : : : : 257
15.6.4 Emp^echer le courrier de partir par UUCP : : : : : : : : : : : : 258
15.6.5 Vider sur demande la queue de Sendmail : : : : : : : : : : : : 258
15.6.6 Obtenir des statistiques sur le courrier traite : : : : : : : : : : 259
15.7 Coherence des distributions binaires : : : : : : : : : : : : : : : : : : : 259
15.8 Pour en savoir plus... : : : : : : : : : : : : : : : : : : : : : : : : : : : : 260

16 Les News Usenet 261


16.1 L'histoire de Usenet : : : : : : : : : : : : : : : : : : : : : : : : : : : : 261
TABLE DES MATIE RES xiii

16.2 Mais qu'est-ce que Usenet ? : : : : : : : : : : : : : : : : : : : : : : : : 262


16.3 Comment les News sont-elles gerees sur Usenet ? : : : : : : : : : : : : 263

17 C News 267
17.1 L'injection des articles : : : : : : : : : : : : : : : : : : : : : : : : : : : 267
17.2 Installation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 268
17.3 Le chier sys : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 271
17.4 Le chier active : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 275
17.5 Le traitement par lots (batching) : : : : : : : : : : : : : : : : : : : : : 276
17.6 Expiration des News : : : : : : : : : : : : : : : : : : : : : : : : : : : : 279
17.7 Fichiers divers : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 281
17.8 Les messages de contr^ole : : : : : : : : : : : : : : : : : : : : : : : : : : 283
17.8.1 Le message cancel : : : : : : : : : : : : : : : : : : : : : : : : : 283
17.8.2 Les messages newgroup et rmgroup : : : : : : : : : : : : : : : : 284
17.8.3 Le message checkgroups : : : : : : : : : : : : : : : : : : : : : : 284
17.8.4 Les messages sendsys, version et senduuname : : : : : : : : : : 285
17.9 C News dans un environnement NFS : : : : : : : : : : : : : : : : : : : 286
17.10Outils et travaux de maintenance : : : : : : : : : : : : : : : : : : : : : 287

18 Description du protocole NNTP 289


18.1 Installation du serveur NNTP : : : : : : : : : : : : : : : : : : : : : : : 291
18.2 Restreindre les acces NNTP : : : : : : : : : : : : : : : : : : : : : : : : 291
18.3 Authenti cation NNTP : : : : : : : : : : : : : : : : : : : : : : : : : : 293
18.4 Integration de nntpd dans C News : : : : : : : : : : : : : : : : : : : : 293

19 Les lecteurs de News 295


19.1 Con guration de tin : : : : : : : : : : : : : : : : : : : : : : : : : : : : 296
19.2 Con guration de trn : : : : : : : : : : : : : : : : : : : : : : : : : : : : 297
19.3 Con guration de nn : : : : : : : : : : : : : : : : : : : : : : : : : : : : 298

A C^able port parallele pour PLIP 301


B Exemples de chiers de con guration pour smail 303
xiv TABLE DES MATIE RES
C Licence Publique Generale GNU 311
C.1 Preambule : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 311
C.2 Stipulations et conditions pour copie, distribution et modi cation : : : 312
C.3 Comment appliquer ces directives : : : : : : : : : : : : : : : : : : : : : 317
D SAGE: La guilde des administrateurs systeme 319
Glossaire 321
Bibliographie commentee 329
Livres : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 329
Les (( HOWTO )) : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 333
Les (( HOWTO )), c'est quoi ? : : : : : : : : : : : : : : : : : : : : : : : 333
Index des documents HOWTO : : : : : : : : : : : : : : : : : : : : : : 334
Les RFC : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 335
TABLE DES FIGURES xv

Table des gures


1.1 L'envoi d'un datagramme entre erdos et quark se fait en trois etapes. 9
2.1 Subdivision d'un reseau de classe B : : : : : : : : : : : : : : : : : : : 24
2.2 Une partie de la topologie du reseau a l'universite Groucho Marx. : : 26
2.3 Une partie de l'espace de nommage. : : : : : : : : : : : : : : : : : : : 30
2.4 Un extrait du chier named.hosts pour le Departement de Physique. : 35
2.5 Un extrait du chier named.hosts de l'universite Groucho Marx. : : : 36
2.6 Un extrait du chier named.rev du sous-reseau 12. : : : : : : : : : : : 37
2.7 Un extrait du chier named.rev du reseau 149.76. : : : : : : : : : : : 37
3.1 Les relations entre les interfaces, les pilotes et le materiel. : : : : : : : 40
5.1 Les deux sous-reseaux des brasseurs et viticulteurs. : : : : : : : : : : 64
6.1 Exemple de chier host.conf. : : : : : : : : : : : : : : : : : : : : : : : 85
6.2 Le chier named.boot de la machine kro. : : : : : : : : : : : : : : : : : 89
6.3 Le chier named.ca. : : : : : : : : : : : : : : : : : : : : : : : : : : : : 96
6.4 Le chier named.hosts. : : : : : : : : : : : : : : : : : : : : : : : : : : 97
6.5 Le chier named.local. : : : : : : : : : : : : : : : : : : : : : : : : : : : 97
6.6 Le chier named.rev. : : : : : : : : : : : : : : : : : : : : : : : : : : : : 98
7.1 Un exemple de script pour le programme dip. : : : : : : : : : : : : : : 106
9.1 Un exemple de chier /etc/inetd.conf. : : : : : : : : : : : : : : : : : : 133
9.2 Exemple de chier /etc/services (extrait). : : : : : : : : : : : : : : : : 136
9.3 Exemple de chier /etc/protocols. : : : : : : : : : : : : : : : : : : : : 137
xvi TABLE DES FIGURES
9.4 Un extrait du chier /etc/rpc. : : : : : : : : : : : : : : : : : : : : : : 138
10.1 Exemple de chier nsswitch.conf. : : : : : : : : : : : : : : : : : : : : : 153
12.1 Interaction des chiers de con guration de Taylor UUCP. : : : : : : : 176
15.1 Exemple du chier de con guration gueuze.m4. : : : : : : : : : : : : : 240
15.2 Exemple de chier aliases. : : : : : : : : : : : : : : : : : : : : : : : : : 249
16.1 Circuit des News Usenet a l'universite Groucho Marx. : : : : : : : : : 264
17.1 Flux des News par relaynews. : : : : : : : : : : : : : : : : : : : : : : : 269
Preface xvii

Preface
Vous ^etes sur le point de vous embarquer dans une fantastique aventure : vous allez
entrer dans le monde de Linux. Pour resumer, Linux vous rappellera l'esprit qui
regnait dans les premiers jours de la micro-informatique, ou programmeurs geniaux
et bidouilleurs passionnes passaient des nuits blanches avec un oscilloscope et un fer
a souder pour construire leur propre micro-ordinateur. Les temps ont change, les
outils aussi ; les debogueurs ont remplace la soudure, mais l'etat d'esprit est toujours
present. Linux est ne de cette passion, et gr^ace a lui vous disposez d'un systeme UNIX
pour votre micro-ordinateur, n'ayant rien a envier aux autres implementations.
Malgre ses origines, Linux a evolue et n'est plus reserve aux programmeurs aver-
tis. Chaque jour, des milliers de personnes, de toute culture informatique, adoptent
ce systeme d'exploitation pour toutes sortes d'applications techniques, scienti ques,
educatives, et... bien s^ur, pour le plaisir aussi.
Mais comment Linux a-t-il pu devenir aussi perfectionne et performant, aussi celebre
et apprecie, sans ^etre developpe par une equipe de professionnels surpayes? Le FBI
devrait-il ouvrir une enqu^ete sur ce mystere ? Que se cache-t-il la-dessous ?
La cooperation. Tout le secret est la. Linux est libre, dans tous les sens du terme.
Cette idee de liberte, partagee par tous les programmeurs ayant r^eve de posseder un
jour leur propre systeme UNIX, a permis de realiser des miracles, chacun apportant sa
pierre a l'edi ce. Demandez a n'importe quel developpeur pourquoi il passe des nuits
entieres a travailler sur les sources de Linux. Tous auront la m^eme reponse : la passion
de programmer, et d'o rir le meilleur a la communaute, librement, sans contraintes.
Vous ne realisez peut-^etre pas qu'en utilisant Linux, vous contribuez a l'essor du
logiciel libre, dans le monde entier. Le libre acces aux programmes, avec la possibilite
de les modi er et de les distribuer sans restrictions, est considere par beaucoup comme
un droit fondamental de tout utilisateur d'ordinateur ; au m^eme titre que les droits de
l'homme, la liberte, la recherche de plus gros disques durs, et le digestif apres le cafe.
Le logiciel de nit comment sont utilisees les machines, le systeme d'exploitation en
etant le tout premier exemple. En choisissant un systeme, vous determinez la maniere
dont votre ordinateur fonctionnera, depuis l'interface utilisateur jusqu'aux pilotes de
peripheriques.
xviii Preface
Linux a l'enorme avantage d'^etre developpe par, et pour ses utilisateurs. Le marche du
logiciel n'a aucune in uence sur ses orientations : ce sont les besoins des utilisateurs
qui les de nissent. Cette situation est bien plus saine que de tenter de conquerir un
(( marche )), ou de realiser des pro ts. Cela ne convient sans doute pas a tout le monde,
mais tous ceux qui l'utilisent peuvent avoir une in uence sur son avenir. Pour tout
dire, Linux est votre systeme d'exploitation personnel, domestique, bien a vous. Ce
sera votre compagnon de tous les jours. Que trouver de mieux ?
Power to the people. Linux is here.
Matt Welsh, coordinateur du groupe de documentation Linux, 9 novembre 1994.
1

Chapitre 1
Introduction aux reseaux
1.1 Historique
La notion de reseau est probablement aussi ancienne que le besoin de communiquer
a distance. Transportons-nous a l'^age de pierre, et imaginons que les hommes s'en-
voyaient des messages en frappant sur des tambours ou autres instruments a percus-
sion. Supposons que l'homme des cavernes A veuille inviter son copain B pour jouer
a se lancer des cailloux, mais qu'ils habitent trop loin l'un de l'autre pour pouvoir
entendre leurs signaux sonores respectifs. Quelles sont les solutions possibles ? Il pour-
rait 1) rendre visite a B, 2) prendre un tambour plus gros, ou 3) demander a C, qui
habite a mi-chemin, de faire passer le message. Cette derniere solution s'appelle un
reseau.
Bien s^ur, nous avons parcouru un long chemin depuis les occupations primaires et les
peripheriques primitifs de nos lointains anc^etres. De nos jours, nous possedons des
ordinateurs qui peuvent communiquer entre eux par l'intermediaire d'une vaste toile
d'araignee de c^ables, bres optiques, micro-ondes ou bien d'autres solutions de haute
technologie, a n de pouvoir prendre rendez-vous pour le match de football de samedi
prochain 1 . Dans la description qui va suivre, nous verrons les moyens et methodes
mis en uvre, mais nous laisserons de c^ote les c^ables et la manifestation sportive.
Nous aborderons deux types de reseaux dans ce guide : ceux bases sur UUCP et
ceux bases sur TCP/IP. Ce sont des ensembles de protocoles et de programmes qui
permettent de transferer des donnees entre deux ordinateurs. Dans ce chapitre, nous
verrons les principes de base de chacun de ces reseaux.
Nous de nissons un reseau comme etant un ensemble d'h^otes capables de communi-
quer entre eux, souvent en s'appuyant sur les services d'un certain nombre d'autres
h^otes specialises qui relayent les donnees entre les participants. Ces h^otes sont tres
1 Dont l'esprit original (voir ci-dessus) appara^t encore de temps en temps en Europe.
:
2 Chapitre 1. Introduction aux reseaux
souvent des ordinateurs, mais ce n'est pas obligatoire ; ce peut ^etre tout aussi bien
des terminaux X ou des imprimantes intelligentes. Les petits ensembles d'h^otes sont
appeles sites.
Toute communication est impossible sans le truchement de quelque sorte de langage,
ou de code. Dans le monde des reseaux d'ordinateurs, ces codes sont appeles protocoles.
Toutefois, n'associez pas cette notion aux divers langages ecrits, mais plut^ot aux codes
bien precis de nissant le comportement a adopter lors de rencontres ocielles entre
chefs d'E tats, par exemple. Les protocoles utilises dans les reseaux informatiques ne
sont pas autre chose que des regles tres strictes lors de l'echange de messages entre
plusieurs h^otes.

1.2 Reseaux UUCP


UUCP est l'abreviation de UNIX-to-UNIX Copy. C'etait a l'origine un ensemble de
programmes destines a transferer des chiers par des lignes de communication serie,
plani er ces transferts, et lancer l'execution de programmes sur les sites distants. Il a
subi de profondes modi cations vers la n des annees 70, mais reste toujours spartiate
quant aux services o erts. Son application principale reside encore dans les reseaux a
longue distance b^atis sur des liaisons telephoniques.
UUCP fut cree aux laboratoires Bell en 1977, pour permettre a leurs di erents sites de
developpement UNIX de communiquer. Vers le milieu de l'annee 1978, ce reseau reliait
deja pres de 80 sites, autorisant le courrier electronique et l'impression a distance, bien
que sa plus grande utilisation f^ut alors la distribution de nouveaux programmes et de
corrections de bogues. Aujourd'hui, UUCP n'est plus con ne dans l'environnement
UNIX : il en existe des implementations, libres ou commerciales, pour une grande
variete de plates-formes, dont AmigaOS, DOS, le TOS Atari, etc.
Le plus gros inconvenient des reseaux UUCP est leur faible bande passante : d'une
part, l'equipement telephonique limite la vitesse de la liaison a des valeurs assez
faibles ; et d'autre part, il s'agit rarement de connexions permanentes, chaque h^ote
appelant ses correspondants a intervalles reguliers. Par consequent, chaque fois qu'un
courrier doit traverser un reseau UUCP, il reste bloque sur le disque dur de chaque
machine en attendant que la prochaine connexion soit etablie.
Malgre ces limitations, il existe encore de nombreux reseaux UUCP en fonctionnement
dans le monde entier, exploites principalement par des amateurs, qui permettent a des
particuliers d'obtenir un service pour un prix raisonnable. La raison principale de la
popularite d'UUCP, est son prix derisoire en comparaison d'une connexion au (( gros
c^able Internet )) : il sut d'un modem, d'une implementation correcte du protocole,
et d'un autre site UUCP vous fournissant le courrier et les News Usenet pour ne plus
^etre isole du monde.
1.2. Reseaux UUCP 3

1.2.1 Comment utiliser UUCP


Le principe d'UUCP est tres simple : comme son nom l'indique, il copie des chiers
d'une machine vers une autre, mais il permet egalement d'e ectuer certaines actions
sur le site distant.
Supposons que votre machine possede un acces a un h^ote hypothetique appele renux,
et que vous vouliez qu'il execute la commande d'impression lpr pour vous. Vous pouvez
taper la commande suivante pour imprimer ce livre sur renux 2 :
$ uux -r renux!lpr !netguide.dvi

Cela fera que le programme uux, une commande de l'ensemble UUCP, plani era un job
pour le site renux. Ce job consistera a prendre le chier netguide.dvi et le passer au
programme lpr. L'option -r indique a uux de ne pas appeler immediatement le systeme
distant, mais de stocker cette requ^ete jusqu'a ce qu'une connexion soit etablie. Cela
s'appelle spouler 3 .
UUCP permet aussi de transmettre commandes et chiers a travers plusieurs h^otes,
a condition que ces derniers l'autorisent. Supposons que renux soit en liaison UUCP
avec groucho, qui archive de nombreuses applications UNIX. Pour telecharger le
chier tripwire-1.0.tar.gz vers votre site, vous taperiez la commande :
$ uucp -mr renux!groucho!~/security/tripwire-1.0.tar.gz trip.tgz

Le job cree ici demandera a renux de recuperer le chier sur la machine groucho
et de l'envoyer a votre site, ou votre UUCP le recevra sous le nom trip.tgz ; puis
vous avertira par courrier de son arrivee. Cette operation s'e ectuera en trois etapes.
Tout d'abord, votre site envoie le job a renux. La prochaine fois que renux etablira
le contact avec groucho, il telechargera le chier. En n, la derniere etape sera le
transfert entre renux et votre machine.
De nos jours, la principale activite des reseaux UUCP consiste a transferer le courrier
electronique et les News Usenet.
Le courrier electronique (E-mail en abrege) permet d'echanger des messages entre
utilisateurs de sites distants, sans se preoccuper de savoir comment se connecter sur
ces h^otes. Le travail de routage entre votre machine et le site distant est entierement
realise par le systeme de courrier electronique. Dans un environnement UUCP, les
messages sont generalement transportes en executant la commande rmail sur un h^ote
voisin, en passant l'adresse du destinataire et le contenu du courrier. Le programme
rmail transmettra a son tour les donnees a un autre site, et ainsi de suite jusqu'a
ce qu'il atteigne la machine de destination. Nous reviendrons la-dessus plus en detail
dans le chapitre 13.
2 Si vous utilisez bash, le GNU Bourne Again Shell, ou tout autre shell moderne, vous devrez
:
encoder le point d'exclamation par une sequence d'echappement car c'est le caractere d'historique.
3 Nous sommes desoles, il s'agit bien de l'expression a utiliser en francais pour le spooling...
:
4 Chapitre 1. Introduction aux reseaux
Les (( News )) peuvent ^etre decrites comme un genre de messageries BBS 4 distribuees.
Ce terme designe le plus souvent les News Usenet, qui constituent le plus grand reseau
d'echange de messages au monde, avec un nombre de sites connectes estime a 120 000.
Les origines de Usenet remontent a 1979, ou apres l'introduction d'UUCP avec le
nouvel UNIX V7, trois etudiants imaginerent un systeme d'echange d'informations
au sein de la communaute UNIX. Ils ecrivirent quelques scripts, qui formerent le tout
premier systeme de News. En 1980, ce reseau etait forme de trois sites ; duke, unc
et phs, entre deux universites de Caroline du Nord. Et Usenet grandit a partir de la.
Bien que concu a l'origine autour de UUCP, de nos jours Usenet n'est plus transporte
par ce seul type de reseau.
L'unite d'information est l'article, qui peut ^etre poste dans une hierarchie de forums,
ou newsgroups, dont le debit peut atteindre, a l'heure ou nous ecrivons ces lignes, plus
de 100 megaoctets par jour.
Dans le monde UUCP, les News sont en general transferees par paquets, en rassem-
blant tous les articles des forums demandes dans un certain nombre de batches. Le
site recepteur passe ces chiers au programme rnews, qui les decompacte et assure le
traitement necessaire.
En n, UUCP est egalement un protocole de choix pour de nombreux sites d'archivage
qui o rent un acces public par ligne telephonique ordinaire. On peut generalement
s'y connecter en les appelant par UUCP, sous un nom d'utilisateur invite, comme
guest, nuucp ou encore uucp, pour telecharger les chiers publics. Les mots de
passe courants pour ce type d'acces sont souvent simplement uucp, nuucp, parfois
m^eme aucun mot de passe n'est necessaire.

1.3 Reseaux TCP/IP


Bien qu'UUCP puisse ^etre un choix raisonnable pour des liaisons telephoniques a
faible co^ut, il est de nombreuses situations ou sa technique de routage des informations
s'avere trop rigide, inadaptee ; c'est le cas par exemple dans les reseaux locaux, ou
LAN 5 . Ceux-ci sont en general constitues d'un petit nombre de machines situees dans
le m^eme b^atiment, voire au m^eme etage, interconnectees a n d'o rir un environnement
de travail etendu, puissant et homogene. Des exemples typiques sont le partage de
chiers entre les di erents h^otes, ou l'execution d'applications partagees sur di erentes
machines.
Ce type d'utilisation necessite une approche totalement di erente du fonctionnement
en reseau. Au lieu de transferer des chiers entiers associes a la description des t^aches a
executer, toutes les donnees sont tronconnees en petits morceaux (paquets), qui sont
immediatement expedies a l'h^ote destinataire, qui les reassemble a l'arrivee. Cette
4 Les BBS, ou Bulletin Board System, appeles egalement babillards au Quebec, sont des serveurs
:
proposant di erents forums de messageries, ou conferences, dans lesquels les utilisateurs debattent
par ecrit de sujets divers.
5 LAN : Local Area Network.
:
1.3. Reseaux TCP/IP 5

methode s'appelle un reseau a commutation de paquets. Entre autres choses, cela


permet d'utiliser des applications interactives a travers le reseau ; le prix a payer est,
bien entendu, une plus grande complexite du code mis en uvre.
La solution adoptee sur les systemes UNIX (et beaucoup d'autres sites non UNIX)
est connue sous le nom de TCP/IP. Nous allons voir de quoi il retourne.

1.3.1 Introduction aux reseaux TCP/IP


TCP/IP est ne d'un projet de recherche au sein du United States Defense Advanced
Research Projects Agency (DARPA), en 1969. Le reseau experimental ARPANET
devint operationnel en 1975, apres avoir prouve son succes.
En 1983, la nouvelle suite de protocoles TCP/IP fut adoptee comme standard, et
tous les h^otes du reseau durent alors l'utiliser. Lorsque ARPANET nit par gran-
dir et se transformer en Internet (ARPANET en lui-m^eme ayant cesse d'exister en
1990), l'usage de TCP/IP s'etait deja etendu bien au-dela de ce seul Internet. Les re-
seaux locaux UNIX en sont l'exemple notoire, mais l'avenement des communications
telephoniques numeriques telles qu'ISDN 6 , lui promet la aussi un bel avenir.
Pour prendre un exemple concret tout au long des explications qui vont suivre, nous
imaginerons l'universite Groucho Marx (UGM), situee quelque part au pays de Fred-
land. La plupart des laboratoires ont leur propre reseau local, d'autres en ont un en
commun et certains en comptent plusieurs. Ils sont tous interconnectes et relies a
l'Internet par une unique ligne a haut debit.
Supposons que votre systeme Linux s'appelle erdos et soit connecte au reseau local
de machines UNIX du Departement de Mathematiques. Pour acceder a un h^ote du
Departement de Physique, disons quark, vous taperez la commande suivante :
$ rlogin quark.physics
- Universite Groucho Marx -
Bienvenue au departement physique
(ttyq2) login:

A l'invite login, vous entrez alors votre nom d'utilisateur, par exemple dugenou,
puis votre mot de passe. Vous obtenez alors un shell sur la machine quark, exactement
comme si vous etiez devant la console de cet ordinateur. Votre travail termine, en sor-
tant de ce shell vous revenez a l'invite de votre propre machine. Vous venez d'utiliser
l'une des applications interactives instantanees o ertes par TCP/IP : le login distant.
Lors de votre session sur quark, vous pouvez avoir besoin d'utiliser une application
graphique sous X Window, par exemple un previsualiseur PostScript. Vous devez alors
indiquer a ce programme que ses fen^etres doivent s'acher sur votre ecran, et non sur
:6 ISDN correspond a l'etranger a ce que nous appelons RNIS en France (reseau numerique a
integration de services), commercialise sous le nom de NUME RIS.
6 Chapitre 1. Introduction aux reseaux
celui de la machine sur laquelle il s'execute. Cela se fait en positionnant la variable
d'environnement DISPLAY :
$ export DISPLAY=erdos.maths:0.0

Si maintenant vous lancez votre application, elle contactera votre serveur X au lieu de
celui de quark, et tout s'achera sur votre propre ecran. Bien s^ur, il va de soi que vous
devez deja travailler sous X11 sur votre machine erdos. En realite, TCP/IP permet
a quark et erdos de s'echanger les paquets X11 a n de vous donner l'illusion d'^etre
sur un systeme unique. Vous constatez ici que le reseau est totalement transparent.
Une autre application tres importante rendue possible par TCP/IP s'appelle NFS,
Network File System (systeme de chiers par reseau). Il s'agit d'une autre maniere
de rendre le reseau transparent, qui vous permet litteralement de monter des hierar-
chies de repertoires depuis d'autres h^otes, de telle maniere qu'elles vous apparaissent
comme des systemes de chiers locaux. Par exemple, tous les repertoires personnels
des utilisateurs peuvent ^etre situes sur un serveur central depuis lequel chaque h^ote
du reseau monte cette arborescence. Le resultat est que chaque utilisateur peut em-
ployer n'importe quelle machine en se retrouvant, quoi qu'il arrive, dans le m^eme
repertoire. De m^eme, il est possible de n'installer des applications tres gourmandes
en place disque (comme TEX) que sur un seul ordinateur et d'exporter ces repertoires
pour que les autres h^otes puissent s'en servir. Nous reviendrons plus en detail sur
NFS dans le chapitre 11.
Bien s^ur, ce ne sont que quelques exemples simples de ce que vous pouvez realiser
gr^ace aux reseaux TCP/IP ; leurs possibilites ne sont limitees que par l'imagination.
Nous allons maintenant regarder d'un peu plus pres le fonctionnement de TCP/IP.
Vous comprendrez ainsi comment et pourquoi con gurer votre machine. Nous com-
mencerons par l'equipement materiel necessaire, et petit a petit nous guiderons vos
premiers pas.

1.3.2 Ethernet
L'equipement materiel le plus utilise pour la realisation de reseaux locaux est ce que
l'on appelle l'Ethernet. Il consiste en un simple c^able coaxial, sur lequel est connecte
chaque h^ote par l'intermediaire de connecteurs, ou de bo^tiers electroniques nommes
transceivers. Les reseaux Ethernet sont extr^emement peu co^uteux et simples a instal-
ler, et leur vitesse de transfert etant de 10 megabits par seconde, ils rencontrent un
succes toujours grandissant.
Il existe trois categories d'Ethernet : n, gros, et paire torsadee. Les deux premiers
utilisent un c^able coaxial, qui di ere dans sa taille et la maniere de s'y connecter.
L'Ethernet n utilise des connecteurs (( BNC )) en (( T )), que vous pouvez inserer au
milieu du c^able reseau et brancher sur la prise prevue a cet e et a l'arriere de l'ordi-
nateur. Le gros Ethernet s'utilise en faisant un petit trou dans le c^able et en connec-
tant un transceiver par l'intermediaire d'une (( pince vampire )). Ces bo^tiers peuvent
1.3. Reseaux TCP/IP 7

supporter un ou plusieurs h^otes. Ces deux variantes supportent respectivement des


distances d'utilisation de 200 et 500 metres, d'ou leurs denominations : 10base-2 et
10base-5. La paire torsadee utilise deux ls de cuivre ordinaires et necessite un bo^tier
additionnel appele hub ; elle est connue sous le nom de 10base-T.
Bien que rajouter un h^ote sur un c^able Ethernet n soit un peu g^enant, cela n'ar-
r^ete pas le reseau : le service est juste interrompu pendant un moment tres court, le
temps de couper le c^able (en debranchant une prise s'il est bien concu) a n d'inse-
rer le connecteur necessaire. Cette operation ne prend que quelques secondes, au pis
quelques minutes.
La majorite des utilisateurs preferent l'Ethernet n pour des raisons economiques;
on trouve des cartes pour PC a partir de 300 francs et le c^able ne co^ute que quelques
dizaines de centimes le metre. Toutefois, pour de grosses installations, le gros Ethernet
est beaucoup plus approprie ; il n'est par exemple pas necessaire d'interrompre le tra c
quelques secondes pour connecter une nouvelle machine sur le reseau.
La longueur de c^able maximale est l'un des principaux inconvenients de la technologie
Ethernet. Toutefois, on peut relier plusieurs segments par l'intermediaire de repeteurs,
ponts ou routeurs. Les repeteurs copient simplement les signaux entre plusieurs tron-
cons a n qu'ils apparaissent comme un unique c^able Ethernet. En raison de la vitesse
necessaire, il ne peut pas y avoir plus de quatre repeteurs entre deux h^otes quelconques
du reseau. Les ponts et routeurs sont beaucoup plus sophistiques : ils analysent les
donnees recues et ne les retransmettent que lorsque la machine destinataire n'est pas
situee sur l'Ethernet local.
L'Ethernet se comporte comme un bus, ou chaque h^ote peut envoyer des paquets
(ou trames) pouvant atteindre 1 500 octets vers une autre machine du m^eme reseau.
Chaque ordinateur possede une adresse unique au monde formee de 6 octets, inscrite
dans la carte Ethernet lors de sa fabrication. Ces adresses sont generalement achees
comme une sequence de nombres hexadecimaux sur deux digits, separes par un deux-
points, comme aa:bb:cc:dd:ee: .
Une trame envoyee par une station est vue par toutes les autres, mais seule la machine
destinataire l'extrait et l'utilise. Si deux h^otes tentent d'envoyer un paquet au m^eme
moment, il se produit une collision, dans ce cas les deux machines abandonnent l'envoi
et recommencent quelques instants plus tard.

1.3.3 Autres types de materiel


Dans les tres grosses installations reseau, l'Ethernet n'est generalement pas le seul
support utilise. A l'universite Groucho Marx, chaque reseau local est relie a la dorsale
du campus (backbone), qui est une bre optique utilisant FDDI (Fiber Distributed
Data Interface). FDDI utilise une approche totalement di erente pour transmettre les
donnees, qui consiste a di user un certain nombre de jetons, chaque station n'etant
alors autorisee a emettre une trame que si elle capture un jeton. Le principal avantage
de FDDI est la vitesse, pouvant atteindre 100 Mbps, ainsi qu'une longueur de c^able
8 Chapitre 1. Introduction aux reseaux
allant jusqu'a 200 km.
Pour de tres longues distances, on utilise frequemment un autre type de transport,
base sur un standard appele X.25. Beaucoup de reseaux utilisent ou o rent ce service ;
on peut citer Tymnet aux E tats-Unis, Datex-P en Allemagne, ou Transpac en France.
X.25 necessite un equipement special appele PAD (Assembleur/Desassembleur de
paquets). X.25 de nit un ensemble de protocoles qui lui sont propres, mais qui sont
neanmoins utilises couramment pour relier des reseaux utilisant TCP/IP ou tout
autre protocole. Comme les trames IP ne peuvent pas ^etre converties de facon simple
en paquets X.25, la methode employee est l'encapsulation. Chaque paquet IP est
encapsule dans une trame X.25 et envoye sur le reseau.
Tres souvent, les radio-amateurs utilisent leur equipement pour relier leurs machines
en reseau par ondes hertziennes ; il s'agit du packet radio (ou ham radio). Le protocole
utilise s'appelle AX.25, et est derive de X.25.
D'autres techniques mettent en uvre des liaisons series lentes mais tres economiques
pour acceder au reseau par ligne telephonique. La encore, d'autres protocoles de trans-
mission de paquets sont employes, comme SLIP ou PPP, que nous decrirons plus loin.

1.3.4 Le protocole Internet


Bien s^ur, vous ne voudriez pas d'un reseau limite a un simple brin d'Ethernet. L'ideal
serait que vous puissiez vous connecter partout, quel que soit le materiel utilise ou
le nombre de sous-reseaux composant l'installation. L'universite Groucho Marx par
exemple, possede plusieurs reseaux locaux interconnectes. Le Departement de Mathe-
matiques en a deux : le premier reliant les ordinateurs puissants pour les enseignants
et chercheurs, le second, plus lent et moins bien equipe, destine aux etudiants. Tous
deux sont relies a la dorsale FDDI du campus.
Cette connexion est geree par un h^ote dedie que l'on appelle alors passerelle ; son r^ole
est de copier les paquets entrants et sortants entre les reseaux Ethernet et la bre
optique de l'universite. Par exemple, si vous ^etes au Departement Mathematiques et
que vous desirez acceder a la machine quark du Departement de Physique depuis
votre systeme Linux, les programmes reseau ne peuvent pas envoyer directement les
paquets a destination car quark n'est pas sur le m^eme Ethernet. Les paquets seront
donc envoyes a la passerelle qui fera le relais. Celle-ci (appelons-la sophus) passera
les trames a la passerelle du Departement de Physique (niels) par l'intermediaire de
la dorsale, et niels les delivrera a la machine destinataire. Le parcours des donnees
entre erdos et quark est montre dans la gure 1.1.
Cette facon de diriger les donnees vers leur destination s'appelle le routage, et dans
ce contexte, les paquets sont souvent appeles datagrammes. Pour simpli er les choses,
l'echange des datagrammes est gere par un unique protocole independant du materiel
utilise : IP, ou Internet Protocol. Nous decrirons plus en detail IP et le routage dans
le chapitre 2, page 19.
1.3. Reseaux TCP/IP 9

Dorsale bre optique du campus

2
niels sophus

Reseau Ethernet du Reseau Ethernet du


3 Departement de Physique Departement Mathematiques 1

quark

erdos

Fig. 1.1 - L'envoi d'un datagramme entre erdos et quark se fait en trois etapes.
10 Chapitre 1. Introduction aux reseaux
Le bene ce apporte par IP est de faire appara^tre des reseaux physiquement di erents
en un seul reseau homogene. Cela se nomme l'interconnexion de reseaux, et le (( meta-
reseau )) resultant est appele un internet. Notez bien la subtilite entre un internet et
l' Internet. Ce dernier terme est le nom ociel d'un internet mondial particulier.
Bien s^ur, IP necessite aussi une methode d'adressage independante du materiel. Pour
ce faire, on assigne a chaque h^ote un nombre unique sur 32 bits, appele l'adresse IP.
Une adresse IP est generalement notee sous la forme de quatre nombres decimaux, un
pour chaque portion de 8 bits, separes par des points. Par exemple, quark pourrait
avoir une adresse IP de 0x954C0C04, qui serait alors ecrite 149.76.12.4 ; ce format
est connu sous le nom evident de notation sur 4 octets, vous verrez aussi tres souvent
l'appellation anglaise dotted quad.
Vous noterez que nous avons maintenant trois types d'adresses di erents : tout d'abord
le nom d'h^ote, comme quark, puis les adresses IP, et en n les adresses materielles, les
6 octets de l'interface Ethernet. Toutes doivent ^etre liees, de sorte que lorsque vous
tapez rlogin quark, la partie logicielle du reseau puisse obtenir l'adresse IP de quark ;
et quand IP delivre des donnees a l'Ethernet du Departement de Physique, il puisse
determiner a quelle adresse materielle correspond cette adresse IP.
Nous verrons comment tout cela est realise dans le chapitre 2. Pour l'instant, il vous
sura de savoir que ces etapes se nomment la resolution de noms, pour ce qui est de
faire correspondre les noms d'h^otes en adresses IP, et resolution d'adresses, pour la
correspondance de cette derniere en adresse materielle.

1.3.5 IP sur lignes serie


Sur des liaisons serie, on utilise frequemment un standard (( de fait )) connu sous le nom
de SLIP, Serial Line IP. CSLIP (Compressed SLIP) en est une amelioration; il e ectue
une compression des en-t^etes IP pour tirer un meilleur parti du debit relativement
faible o ert par une ligne serie 7. PPP, ou Point-to-Point Protocol, est un protocole
di erent destine au m^eme usage ; il est plus evolue que SLIP. Son principal avantage
est de ne pas ^etre limite au transport de datagrammes IP, car il a ete concu pour
transporter tout type de paquets.

1.3.6 Le protocole TCP


Mais pouvoir envoyer des paquets d'une machine a l'autre n'est pas tout. Si vous vous
connectez sur quark, vous aurez besoin d'une connexion able entre votre processus
rlogin sur erdos et le shell lance sur quark. Par consequent, les informations envoyees
et recues devront ^etre tronconnees en paquets par l'emetteur, et reassemblees en un
ux de caracteres par le recepteur. Bien que paraissant tres simple, cette operation
entra^ne un certain nombre de t^aches complexes.
7 SLIP est decrit dans le RFC 1055, et CSLIP dans le RFC 1144.
:
1.3. Reseaux TCP/IP 11

Il est tres important de savoir que IP, par conception, n'est pas un protocole able.
Supposons que dix personnes, sur votre reseau Ethernet, soient en train de telecharger
la derniere version de XFree86 depuis le serveur ftp de GMU. Le tra c genere peut
alors devenir trop important pour la passerelle, si elle est trop lente ou manque de
memoire. Si a ce moment, vous envoyez un paquet a destination de quark, sophus
pourrait se trouver a cours de ressources pendant quelques instants et ne pas pouvoir
traiter vos donnees. IP resout ce probleme d'une facon tres simple : il elimine le paquet,
qui est irremediablement perdu. Par consequent, la responsabilite de veri er l'integrite
des donnees transmises, et de les retransmettre en cas d'erreur est celle des h^otes en
communication.
Ce r^ole est assure par un autre protocole : TCP, ou Transmission Control Protocol, qui
cree un service able par-dessus IP, en prenant en charge le contr^ole de la transmission.
La propriete la plus importante de TCP est d'utiliser IP a n de donner l'illusion d'une
simple connexion entre les deux processus distants, de maniere a ce qu'il n'y ait pas a
se preoccuper du routage des donnees. Une connexion TCP fonctionne un peu comme
un tube bidirectionnel dans lequel chaque programme peut lire et ecrire. Vous pouvez
l'imaginer comme une conversation telephonique, par exemple.
TCP identi e chaque bout d'une telle connexion par les adresses IP des h^otes concer-
nes, et un numero de port sur chacun d'eux. Les ports peuvent ^etre vus comme des
points d'attache pour les connexions reseau. En prenant encore une fois le telephone
comme exemple, on pourrait comparer les adresses IP aux codes regionaux (un numero
par ville), et les ports aux numeros individuels (un numero par abonne) 8.
Dans notre exemple de rlogin, l'application cliente (rlogin) ouvre un port sur erdos
et se connecte au port 513 du systeme quark, dont le serveur rlogind est a l'ecoute.
Il s'etablit alors une connexion TCP. Par l'intermediaire de cette connexion, rlogind
e ectue la procedure d'autorisation d'acces, puis lance l'execution du shell. L'entree
et la sortie standard de ce dernier sont redirigees vers la connexion TCP de sorte
que tout ce que vous tapez sur votre machine dans rlogin soit envoye au ux TCP et
aboutisse a l'entree standard du shell distant.

1.3.7 Le protocole UDP


Bien s^ur, TCP n'est pas le seul protocole utilisateur sur un reseau TCP/IP. Bien que
parfait pour des utilisations comme rlogin, la surcharge induite le rend peu ecace
pour des applications comme NFS, qui utilise plut^ot le protocole UDP, ou User Data-
gram Protocol. Tout comme TCP, il permet a un programme de contacter un service
sur un port donne de la machine distante, mais il n'etablit aucune connexion. UDP
est utilise pour envoyer simplement des paquets, d'ou son nom.
Supposons que vous ayez monte le repertoire TEX de galois, le serveur NFS central
du departement, et que vous desiriez voir un document decrivant le mode d'emploi de
LaTEX. Vous appelez votre editeur de texte, qui commence par lire la totalite du chier.
8 La numerotation telephonique est faite di eremment en France.
:
12 Chapitre 1. Introduction aux reseaux
Toutefois, etablir une connexion TCP avec galois, envoyer le chier, puis deconnecter
prendrait bien trop de temps. A la place, une requ^ete est envoyee a galois, qui envoie
alors le chier dans deux ou trois paquets UDP, ce qui est bien plus rapide. Mais UDP
n'est pas concu pour gerer la perte ou la corruption des donnees ; c'est a l'application,
NFS dans le cas present, de prendre en charge ces problemes eventuels.

1.3.8 Les ports


Les ports sont, en quelque sorte, des points d'attache logiciels pour les connexions
reseau. Si une application desire o rir un certain service, elle s'attache a un port
et attend les clients (on dit aussi qu'elle ecoute le port). Un client voulant utiliser
ce service alloue alors un port sur sa machine locale, puis se connecte a celui de
l'application serveur sur le systeme distant.
Une fois qu'une connexion est etablie entre le client et le serveur, une des caracte-
ristiques importantes des ports est qu'une autre copie du serveur peut s'y attacher
et continuer ainsi l'ecoute dans l'attente d'autres clients. Cela permet par exemple,
plusieurs sessions rlogin concurrentes sur la m^eme machine distante, toutes utilisant le
port 513. TCP est capable de di erencier les connexions car elles proviennent toutes
de di erents ports ou h^otes. Par exemple, si vous avez deux rlogin sur quark depuis
erdos, le premier client utilisera le port local 1023, et le second le 1022. Tous deux
se connecteront neanmoins au m^eme port 513 sur quark.
Cet exemple montre l'utilisation des ports en tant que points de rencontre, ou les
serveurs donnent rendez-vous aux clients desirant un service particulier. A n que
ces clients sachent quel numero de port contacter, les administrateurs des di erents
systemes connectes doivent se mettre d'accord sur leur assignation. En ce qui concerne
les services les plus couramment utilises, comme rlogin, ces numeros doivent ^etre
administres de maniere centrale : c'est le r^ole de l'IETF (Internet Engineering Task
Force), qui publie regulierement un RFC intitule Assigned Numbers. Ce document
decrit, entre autres choses, les numeros de port assignes aux services les plus connus
utilises mondialement. Linux utilise, comme beaucoup d'autres systemes, un chier
nomme /etc/services, qui contient la correspondance entre les noms de ces services et
les numeros de ports qui leur sont associes.
Bien que les connexions TCP et UDP se basent sur les ports, il faut noter que ces
numeros n'entrent pas en con it. Comprenez par la que le port TCP 513, par exemple,
est di erent du port UDP 513 : ils correspondent en pratique a rlogin (TCP) et rwho
(UDP).

1.3.9 Les sockets


Dans les systemes d'exploitation UNIX, la partie logicielle responsable des t^aches et
des protocoles que nous venons de decrire succinctement fait generalement partie du
noyau ; Linux ne fait pas exception a la regle. L'interface de programmation reseau
1.4. Le reseau sous Linux 13

la plus courante dans le monde UNIX est la bibliotheque de sockets de Berkeley. Ce


nom, qui dans un contexte technique signi e (( prise )), ou (( connecteur )) en anglais,
provient de l'analogie courante faite entre les ports et des prises, sur lesquels on vient
se (( brancher )) pour realiser la connexion. Cette bibliotheque o re la fonction bind
pour speci er un h^ote distant, un protocole de transport, et un service auquel un
programme peut se connecter ou bien ecouter (gr^ace aux fonctions connect, listen et
accept). Elle est assez generaliste, en ce sens qu'elle contient non seulement une classe
de sockets TCP/IP (AF INET), mais egalement une classe qui permet les connexions
locales a la machine (les sockets AF UNIX). Quelques implementations comportent
m^eme d'autres classes, comme le protocole XNS (Xerox Networking System) ou X.25.
Sous Linux, la bibliotheque de sockets est partie integrante de la bibliotheque C
standard, libc. A l'heure actuelle, elle ne supporte que AF INET et AF UNIX, mais
d'autres protocoles sont en developpement et appara^tront sans doute dans l'avenir.

1.4 Le reseau sous Linux


E tant le fruit de developpeurs du monde entier, Linux n'aurait jamais pu voir le jour
sans le reseau mondial. Aussi, il n'est pas surprenant que tout au debut, plusieurs
personnes aient entrepris de lui apporter les possibilites reseau necessaires. Des les
toutes premieres versions, il etait deja possible d'utiliser UUCP, et le travail sur
les couches TCP/IP debuta en automne 1992, lorsque Ross Biro et quelques autres
creerent ce qui est maintenant connu sous le nom de Net-1.
Ross dut cesser ses activites de developpement pour Linux au mois de mai 1993, et
Fred van Kempen commenca a travailler sur une nouvelle implementation, reecrivant
de grandes parties du code. Cette etape prit le nom de Net-2, dont la premiere ver-
sion publique, Net-2d, fut di usee en ete 1993 (dans le noyau 0.99.10), et a depuis ete
maintenue et amelioree par plusieurs personnes, en particulier Alan Cox, sous l'ap-
pellation Net-2Debugged. Apres de grandes periodes de deboguage et de nombreux
perfectionnements, ce nom fut change en Net-3 apres la sortie de Linux 1.0. C'est la
version du code reseau actuellement incluse dans les versions ocielles du noyau, a
l'heure ou nous ecrivons ces lignes.
Net-3 o re des pilotes pour une large gamme de cartes Ethernet, aussi bien que
SLIP, PPP (pour des connexions reseau via une liaison serie), et PLIP (pour utiliser
le port imprimante parallele dans le m^eme but). Avec Net-3, Linux est dote d'une
implementation de TCP/IP qui se comporte parfaitement bien dans la plupart des
environnements reseaux, avec une abilite depassant certains Unix commerciaux pour
PC. Le developpement continue, a n d'assurer une stabilite encore meilleure en toutes
circonstances sur les h^otes o rant des services sur l'Internet.
En plus de tout cela, certains projets sont en cours, qui augmenteront encore davan-
tage l'universalite de Linux. Un pilote AX.25 pour packet-radio est en Alpha test, et
Alan Cox a egalement implemente une partie du protocole IPX de Novell. Mais ce
dernier projet n'avance pas, car Novell n'a pas l'intention de fournir la documentation
14 Chapitre 1. Introduction aux reseaux
necessaire a son aboutissement. Andrew Tridgell a realise samba, un serveur NetBIOS 9
gratuit pour systemes Unix dont les premieres versions sont tres prometteuses.

1.4.1 Orientations du developpement


Fred a continue parallelement son developpement pour faire Net-2e, une approche
profondement nouvelle des couches reseau. Toutefois, on n'a pas entendu parler de ce
travail depuis longtemps.
Il existe une autre implementation de TCP/IP realisee par Matthias Urlichs, qui a
ecrit un pilote ISDN pour Linux et FreeBSD, en integrant une partie du code reseau
de BSD dans le noyau Linux.
Malgre tout, Net-3 semble maintenant destine a rester la version ocielle. Les (( mo-
dules )), qui permettent d'ajouter des pilotes de peripheriques au noyau pendant le
fonctionnement du systeme, donneront sans nul doute un coup de fouet au develop-
pement et la partie reseau s'enrichira sans doute de nombreuses possibilites au l du
temps.
Bien que ces di erentes implementations des couches reseau s'e orcent d'o rir le
m^eme service, elles comportent d'importantes di erences au niveau noyau et pilotes.
Par consequent, vous ne pourrez pas con gurer un systeme comportant un noyau avec
Net-2e a l'aide des utilitaires en provenance de Net-2d ou Net-3, et vice versa. Cela ne
s'applique qu'aux commandes tres proches du noyau ; les applications et programmes
usuels comme rlogin ou telnet fonctionneront bien s^ur avec n'importe quelle version.
Quoi qu'il en soit, cette legere confusion ne devrait pas vous inquieter. A moins que
vous ne participiez activement au developpement, vous n'aurez pas a vous soucier de
ces di erentes versions de TCP/IP. Les versions ocielles du noyau seront toujours
accompagnees des outils reseau compatibles avec l'implementation courante.

1.4.2 Ou se procurer le code


Le derniere version du code reseau de Linux peut ^etre obtenue par FTP anonyme au-
pres de di erents serveurs. Le site ociel pour Net-3 est sunacm.swan.ac.uk, repris
par sunsite.unc.edu dans le repertoire system/Network/sunacm. Les dernieres ver-
sions connues de Net-2e se trouvent sur ftp.aris.com. Les travaux derives de BSD, par
Matthias Urlichs, sont sur ftp.ira.uka.de dans le repertoire /pub/system/linux/netbsd.
Le code source des derniers noyaux en date, ainsi que les versions en cours de de-
veloppement se trouvent dans le repertoire /pub/OS/Linux/PEOPLE/Linus du site
nic.funet. ; qui est repris par de nombreux serveurs 10.
9: NetBIOS est le protocole sur lequel sont basees certaines applications comme lanmanager et
Windows for Workgroups.
10: En France, avant d'utiliser de co^uteuses liaisons internationales, vous devez visiter le site
ftp.ibp.fr. Ce serveur est le site Linux de reference pour la France, et tient a jour un miroir des
principaux sites etrangers.
1.5. Maintenance du systeme 15

1.5 Maintenance du systeme


Tout au long de ce livre, nous traiterons principalement de procedures d'installation
et de con guration. Neanmoins, l'administration d'un systeme est bien plus que cela :
une fois un service installe, vous devez le maintenir en parfait etat de fonctionnement.
Dans la plupart des cas, il sut d'un peu d'attention ; mais certains, comme le courrier
et les News, necessitent un entretien de routine. Nous verrons en quoi consistent ces
di erentes t^aches d'administration dans les chapitres qui vont suivre.
La maintenance minimale consiste a regarder regulierement les chiers de trace du
systeme et des di erentes applications, a la recherche d'eventuelles erreurs ou evene-
ments inhabituels. Le plus simple est d'ecrire quelques shell-scripts qui seront executes
automatiquement par cron a certaines heures. Les applications importantes, comme
C News ou smail, sont souvent fournies avec de tels programmes qu'il ne vous reste
plus qu'a modi er legerement pour les adapter a vos besoins particuliers.
La sortie de tous les travaux executes par cron doit faire l'objet d'un courrier envoye
dans la bo^te aux lettres d'un compte administratif. Par defaut, beaucoup d'applica-
tions postent leurs erreurs ou statistiques a l'utilisateur root. Cela n'a d'inter^et que
si vous vous connectez souvent sous ce compte, ce qui est deconseille. Une solution
bien meilleure sera de rediriger le courrier de root vers votre compte personnel en
declarant un alias, comme decrit dans le chapitre 14.
Quel que soit le soin apporte a la con guration de votre site, les lois de Murphy garan-
tissent que malgre tout, certains problemes se produiront. Par consequent, maintenir
un systeme signi e egalement ^etre disponible pour repondre aux reclamations. Gene-
ralement, on considere que l'administrateur systeme doit au minimum pouvoir ^etre
joint par courrier electronique au compte root, mais il existe aussi d'autres adresses
traditionnellement utilisees pour des aspects ou services speci ques. Par exemple, tout
ce qui concerne le fonctionnement du courrier electronique est envoye a postmaster,
alors que pour ce qui est des News Usenet, il s'agira de newsmaster ou usenet.
Un message a destination de hostmaster devra ^etre redirige vers la personne en
charge de la con guration reseau de base, et du serveur de noms si vous fournissez un
DNS.

1.5.1 Securite du systeme


Proteger votre machine et ses utilisateurs des intrus est un aspect tres important
de l'administration systeme dans un environnement reseau. Negliger ce point peut
o rir de nombreuses cibles aux malfaisants, les attaques pouvant aller de tentatives
de decryptage des mots de passe a l'analyse de datagrammes, avec des consequences
diverses comme courriers falsi es, destructions de donnees ou entrave a la vie privee
de vos utilisateurs. Nous mentionnerons quelques-uns de ces problemes lorsque nous
decrirons le contexte dans lequel chacun peut se produire, et les solutions les plus
courantes employees pour se proteger.
16 Chapitre 1. Introduction aux reseaux
Il est evidemment impossible de detailler ici tous les ennuis de securite auxquels vous
serez peut-^etre confronte. La lecture d'un ouvrage specialise est absolument necessaire,
particulierement en environnement reseau. Le livre (( Practical UNIX Security )), de
Simson Gar nkel (voir [Spaf93]) est hautement recommande.
La securite commence par une bonne administration systeme. Cela comprend la ve-
ri cation des proprietaires et droits d'acces des chiers vitaux et des repertoires,
l'observation de l'utilisation des comptes privilegies, etc. Le programme COPS, par
exemple, permet de tester le systeme de chiers et la con guration courante a la re-
cherche de permissions dangereuses ou autres anomalies. Il est souvent raisonnable
d'utiliser une gestion des mots de passe les rendant plus diciles a deviner. L'ensemble
shadow password suite, par exemple, demande entre autres choses qu'ils aient une lon-
gueur minimale de cinq caracteres et comportent un ensemble de lettres minuscules,
majuscules et chi res.
Lors de la creation d'un service accessible par reseau, assurez-vous de ne lui donner
que les privileges minimaux, ne lui permettez pas de faire des choses inutiles pour
son fonctionnement normal. Par exemple, vous ne devez faire de programmes setuid a
root ou tout autre utilisateur privilegie que lorsque c'est vraiment necessaire. Si vous
desirez n'utiliser un service que pour une application tres limitee, n'hesitez pas a le
con gurer de maniere aussi restrictive que possible. Si par exemple vous comptez au-
toriser des stations diskless a s'amorcer depuis votre machine, vous devez o rir TFTP
(Trivial File Transfer Protocol) a n qu'elles puissent telecharger leur con guration de
base depuis le repertoire /boot. Toutefois, utilise sans restrictions, TFTP permet a
n'importe quel utilisateur du monde de telecharger tout chier de votre machine qui
soit lisible par tous. Si ce n'est pas ce que vous desirez, pourquoi ne pas restreindre
le service TFTP au repertoire /boot ? 11 .
Dans le m^eme ordre d'idees, vous pouvez restreindre l'acces a certains services a
des utilisateurs de certains h^otes, par exemple ceux de votre reseau local. Dans le
chapitre 9, nous presenterons tcpd, qui permet cette operation pour une grande variete
d'applications reseaux.
Un autre point tres important : eviter les logiciels a risque. Bien s^ur, tous les pro-
grammes que vous utilisez peuvent ^etre dangereux, puisqu'ils peuvent receler des
bogues que des personnes malintentionnees pourraient exploiter pour penetrer dans
votre systeme. Ce genre de situation arrive, et il n'existe malheureusement pas de
protection a toute epreuve. Ces problemes a ectent aussi bien les applications du
domaine public que les produits commerciaux 12. Toutefois, les programmes neces-
sitant des privileges particuliers sont fatalement plus dangereux que les autres, car
le moindre trou de securite peut avoir de graves consequences 13. Si vous installez
11 Nous reviendrons sur ce sujet dans le chapitre 9.
:
12 Il y a eu des systemes UNIX commerciaux (qui co^utent une petite fortune), fournis avec un
:
shell script setuid-root, qui permettait a tous les utilisateurs d'obtenir en une fraction de seconde
tous les privileges root par un simple tour d'adresse.
13 En 1988, le ver RTM provoqua l'arr^et presque complet de la plus grande partie de l'Internet,
:
en exploitant une grosse breche dans quelques versions du programme sendmail. Ce trou de securite
a ete corrige depuis.
1.5. Maintenance du systeme 17

un programme setuid, redoublez de prudence et assurez-vous de ne rien rater de sa


documentation, a n d'eviter de creer une breche de securite par erreur ou omission.
Malgre tout le soin que vous pourrez apporter a la securite, vous ne pourrez jamais
vous considerer comme totalement a l'abri. Par consequent, vous devez pouvoir de-
tecter les eventuels intrus le plus t^ot possible. La lecture des chiers de trace du
systeme est un bon point de depart, mais les pirates le sachant aussi bien que vous,
ils ne manqueront pas d'e acer tout ce qui pourrait les denoncer. Il existe neanmoins
des outils comme tripwire 14 , qui calcule regulierement di erents checksums sur ces
chiers, et les stocke dans une base de donnees. Lors des acces ulterieurs, ces valeurs
sont recalculees et comparees avec celles precedemment trouvees a n de detecter toute
modi cation anormale de ces traces.

14 E crit par Gene Kim et Gene Spa ord.


:
18 Chapitre 1. Introduction aux reseaux
19

Chapitre 2
Le reseau TCP/IP
Nous allons maintenant aborder tous les details que vous devrez conna^tre lors de la
connexion de votre systeme Linux a un reseau TCP/IP, notamment la gestion des
adresses IP, les noms de machines, et le routage. Ce chapitre vous apportera les bases
necessaires pour la comprehension de ce que necessite une con guration reseau, les
suivants decriront les di erents outils a employer.

2.1 Interfaces reseau


A n de s'a ranchir des nombreuses di erences entre les equipements divers utili-
ses dans un environnement reseau, TCP/IP de nit une interface abstraite, a travers
laquelle on accede a la partie materielle. Cette interface permet un ensemble d'ope-
rations, communes a tout type d'equipement reseau, et gere l'envoi et la reception de
paquets.
Pour chaque peripherique a connecter au reseau, il faut une interface correspondante
dans le noyau du systeme. Par exemple, les cartes Ethernet sous Linux s'appellent
eth0 et eth1, les interfaces SLIP sont sl0, sl1, etc. Ces noms sont utilises lors de
la con guration, pour indiquer au noyau a quel peripherique physique vous desirez
acceder. Ils n'ont pas d'autre signi cation.
A n d'^etre utilisable sur un reseau TCP/IP, une interface doit se voir attribuer une
adresse IP, qui permet de l'identi er lors de communications avec le reste du monde.
Cette adresse est di erente du nom cite ci-dessus ; si vous comparez une interface a
une porte, l'adresse est comme la plaque clouee dessus, portant le numero.
Bien entendu, d'autres parametres peuvent ^etre ajustes. L'un d'entre eux est la taille
maximale des datagrammes que cette interface particuliere peut gerer, que l'on appelle
Maximum Transfer Unit, ou MTU. Nous en verrons bien d'autres plus tard.
20 Chapitre 2. Le reseau TCP/IP
2.2 Adresses IP
Comme nous l'avons vu dans le chapitre precedent, les adresses comprises par le
protocole reseau IP sont des nombres de 32 bits. Chaque machine se voit assigne un
nombre unique dans l'environnement : si vous concevez un reseau local qui ne partage
pas de tra c TCP/IP avec d'autres reseaux, vous pouvez choisir ces nombres selon
vos propres criteres. Toutefois, pour les sites connectes a l'Internet, ces adresses sont
fournies par une autorite centrale, le Network Information Center, ou NIC 1 .
Pour en faciliter la lecture, les adresses IP sont partagees en quatre nombres de 8 bits
appeles octets 2 . Par exemple, l'adresse 0x954C0C04, qui est en hexadecimal celle
du site quark.physique.groucho.edu, s'ecrira 149.76.12.4. Ce format est souvent
appele notation sur 4 octets ou notation pointee (dotted quad notation en anglais).
Cette notation est aussi due au fait que les adresses IP sont composees d'une valeur
reseau, contenue dans les premiers octets, et une valeur h^ote, dans ceux qui restent.
Lorsque vous demandez une adresse ocielle au NIC, vous n'obtenez pas de valeurs
individuelles pour chaque machine que vous comptez connecter : le NIC vous accorde
une adresse de reseau, et c'est a vous d'assigner toutes les adresses IP individuelles
valides qu'elle permet, selon vos preferences.
En fonction de la taille du reseau, la partie h^ote peut ^etre plus ou moins grande.
Pour faire face aux di erents besoins, il existe plusieurs classes de reseau, de nissant
di erentes manieres de decouper les adresses IP.
Classe A La classe A comprend les reseaux 1.0.0.0 a 127.0.0.0. La valeur
reseau est contenue dans le premier octet. Cela donne une partie
h^ote de 24 bits, permettant environ 1,6 million de machines.
Classe B La classe B comprend les reseaux 128.0.0.0 a 191.255.0.0 ; la valeur
reseau est contenue dans les deux premiers octets. Elle permet donc
16 320 reseaux de 65 024 h^otes chacuns.
Classe C La classe C comprend les reseaux 192.0.0.0 a 223.255.255.0, la va-
leur reseau etant contenue dans les trois premiers octets. Elle permet
pres de 2 millions de reseaux de 254 h^otes.
Classes D, E, et F
Les adresses comprises entre 224.0.0.0 et 254.0.0.0 sont soit expe-
rimentales, soit reservees pour un usage futur et ne speci ent aucun
reseau.
1 Tres souvent, les adresses IP vous seront assignees par le fournisseur de services aupres du-
:
quel vous achetez votre connectivite. Mais vous pouvez egalement traiter directement aupres du
NIC a n d'obtenir une adresse pour votre reseau, en envoyant un courrier electronique a l'adresse
hostmaster@internic.net.
2 Il faut noter ici que la langue anglaise fait la di erence entre un nombre quelconque sur 8 bits,
:
appele byte, de son utilisation dans la notation d'adresses IP, ou il prend l'appellation octet. En
francais, nous ne disposons que du terme octet pour les deux cas.
2.3. Resolution des adresses 21

Si nous reprenons l'exemple du chapitre precedent, nous pouvons maintenant voir


que 149.76.12.4, l'adresse de quark, designe l'h^ote 12.4 du reseau de classe B
149.76.0.0.
Vous aurez peut-^etre remarque dans la liste ci-dessus que toutes les valeurs possibles
pour la partie h^ote ne sont pas autorisees. En e et, les valeurs 0 et 255 sont reservees
a des usages speciaux : une adresse dont tous les bits de la partie h^ote sont a zero
designe le reseau en lui-m^eme, et si les bits sont tous a 1 il s'agit alors de l'adresse de
di usion (broadcast). Celle-ci designe simultanement toutes les machines connectees
au reseau en question. Par consequent, 149.76.255.255 n'est pas une adresse d'h^ote
valide, mais reference tous ceux du reseau 149.76.0.0.
Il y a egalement deux autres adresses reservees, 0.0.0.0 et 127.0.0.0. La premiere
s'appelle la route par defaut et la seconde, l'adresse loopback. La route par defaut est
en rapport avec la facon dont sont diriges les datagrammes, ce que nous verrons dans
la section suivante.
Le reseau 127.0.0.0 est reserve au tra c IP local a votre ordinateur. En general,
l'adresse 127.0.0.1 sera assignee a une interface speciale de votre systeme, appelee
interface loopback, qui se comporte comme un circuit ferme. Chaque paquet TCP ou
UDP qui lui est transmis, est immediatement retourne comme s'il arrivait d'un autre
reseau. Ainsi, il est possible de developper et tester des programmes sans disposer d'un
(( vrai )) r
eseau; cette interface trouve toutefois sa principale utilite lors de l'emploi
de logiciels utilisant le reseau sur la m^eme machine, ou sur un ordinateur totalement
isole. Cette situation n'est pas si rare qu'il y para^t : par exemple, beaucoup de sites
UUCP ne disposent d'aucune connectivite IP, mais ont besoin de faire fonctionner le
serveur de News INN. Celui-ci utilisera alors l'interface loopback.

2.3 Resolution des adresses


Maintenant que vous savez comment sont constituees les adresses IP, vous devez
sans doute vous demander comment elles sont utilisees pour acceder aux di erentes
machines. Apres tout, le protocole Ethernet identi e les h^otes par un nombre de six
octets qui n'a absolument rien en commun avec une adresse IP, n'est-ce pas ?
C'est exact. Et c'est pourquoi il faut un mecanisme sachant mettre en correspondance
les adresses IP et Ethernet : ce protocole se nomme Address Resolution Protocol, ou
ARP. En fait, ARP n'est pas limite a l'Ethernet, mais est egalement employe sur
d'autres types de reseaux, comme par exemple le packet-radio des radio-amateurs.
Pour fonctionner, ARP utilise exactement la methode qu'emploient la plupart des
gens pour trouver M. Marcel Dugenou dans une foule de 150 inconnus : se promener
en criant son nom, en esperant qu'il repondra s'il est la.
Lorsque ARP veut trouver l'adresse Ethernet correspondant a une adresse IP donnee,
il fait appel a une possibilite appelee la (( di usion )) (broadcasting), qui consiste a
envoyer un datagramme simultanement a toutes les stations presentes sur le reseau. Ce
22 Chapitre 2. Le reseau TCP/IP
paquet expedie par ARP contient une requ^ete pour l'adresse IP en question. Chaque
h^ote le recevant compare alors cette adresse a la sienne, et si elles correspondent,
retourne une reponse ARP a la machine appelante. Celle-ci peut alors en extraire
l'adresse Ethernet de l'expediteur.
Vous pouvez vous demander comment un h^ote peut atteindre une adresse Internet
pouvant se trouver sur un reseau Ethernet di erent, quelque part dans le monde,
ou comment, en tout premier lieu, il peut savoir que cette adresse est sur un reseau
Ethernet. Toutes ces questions mettent en jeu ce que l'on appelle le routage, qui
consiste a localiser physiquement un h^ote dans un reseau. Ce sera le sujet de la
section suivante.
Voyons ARP plus en detail. Une fois qu'un h^ote a decouvert une adresse Ethernet, il
la stocke dans son cache ARP a n de ne pas avoir a la redemander la prochaine fois
qu'il devra envoyer un datagramme a la machine en question. Toutefois, il ne serait
pas judicieux de conserver cette information inde niment ; la machine distante peut
changer de con guration (changement de carte Ethernet pour des raisons techniques
par exemple) et l'entree ARP ne serait plus valide. Par consequent, les entrees conte-
nues dans le cache ARP sont supprimees au bout d'un certain temps a n de forcer
une nouvelle requ^ete.
Il est aussi quelquefois necessaire de trouver l'adresse IP associee a une adresse Ether-
net donnee. Cela se produit lorsqu'une machine diskless veut s'amorcer depuis un
serveur du reseau, ce qui est une situation tres courante sur les reseaux locaux. Ce
type de station ne possede pratiquement aucune information sur elle-m^eme, a l'ex-
ception de son adresse Ethernet : par consequent, elle di use un message demandant
aux serveurs de lui indiquer son adresse IP. Il existe un autre protocole pour cela,
appele Reverse Address Resolution Protocol, ou RARP. Avec le protocole BOOTP, il
permet de de nir une procedure d'amorcage de clients diskless via reseau.

2.4 Routage IP
Nous allons maintenant voir comment localiser un h^ote a qui nous voulons envoyer des
paquets, en fonction de son adresse IP. Les di erentes parties de l'adresse sont gerees
di eremment ; et c'est a vous de con gurer correctement les chiers qui indiquent
comment traiter chacune de ces parties.

2.4.1 Reseaux IP
} Lorsque vous ecrivez une lettre a quelqu'un, vous indiquez generalement sur l'enve-
loppe une adresse complete speci ant le pays, le departement, le code postal, etc.
Ensuite, vous mettez l'enveloppe dans une bo^te aux lettres et les services postaux la
delivreront au destinataire : elle sera expediee dans le pays indique, ou d'autres ser-
vices nationaux la dirigeront vers le departement indique, et ainsi de suite jusqu'au
2.4. Routage IP 23

destinataire. L'avantage de cette methode hierarchique est evident : quelle que soit la
destination, la poste locale saura dans quelle direction diriger la lettre, mais n'aura
pas a se soucier de savoir comment elle voyagera une fois qu'elle aura atteint le pays
de destination.
Les reseaux IP sont structures de facon similaire. L'Internet consiste en un certain
nombre de reseaux particuliers, appeles systemes autonomes. Chaque systeme e ectue
tout le routage necessaire entre ses h^otes internes de telle maniere que l'envoi d'un
datagramme se reduise a trouver un chemin vers le reseau sur lequel se trouve l'h^ote
destinataire. Cela signi e qu'aussit^ot que le paquet est passe a n'importe quel h^ote
de ce reseau particulier, le reste du traitement est exclusivement realise par ce reseau
lui-m^eme.

2.4.2 Sous-reseaux
Cette structure est re etee par le decoupage des adresses IP en une partie reseau
et une partie h^ote, comme nous l'avons explique plus haut. Par defaut, le reseau de
destination est derive de la partie reseau de l'adresse IP. Par consequent, les h^otes
pour lesquels ce nombre est le m^eme doivent se trouver sur le m^eme reseau, et reci-
proquement 3 .
Il est alors logique d'o rir un schema similaire a l'interieur du reseau, puisqu'il peut
lui-m^eme consister en un ensemble de centaines de reseaux plus petits, la plus petite
unite etant des reseaux physiques comme l'Ethernet. Par consequent, IP permet de
subdiviser un reseau IP en plusieurs sous-reseaux.
Un sous-reseau prend la responsabilite de delivrer les datagrammes pour une certaine
plage d'adresses IP appartenant au reseau IP dont il fait partie. Tout comme dans les
classes A, B, ou C, il est identi e par la partie reseau des adresses IP. Toutefois, cette
partie reseau est alors etendue en incluant quelques bits de la partie h^ote. Le nombre
de bits qui seront interpretes en tant que valeur de sous-reseau est donne par ce que
l'on appelle le masque de sous-reseau ou masque reseau, en anglais netmask. Il s'agit
aussi d'un nombre sur 32 bits, qui speci e le masque de bits pour la partie reseau de
l'adresse IP.
Le reseau du campus de l'universite Groucho Marx est un exemple d'une telle orga-
nisation. Il possede le reseau de classe B 149.76.0.0, et son masque reseau est par
consequent 255.255.0.0.
A l'interieur, il est en fait constitue de plusieurs reseaux plus petits, comme ceux des
di erents departements. Aussi, la plage d'adresses IP est divisee en 254 sous-reseaux,
149.76.1.0 a 149.76.254.0. Par exemple, le Departement de Physique Theorique
s'est vu assigner 149.76.12.0. La dorsale du campus est aussi un reseau, auquel on
a attribue l'adresse 149.76.1.0. Ces sous-reseaux partagent la m^eme valeur reseau,
bien que le troisieme octet soit utilise pour les distinguer entre eux. Ils utiliseront un
masque de sous-reseau de 255.255.255.0.
3 Les systemes autonomes sont plus generaux et peuvent comporter plus d'un reseau IP.
:
24 Chapitre 2. Le reseau TCP/IP

Partie reseau Partie h^ote


149 76 12 4

149 76 12 4

Partie reseau Partie h^ote

Fig. 2.1 - Subdivision d'un reseau de classe B

La gure 2.1 montre comment 149.76.12.4, l'adresse de quark, est interpretee dif-
feremment selon qu'elle est consideree sur un reseau de classe B ordinaire, ou comme
sous-reseau.
Il faut bien avoir a l'esprit que la subdivision de reseaux n'est qu'une division interne.
Les sous-reseaux sont crees par le proprietaire du reseau (ou les administrateurs). Sou-
vent, ils sont mis en place pour delimiter des zones precises, qu'elles soient physiques
(entre deux Ethernet), administratives (entre deux departements), ou geographiques;
et une personne se voit deleguer la responsabilite de ces sous-reseaux. Mais cette
structure n'a ecte que le comportement interne et est completement invisible pour le
reste du monde.

2.4.3 Passerelles
La subdivision de reseaux n'est pas seulement utile pour des raisons administratives,
mais est aussi tres souvent la consequence naturelle des limitations materielles. Le
point de vue d'un h^ote connecte a un reseau physique donne (Ethernet par exemple),
est tres limite : il ne pourra acceder directement qu'aux machines situees sur le m^eme
reseau local. Tous les autres h^otes ne lui sont accessibles qu'a travers ce que l'on
appelle une passerelle. Une passerelle est un h^ote qui est connecte physiquement a deux
reseaux (ou plus) simultanement, et qui est con gure specialement pour permettre
d'echanger des paquets entre eux.
Pour que IP puisse facilement savoir si un h^ote est sur un reseau local physique, ces
di erents reseaux physiques doivent appartenir a di erents reseaux IP. Par exemple,
le reseau IP 149.76.4.0 est reserve aux h^otes du reseau local du Departement de
Mathematiques. Lors de l'envoi d'un datagramme vers quark, les logiciels reseau de
erdos deduisent immediatement de l'adresse IP 149.76.12.4 que l'h^ote destinataire
est situe sur un reseau physique di erent, et par consequent ne sera joignable que par
une passerelle (sophus par defaut).
2.4. Routage IP 25

Cette machine passerelle, sophus, est connectee a deux sous-reseaux distincts : celui
du Departement de Mathematiques et la dorsale du campus. Il accede a chacun d'eux
par une interface di erente, qui sont respectivement eth0 et fddi0. Mais alors, quelle
adresse IP devons-nous lui assigner ? Faut-il lui en donner une appartenant au sous-
reseau 149.76.1.0, ou bien a 149.76.4.0 ?
La reponse est : les deux, mon general. Lors de dialogues avec des h^otes du Depar-
tement de Mathematiques, sophus devra utiliser une adresse IP de 149.76.4.1, et
avec la dorsale, ce sera 149.76.1.4.
Donc, une passerelle se voit assigner une adresse IP par reseau auquel elle est connec-
tee. Ces adresses (et les masques correspondants) sont liees aux interfaces par les-
quelles on accede aux sous-reseaux. La correspondance entre les interfaces et adresses
de sophus ressemblera donc a ceci :
Interface Adresse Masque reseau
eth0 149.76.4.1 255.255.255.0
fddi0 149.76.1.4 255.255.255.0
lo 127.0.0.1 255.0.0.0
La derniere entree correspond a l'interface loopback, que nous avons decrit plus haut.
La gure 2.2 montre une partie de la topologie du reseau a l'universite Groucho Marx
(GMU). Les machines connectees simultanement a deux sous-reseaux sont indiquees
avec leurs deux adresses IP.
La plupart du temps, vous pouvez ignorer la di erence entre l'adresse IP d'un h^ote
et son interface. Pour ceux qui ne sont que sur un seul reseau, comme erdos, vous
pourrez dire que cette machine a telle ou telle adresse IP, bien qu'en realite ce soit son
interface Ethernet qui ait cette adresse. Mais la distinction n'est vraiment importante
que pour les passerelles.

2.4.4 La table de routage


Nous allons maintenant concentrer notre attention sur la maniere dont IP choisit une
passerelle pour delivrer des donnees a un reseau distant.
Nous venons de voir que erdos, lorsqu'il a un datagramme pour quark, teste l'adresse
de destination et s'apercoit qu'elle n'est pas sur le reseau local. Par consequent, il
envoie le paquet a la passerelle par defaut sophus, qui est alors confrontee au m^eme
probleme. Sophus voit que quark ne fait partie d'aucun des reseaux sur lesquels elle
est directement connectee, et qu'il lui faut trouver une autre passerelle a qui passer le
ambeau. Le bon choix serait niels, celle reliant le Departement de Physique : sophus
a donc besoin d'informations lui permettant d'associer un reseau destinataire a une
passerelle adequate.
Les informations de routage qu'IP utilise pour cela consistent en une table indiquant
les reseaux et les passerelles necessaires pour les atteindre. De plus, une route par
26 Chapitre 2. Le reseau TCP/IP

Departement Mathematiques Departement Physique Theorique

4.23 4.17 12.4


4.0 12.0
gauss erdos quark

4.1 12.1
sophus niels
1.4 1.12
Dorsale du campus 1.1 gcc1
2.1

1.0

Centre de calcul de Groucho

Fig. 2.2 - Une partie de la topologie du reseau a l'universite Groucho Marx.


2.4. Routage IP 27

defaut doit generalement ^etre indiquee ; il s'agit d'une entree associant une passerelle
au reseau 0.0.0.0. Tous les paquets destines a un reseau inconnu seront expedies par
ce chemin. Sur sophus, cette table pourrait ressembler a celle-ci :
Reseau Passerelle Interface
149.76.1.0 - fddi0
149.76.2.0 149.76.1.2 fddi0
149.76.3.0 149.76.1.3 fddi0
149.76.4.0 - eth0
149.76.5.0 149.76.1.5 fddi0
::: ::: :::

0.0.0.0 149.76.1.2 fddi0


Les routes vers les reseaux sur lesquels sophus est directement connectee n'ont pas
besoin de passerelle, c'est pourquoi ici la colonne correspondante contient un tiret.
Les tables de routage peuvent ^etre construites par di erents moyens. Dans le cas de
petits reseaux, la meilleure methode est de le faire manuellement et de les positionner
par la commande route lors de l'amorcage des systemes (voir le chapitre 5). Sur les
grands reseaux, elles sont ajustees en cours de fonctionnement par des programmes
qui s'echangent des informations de routage pour determiner les meilleures routes.
En fonction de la taille du reseau, di erents protocoles de routage seront alors utilises.
A l'interieur de systemes autonomes (comme le campus Groucho Marx), les protocoles
de routage interne sont employes. Le plus courant, RIP (Routing Information Proto-
col) est implemente par le demon BSD routed. Entre les systemes autonomes, il faut
faire appel aux protocoles de routage externe comme EGP (External Gateway Protocol)
ou BGP (Border Gateway Protocol) ; ceux-ci (aussi bien que RIP) sont implementes
dans le demon gated de l'universite de Cornell 4.

2.4.5 Valeurs metriques


Le routage dynamique base sur RIP choisit le meilleur chemin vers un h^ote ou un
reseau en fonction du nombre de (( sauts )) (hops), c'est-a-dire le nombre de passerelles
traversees pour amener un datagramme a destination. Plus ce chemin est court, mieux
il est note par RIP. Lorsqu'il est trop long, 16 sauts ou plus, il est considere comme
inutilisable et elimine.
Pour utiliser RIP a n de gerer les informations de routage internes a votre reseau local,
il faut que le programme gated soit en service sur chaque h^ote. Au demarrage, gated
teste toutes les interfaces reseau actives. S'il en trouve plus d'une (loopback exclue), il
considere que cette machine sert de passerelle entre di erents reseaux et devient alors
actif, echangeant et di usant des informations de routage. Sinon, il restera passif,
4: Le programme routed est considere comme bogue par beaucoup d'administrateurs. Puisque
gated supporte egalement RIP, il est toujours preferable d'utiliser ce dernier.
28 Chapitre 2. Le reseau TCP/IP
attendant la reception de mises a jour RIP pour modi er la table de routage locale
de maniere appropriee.
Lors de la di usion des informations sur la table locale, gated determine la longueur
du chemin a partir de la valeur metrique associee avec chaque entree. Cette valeur
est initialisee par l'administrateur systeme lors de l'etablissement de la route et doit
re eter le prix de revient de ce chemin particulier. Par consequent, la valeur metrique
d'une route vers un sous-reseau dont l'h^ote est directement connecte doit toujours
valoir zero, alors qu'une route passant par deux passerelles aura la valeur deux. Notez
que vous n'avez toutefois pas a vous soucier de cette valeur metrique si vous n'utilisez
jamais le protocole RIP ou le programme gated.

2.5 Le protocole ICMP


IP vient avec un protocole dont nous n'avons pas encore parle : le protocole de contr^ole
de messages, Internet Control Message Protocol. ICMP est utilise par les couches
reseau du noyau pour communiquer des messages d'erreurs aux autres h^otes. Par
exemple, supposons que vous ^etes une nouvelle fois sur erdos et desirez lancer un
telnet sur le port 12345 de quark, mais qu'a l'autre bout il n'y ait aucun processus
a l'ecoute de ce port. Lorsque le premier paquet TCP arrivera sur quark, la couche
reseau se rendra immediatement compte de cet etat de fait et renverra un message
ICMP a erdos disant (( Port Unreachable )), soit (( Port inaccessible )).
ICMP sait traiter un certain nombre de messages, dont beaucoup sont des conditions
d'erreur. Malgre tout, l'un d'eux est particulierement interessant: le message de redi-
rection. Il est genere par le module de routage lors qu'il detecte qu'un autre h^ote est
en train d'utiliser la machine comme passerelle, alors qu'il existe une route bien plus
courte. Par exemple, apres le demarrage de sophus, sa table de routage peut ^etre
incomplete. Elle pourrait contenir des routes vers le Departement de Mathematiques,
la dorsale FDDI, et la route par defaut pointerait sur la passerelle du centre de calcul
(gcc1). Par consequent, tout paquet a destination de quark serait envoye a gcc1
plut^ot qu'a niels, la passerelle vers le reseau du Departement de Physique. En rece-
vant un tel datagramme, gcc1 se rendra compte qu'il s'agit d'un tres mauvais choix
de routage et le renverra a niels, tout en retournant un message ICMP de redirection
a sophus, lui indiquant cette route, bien meilleure.
Cela peut sembler une methode tres habile pour se contenter de ne positionner ma-
nuellement que le strict minimum de routes, et laisser les systemes faire le reste.
Neanmoins, nous devons vous avertir que compter sur le routage dynamique, que
ce soit par RIP ou les redirections ICMP, n'est pas toujours une bonne idee : ces
protocoles ne vous o rent que tres peu, voire aucune possibilite de veri cation de
l'authenticite des informations de routage. Des utilisateurs malintentionnes peuvent
arriver a rendre votre reseau totalement hors service, ou pis encore. Pour cette rai-
son, certaines versions du code reseau de Linux traitent les messages de redirection
a ectant des routes reseaux comme s'il ne s'agissait que des routes d'h^otes.
2.6. DNS : Le Domain Name System 29

2.6 DNS : Le Domain Name System


Nous abordons une partie ou vous allez rencontrer beaucoup de termes techniques
americains : en l'absence d'equivalents francais reconnus et acceptes, nous avons pre-
fere conserver les expressions originales connues du monde entier plut^ot que d'inventer
des noms b^atards du plus mauvais e et.

2.6.1 Resolution de noms


} Comme nous le savons maintenant, l'adressage sur un reseau TCP/IP est base sur
des nombres de 32 bits. Comme ils sont dicilement memorisables, les h^otes sont
generalement baptises de facon plus humaine, par de simples noms comme pluton,
zeus ou marcel. C'est alors au systeme de trouver les adresses IP correspondantes:
il s'agit de la resolution de noms.
Lorsqu'une application a besoin de trouver l'adresse IP d'un h^ote donne, il s'appuie sur
les fonctions gethostbyname(3) et gethostbyaddr(3). Traditionnellement, celles-ci sont
groupees avec quelques autres de la m^eme famille, dans une bibliotheque specialisee;
sous Linux l'ensemble est integre dans la bibliotheque standard libc. On fait en general
reference a ces fonctions en parlant du (( resolver )).
Sur un petit reseau, il n'est pas tres dicile de maintenir des tables de correspondances
entre les noms de machines et leurs adresses. Ces informations sont en principe conte-
nues dans un chier nomme /etc/hosts. Lors de l'ajout ou la suppression d'h^otes, ou
en cas de reassignation d'adresse, il sut de mettre a jour le chier hosts sur toutes les
machines. Il est evident que cette operation devient quasi impossible sur des reseaux
composes d'une tres grande quantite de systemes.
NIS, le Network Information System developpe par Sun Microsystems, est une solu-
tion a ce probleme (On l'appelle YP, Yellow Pages ou pages jaunes pour des raisons
historiques). NIS conserve le chier hosts, ainsi que certaines autres informations,
dans une base de donnees sur une machine ma^tre depuis laquelle des clients peu-
vent recuperer a tout moment ce dont ils ont besoin. Mais la encore, cette approche
n'est utilisable que sur des reseaux d'importance moyenne, comme les reseaux locaux,
car il faut stocker et maintenir la base de donnees hosts de maniere centralisee et la
distribuer a tous les serveurs.
Sur l'Internet, ces informations etaient aussi a l'origine stockees dans un unique -
chier, HOSTS.TXT. Il etait maintenu au Network Information Center, ou NIC, et
devait ^etre telecharge puis installe par tous les sites connectes. La croissance du re-
seau engendra plusieurs problemes. En plus du surcro^t de travail d^u a la necessite
d'installer HOSTS.TXT regulierement, la charge des serveurs le di usant devint vite
trop elevee. Pis encore, tous les noms devaient ^etre enregistres aupres du NIC, qui
devait s'assurer que tous soient bien uniques.
30 Chapitre 2. Le reseau TCP/IP
C'est pourquoi, en 1984, une nouvelle methode de resolution des noms fut adoptee,
le Domain Name System. Le DNS est l'uvre de Paul Mockapetris, et regle simulta-
nement les deux problemes que nous venons d'evoquer.

2.6.2 Introduction du DNS


DNS organise les noms d'h^otes en une hierarchie de domaines. Un domaine est un
ensemble de sites qui ont une certaine relation entre eux ; ils peuvent former un reseau
particulier (toutes les machines d'un campus par exemple), ou bien tous appartenir
a une organisation particuliere (comme le Gouvernement francais) ou encore, ^etre
tout simplement proche geographiquement parlant. Aux USA par exemple, toutes les
universites sont regroupees dans le domaine edu, chacune utilisant un sous-domaine
la de nissant mieux. L'universite Groucho Marx pourrait ainsi se trouver dans le
domaine groucho.edu, et son Departement de Mathematiques pourrait ^etre baptise
maths.groucho.edu. Les h^otes du departement verraient alors leur nom ajoute a
tout cela ; ainsi la machine erdos serait connue comme erdos.maths.groucho.edu.
C'est ce que l'on appelle le fully quali ed domain name, ou FQDN, qui identi e de
maniere unique cet h^ote aux yeux du monde entier.

com edu net

groucho

maths physique

gauss erdos sophus theorique particules

quark otto niels up down strange

Fig. 2.3 - Une partie de l'espace de nommage.

La gure 2.3 montre une partie de l'espace de nommage. Tout en haut de cette ar-
borescence, l'entree denotee par un simple point, correspond a la racine et est appele
root domain. Pour indiquer qu'un nom d'h^ote est FQDN (c'est-a-dire completement
2.6. DNS : Le Domain Name System 31

quali e, et non pas relatif a un domaine local implicite), on l'ecrit parfois en le ter-
minant par un point. Cela signi e que la derniere composante est le domaine racine
(root domain).
En fonction de sa position dans la hierarchie, un domaine peut ^etre appele de premier
niveau (top-level), second niveau ou troisieme niveau. Il peut y en avoir encore plus,
mais le cas est assez rare. Voici plusieurs domaines americains de premier niveau que
vous rencontrerez tres souvent :

edu Sites en rapport avec l'education (colleges, universites...).


com Entreprises commerciales.
org Organisations privees non commerciales. Beaucoup de reseaux UUCP
prives sont dans ce domaine.
net Passerelles et autres machines administratives d'un reseau.
mil Institutions militaires americaines.
gov Institutions gouvernementales americaines.
uucp Ociellement, tous les noms de sites depourvus de domaines utilises
en UUCP ont ete places dans ce domaine.
Techniquement, les quatre premiers appartiennent aux E tats-Unis, mais vous pourrez
quand m^eme rencontrer des sites d'autres pays dans ces domaines ; en particulier dans
net. En revanche, mil et gov sont exclusivement americains.
En dehors des USA, chaque etat utilise generalement un domaine de premier niveau
bien a lui, constitue d'apres les deux lettres de nissant le code pays ISO-3166. La Fin-
lande, par exemple, utilise le domaine ; la France fr, l'Allemagne de, et l'Australie
au. En dessous, chaque NIC est libre d'organiser les noms comme il l'entend. L'Austra-
lie, par exemple, utilise des domaines de second niveau identiques aux niveaux interna-
tionaux superieurs: com.au, edu.au, et ainsi de suite. D'autres, comme l'Allemagne,
n'utilisent pas cette methode et preferent avoir des noms de machines bien plus longs
representant directement les organismes gerant des domaines particuliers. Il n'est pas
rare de rencontrer des noms d'h^otes comme ftp.informatik.uni-erlangen.de. La
langue allemande fonctionne de m^eme, para^t-il...
Bien s^ur, ces domaines nationaux n'impliquent absolument pas que les machines resi-
dent physiquement dans les pays correspondants; ils signalent seulement qu'elles ont
ete enregistrees aupres du NIC de cet etat. Une entreprise suedoise peut avoir une
branche australienne, mais toutes ses adresses dans le domaine de premier niveau se.
Il appara^t donc maintenant que l'organisation de l'espace de nommage en une hie-
rarchie de domaines, resout elegamment le probleme d'unicite des noms : gr^ace au
DNS, un nom d'h^ote n'a besoin de rester unique qu'a l'interieur de son domaine pour
32 Chapitre 2. Le reseau TCP/IP
qu'il soit egalement unique au monde. De plus, les domaines quali es sont facilement
memorisables. Ces deux raisons susent deja pour vouloir separer un grand domaine
en plusieurs sous-domaines.
Mais DNS peut faire bien plus encore. Il permet de deleguer l'autorite sur un sous-
domaine a ses administrateurs. A l'universite Groucho Marx, les responsables peuvent
par exemple creer un sous-domaine par departement, nous avons deja rencontre ce cas
avec maths et physique. Lorsqu'ils trouveront le reseau du Departement de Physique
trop grand et trop complexe a administrer, et dicile a apprehender de l'exterieur,
ils pourront simplement passer le contr^ole du domaine physique.groucho.edu aux
administrateurs de ce sous-reseau. Ceux-ci seront alors libres de decider des noms
de machines voulus et de leur assigner des adresses IP de leur reseau comme ils
l'entendent, sans intervention exterieure.
En n, l'espace de nommage est separe en zones, chacune partant d'un domaine. No-
tez bien la di erence subtile entre une zone et un domaine : le domaine groucho.edu
comprend toutes les machines de l'universite Groucho Marx, alors que la zone grou-
cho.edu ne contient que celles gerees directement par le centre de calcul, celles du
Departement de Mathemathiques par exemple. Les h^otes du Departement de Physique
appartiennent a une zone di erente, physique.groucho.edu. Dans la gure 2.3, le
debut de chaque zone est repere par un petit cercle a droite du nom de domaine.

2.6.3 Recherche de noms avec le DNS


Au premier coup d'il, tout ce bazar de zones et domaines semble compliquer incon-
siderement la resolution de noms. Apres tout, s'il n'existe aucune autorite centrale
contr^olant quels noms sont assignes a quelle machine, comment diable une petite
application saura-t-elle se debrouiller ?
C'est la qu'intervient la partie la plus ingenieuse du DNS. Si vous voulez trouver
l'adresse IP de erdos, le DNS vous dira d'aller la demander a ceux qui la gerent, car
eux sauront vous l'indiquer.
En fait, le DNS est une base de donnees distribuee geante. Elle est implementee par
ce que l'on appelle des serveurs de noms, qui delivrent les informations relatives a un
domaine donne, ou un ensemble de domaines. Pour chaque zone, il y a au moins deux,
ou un petit nombre de serveurs de noms qui detiennent les informations sur les h^otes
de cette zone. Pour obtenir l'adresse IP de erdos, tout ce que vous avez a faire est
de contacter le serveur de noms pour la zone groucho.edu, qui vous retournera les
donnees desirees.
Facile a dire, devez-vous penser. Mais comment saurai-je contacter ce serveur de
noms de l'universite Groucho Marx ? Et bien au cas ou votre ordinateur ne serait
pas equipe d'une boule de cristal, le DNS saura aussi vous o rir ce service. Lorsque
votre application a besoin d'obtenir des informations sur erdos, elle contacte un
serveur de noms local, qui e ectue alors une requ^ete iterative. Il commence par envoyer
au serveur de noms du domaine du plus haut niveau, une demande d'adresse de
2.6. DNS : Le Domain Name System 33

erdos.maths.groucho.edu. Celui-ci reconna^t que ce nom n'appartient pas a sa zone


d'autorite, mais plut^ot a l'une situee en dessous du domaine edu. Par consequent, il
indique de contacter un serveur de noms de cette zone et joint a sa reponse la liste de
tous ces serveurs, avec leurs adresses. Votre serveur de noms local contactera alors l'un
d'entre eux, par exemple a.isi.edu. Celui-ci a son tour, indiquera que groucho.edu
possede sa propre zone et renverra les adresses des serveurs de noms concernes. Le
serveur de noms local presentera alors sa requ^ete pour l'adresse de erdos a l'un d'entre
eux, qui, nalement, reconna^tra que ce nom appartient a sa zone et pourra retourner
l'adresse IP correspondante.
Tout cela peut para^tre generer beaucoup de tra c pour trouver une simple adresse IP,
mais c'est en realite minuscule en comparaison de la quantite de donnees qu'il aurait
fallu transferer si nous en etions encore au chier HOSTS.TXT central. Toutefois,
cette methode est encore perfectible.
A n d'ameliorer le temps de reponse lors des requ^etes suivantes, le serveur de noms
stocke les informations obtenues dans son cache local. Ainsi, la prochaine fois que
quelqu'un, sur votre reseau local, desire trouver l'adresse d'une machine du domaine
groucho.edu, votre serveur de noms n'aura pas besoin de recommencer toute la
procedure, et ira directement se connecter au serveur de noms de groucho.edu 5 .
Bien s^ur, le serveur de noms ne conservera pas cette information inde niment, mais
elle sera supprimee au bout d'un certain temps. La duree de vie des informations
contenues dans le cache est appelee time to live, ou TTL. Elle est positionnee par les
administrateurs responsables de chaque zone.

2.6.4 Serveurs de noms


Les serveurs de noms qui contiennent toutes les informations relatives aux h^otes d'une
zone particuliere sont dits ayant autorite pour cette zone et sont quelquefois quali es
de serveurs de noms autoritatifs 6 . Toute requ^ete concernant une machine de cette
zone nira par aboutir sur l'un de ces serveurs possedant l'information absolue.
A n de pouvoir o rir une image coherente d'une zone, ses serveurs ma^tres doivent ^etre
parfaitement synchronises. Ceci est realise en faisant de l'un d'entre eux un serveur
primaire, qui charge les informations sur sa zone depuis des chiers de donnees, alors
que les autres deviennent serveurs secondaires, qui transferent leurs informations a
intervalles reguliers depuis le serveur primaire.
L'emploi de plusieurs serveurs de noms permet de distribuer la charge de travail, et
d'obtenir une certaine redondance des informations. Si l'un des serveurs a un probleme
quelconque, comme la perte de connexion reseau ou un arr^et momentane, toutes les
5 Si aucun cache n'etait utilise, le DNS serait aussi mediocre que n'importe quelle autre methode
:
puisque chaque requ^ete mettrait en jeu les serveurs de noms principaux.
6 Le mot (( autoritatif )) n'est pas francais. Il n'existe aucune traduction satisfaisante de l'expres-
:
sion (( Authoritative Name Server )), aussi avons-nous decide d'employer le terme utilise par tout le
monde dans le langage courant, m^eme s'il s'agit d'un barbarisme.
34 Chapitre 2. Le reseau TCP/IP
requ^etes aboutiront aux autres serveurs. Bien entendu, ce schema ne met pas a l'abri
de dysfonctionnements produisant des reponses erronees a toutes les requ^etes DNS,
comme des bogues dans le programme lui-m^eme par exemple.
Bien s^ur, vous pouvez aussi utiliser un serveur de noms qui n'a autorite sur aucun
domaine domaine 7 . Ce type de serveur peut neanmoins ^etre utile, car il est toujours
capable de gerer des requ^etes DNS pour les applications fonctionnant sur le reseau
local, ainsi qu'un cache des informations. On l'appelle par consequent serveur caching-
only (cache seulement).

2.6.5 La base de donnees DNS


Nous avons vu que le DNS ne gere pas que des adresses IP de machines, mais qu'il
echange egalement des informations sur les serveurs de noms. En fait, la base de
donnees DNS peut posseder une grande quantite d'entrees di erentes.
Chaque information elementaire de la base de donnees DNS est un objet appele (( re-
source record )), ou RR en abrege. Chaque enregistrement est associe a un type de-
crivant le genre de donnees qu'il represente, et une classe speci ant le type de reseau
auquel il s'applique. Cette derniere permet di erents schemas d'adressage, comme les
adresses IP (classe IN), adresses reseaux Hesiod (utilise au MIT), et quelques autres.
Le RR typique est de classe A, qui associe une adresse IP avec un domaine quali e.
Bien s^ur, une machine peut avoir plusieurs noms. Toutefois, un seul de ces noms
doit ^etre declare comme nom ociel, ou nom canonique, alors que les autres sont
simplement des alias s'y referant. La di erence est que le nom canonique est celui qui
est associe avec l'enregistrement A, les autres faisant l'objet d'un enregistrement de
type CNAME pointant sur ce nom canonique.
Nous n'allons pas decrire tous les types possibles ici | ce sera fait dans un pro-
chain chapitre | mais plut^ot vous donner un bref exemple. La gure 2.4 montre une
partie de la base de donnees qui est chargee dans les serveurs de noms de la zone
physique.groucho.edu.
En dehors des enregistrements A et CNAME, il y en a un d'un type particulier en
haut du chier, qui s'etend sur plusieurs lignes. C'est le resource record SOA, signalant
le debut d'autorite, Start Of Authority, qui contient l'information generale sur la zone
pour laquelle le serveur a autorite. Il comprend, entre autres, le temps par defaut
pendant lequel tous les enregistrements doivent ^etre conserves.
Notez que tous les noms dans ce chier d'exemple, qui ne se terminent pas par un
point, doivent ^etre interpretes comme relatifs au domaine groucho.edu. Le nom
special (( @ )) utilise dans le SOA correspond au nom du domaine lui-m^eme.
Nous avons vu plus haut que les serveurs de noms du domaine groucho.edu doivent
avoir connaissance de la zone physique de sorte qu'ils puissent pointer les requ^etes
7 En n, presque. Un serveur de noms doit au moins o rir un service pour localhost et une
:
recherche inverse sur 127.0.0.1.
2.6. DNS : Le Domain Name System 35

;
; Information ayant autorit
e pour physique.groucho.edu.
@ IN SOA niels.physique.groucho.edu. janet.niels.physique.groucho.edu. (
940902 ; numero de serie
360000 ; mise a jour
3600 ; tentative apres echec
3600000 ; delai d'expiration
3600 ; ttl par defaut (time to live)
)
;
; Serveurs de noms
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Physique th
eorique (sous-reseau 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Physique des particules (acc
el
erateur) (sous-r eseau 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...

Fig. 2.4 - Un extrait du chier named.hosts pour le Departement de Physique.


36 Chapitre 2. Le reseau TCP/IP
vers leurs serveurs de noms. Ceci est generalement realise par une paire d'enregistre-
ments : NS qui donne le nom quali e du serveur, et un enregistrement A qui associe
une adresse a ce nom. Puisque ces enregistrements sont ce qui relie le tout pour que
l'espace de nommage soit maintenu unique et coherent, ils sont souvent appeles glue
records (enregistrements-colle). Ce sont les seuls endroits ou une zone contient des
informations sur les h^otes de la zone inferieure. Les glue records pointant vers les
serveurs de noms de physique.groucho.edu sont montres dans la gure 2.5.
;
: Donn
ees pour la zone groucho.edu.
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. (
940701 ; numero de serie
360000 ; mise a jour
3600 ; tentative apr es 
echec
3600000 ; d
elai d'expiration
3600 ; ttl par defaut (time to live)
)
....
;
; Glue records pour la zone physique.groucho.edu
physique IN NS niels.physique.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physique IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
...

Fig. 2.5 - Un extrait du chier named.hosts de l'universite Groucho Marx.

2.6.6 Requ^etes inverses


Au lieu de rechercher une adresse IP appartenant a un h^ote, on peut parfois avoir
besoin de l'inverse, c'est-a-dire de trouver le nom canonique correspondant a une
adresse. C'est ce qu'on appelle la requ^ete inverse (reverse mapping) qui est utilisee par
di erents services reseau pour veri er l'identite d'un client. Lorsque l'on ne possede
qu'un simple chier hosts, la recherche inverse consiste simplement a trouver la ligne
ou gure la machine et prendre l'adresse IP qui s'y trouve. Avec le DNS, il est hors
de question d'e ectuer une recherche exhaustive dans tout l'espace de nommage,
bien entendu. Alors, un domaine special a ete cree, in-addr.arpa., contenant les
adresses de toutes les machines en notation inversee. Par exemple, une adresse IP de
149.76.12.4 correspond au nom 4.12.76.149.in-addr.arpa. Le RR type reliant ces
noms a leurs noms canoniques est PTR.
La creation d'une zone d'autorite signi e generalement que ses administrateurs ont
recu le contr^ole total de l'assignation des adresses. Puisqu'ils ont en principe un ou
plusieurs reseaux IP ou sous-reseaux a leur disposition, il y a une subdivision entre les
zones DNS et les reseaux IP. Le Departement de Physique, par exemple, comprend
les sous-reseaux 149.76.8.0, 149.76.12.0, et 149.76.14.0.
2.6. DNS : Le Domain Name System 37

En consequence, de nouvelles zones du domaine in-addr.arpa doivent ^etre creees


avec la zone physique et deleguees aux administrateurs reseau du departement :
8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, et 14.76.149.in-addr.arpa. Au-
trement, l'installation d'une nouvelle machine au laboratoire de physique des parti-
cules necessiterait qu'ils contactent leur domaine parent pour que la nouvelle adresse
soit integree dans leur chier de la zone in-addr.arpa.
La base de donnees de la zone pour le sous-reseau 12 est montree dans la gure 2.6. Les
glue records correspondants dans la base de leur zone parente sont illustres gure 2.7.

;
; Le domaine 12.76.149.in-addr.arpa.
@ IN SOA niels.physique.groucho.edu. janet.niels.physique.groucho.edu. (
940902 360000 3600 3600000 3600
)
2 IN PTR otto.physique.groucho.edu.
4 IN PTR quark.physique.groucho.edu.
5 IN PTR down.physique.groucho.edu.
6 IN PTR strange.physique.groucho.edu.

Fig. 2.6 - Un extrait du chier named.rev du sous-reseau 12.

;
; Le domaine 76.149.in-addr.arpa.
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. (
940701 360000 3600 3600000 3600
)
...
; sous-r
eseau 4: departement mathematiques.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; sous-r
eseau 12: departement de physique, zone separ
ee.
12 IN NS niels.physique.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physique.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
...

Fig. 2.7 - Un extrait du chier named.rev du reseau 149.76.

Une consequence importante du systeme in-addr.arpa est que les zones ne peuvent
^etre creees que comme sur-ensembles de reseaux IP, et encore pis, que ces masques re-
seaux doivent ^etre alignes sur des octets. Tous les sous-reseaux de l'universite Groucho
Marx ont un masque de 255.255.255.0, par consequent une zone in-addr.arpa peut
^etre creee pour chaque sous-reseau. Toutefois, si le masque etait 255.255.255.128,
la creation de zones pour le sous-reseau 149.76.12.128 serait impossible, car il n'y a
38 Chapitre 2. Le reseau TCP/IP
aucun moyen de dire au DNS que le domaine 12.76.149.in-addr.arpa a ete separe
en deux zones d'autorite, avec des h^otes repartis de 1 a 127, et 128 a 255.
39

Chapitre 3
Con guration de
l'equipement reseau
3.1 Peripheriques, pilotes, etc.
Jusqu'a maintenant, nous avons parle d'interfaces reseau et de TCP/IP en general,
mais nous n'avons pas vu ce qui se passe lorsque le (( code reseau )) du noyau accede
a la partie materielle. Pour cela, nous devons introduire le concept d'interfaces et de
pilotes de peripheriques.
Tout d'abord, il y a bien s^ur l'equipement lui-m^eme, par exemple la carte Ethernet :
C'est une plaque de resine Epoxy, peuplee de nombreux composants electroniques, et
inseree dans un des nombreux connecteurs d'extension de votre PC. Elle constitue ce
que l'on nomme generalement un peripherique.
Pour que vous puissiez utiliser cette carte Ethernet, le noyau de Linux doit contenir
des fonctions speciales connaissant la methode a employer pour acceder a ce periphe-
rique. Ce sont les fameux pilotes de peripheriques. Par exemple, Linux possede des
pilotes pour plusieurs marques de cartes Ethernet qui se ressemblent beaucoup. Ils
sont connus en tant que (( serie Becker )), du nom de leur auteur, Donald Becker. Un
exemple di erent, le pilote D-Link gere un adaptateur de poche D-Link qui se branche
sur le port parallele du PC.
Mais, lorsque nous disons qu'un pilote (( gere )) un peripherique, qu'entendons-nous par
la ? Revenons a la carte Ethernet que nous examinions tout a l'heure. Le pilote doit
^etre capable de communiquer par un moyen quelconque avec la logique presente sur
ce montage electronique : il doit pouvoir lui envoyer des commandes et des donnees,
et la carte doit delivrer toute donnee recue a ce pilote.
Dans les PC, cette communication se fait par l'intermediaire d'une zone de memoire
destinee aux entrees/sorties (E/S) qui donne acces aux registres de la carte. Toutes
40 Chapitre 3. Con guration de l'equipement reseau

Code reseau du noyau Linux

Interface
reseau eth0 eth2 eth1 eth3

Pilote de
peripherique Pilote SMC Pilote 3Com

Materiel

Fig. 3.1 - Les relations entre les interfaces, les pilotes et le materiel.
3.1. Peripheriques, pilotes, etc. 41

les commandes et les donnees que le noyau envoie doivent passer par ces registres. La
memoire d'E/S est generalement decrite en donnant son adresse de depart, ou adresse
de base. Les adresses de base typiques pour les cartes Ethernet sont 0x300 ou 0x360.
En principe, vous n'avez pas a vous occuper de ces problemes materiels, car le noyau
teste ces caracteristiques lors de l'amorcage pour tenter de detecter les peripheriques
installes. Il lit plusieurs adresses memoire et compare les donnees trouvees avec ce
qu'il devrait voir si certaines cartes Ethernet etaient presentes. Toutefois, il est pos-
sible qu'il n'arrive pas a detecter certain materiel ; c'est parfois le cas avec des cartes
Ethernet bon marche qui ne sont pas des clones parfaits des realisations standard
d'autres constructeurs. De plus, Linux n'essaiera de detecter que le premier periphe-
rique Ethernet. Si vous utilisez plusieurs cartes, il vous faudra l'indiquer explicitement
au noyau.
Vous pourrez aussi parfois ^etre oblige d'indiquer au noyau un autre parametre: la
ligne d'IRQ (interruptions materielles). Les peripheriques generent une interruption
pour indiquer au noyau qu'ils ont besoin qu'il s'occupe d'eux, par exemple lorsque
des donnees sont arrivees ou qu'un evenement special s'est produit. Dans un PC,
ces signaux electriques peuvent se produire sur l'une des 15 lignes d'interruption,
numerotees de 0 a 15. 1 Le numero du canal d'interruption assigne a un peripherique
est appele son IRQ, pour resumer.
Comme nous l'avons explique dans le chapitre 2, le noyau accede a un peripherique
par l'intermediaire d'une interface. Les interfaces sont des parties logicielles qui o rent
un ensemble de fonctions communes pour tout type de materiel, comme l'envoi ou la
reception de datagrammes.
On les identi e par des noms, de nis directement a l'interieur du noyau ; ce ne sont pas
des chiers decrivant un peripherique comme ceux presents dans le repertoire /dev.
Les noms courants pour les interfaces Ethernet sont eth0, eth1, etc. L'assignation des
interfaces aux peripheriques depend souvent de l'ordre dans lequel ils ont ete con gu-
res et detectes. Par exemple, la premiere carte Ethernet installee deviendra eth0, la
suivante eth1, et ainsi de suite. Les interfaces SLIP et PPP sont gerees di eremment
des autres, car elles sont dynamiques : chaque fois qu'une telle connexion est etablie,
le noyau assigne une nouvelle interface au port serie concerne.
Les relations entre le materiel, les pilotes de peripheriques et les interfaces sont illus-
trees dans la gure 3.1.
Lors de l'amorcage, le noyau ache quels sont les peripheriques qu'il a pu detecter
et le nom des interfaces qu'il leur a assigne. Voici un tout petit extrait de ce que l'on
peut voir a l'ecran lors du demarrage de Linux :
.
.
This processor honours the WP bit even when in supervisor mode. Good.

1 Les IRQ 2 et 9 sont les m^emes, car le PC possede deux processeurs d'interruption gerant 8
:
lignes chacun, montes en cascade. Le processeur secondaire est connecte a la ligne IRQ 2 du premier.
42 Chapitre 3. Con guration de l'equipement reseau
Floppy drive(s): fd0 is 1.44M
Swansea University Computer Society NET3.010
IP Protocols: ICMP, UDP, TCP
PPP: version 0.2.1 (4 channels) OPTIMIZE_FLAGS
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
SLIP: version 0.7.5 (4 channels)
CSLIP: code copyright 1989 Regents of the University of California
dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95
Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994

Nous voyons que le noyau a ete compile avec le support de TCP/IP et qu'il comprend
des pilotes pour SLIP, CSLIP et PPP. La troisieme ligne en partant de la n indique
qu'un adaptateur D-Link a ete detecte et installe en tant qu'interface dl0. Si vous
avez une carte Ethernet, le noyau achera une ligne commencant par eth0, suivie par
le type de carte detectee, par exemple :

eth0: 3c509 at 0x300 tag 1, BNC port, address 00 60 8c 53 d4 1d, IRQ 15.
3c509.c:1.03 10/8/94 becker@cesdis.gsfc.nasa.gov

Si vous avez installe une carte Ethernet et qu'aucun message de ce type n'appara^t,
c'est que le noyau est incapable de detecter la carte correctement. Nous verrons com-
ment remedier a cette situation un peu plus loin.

3.2 Con guration du noyau


La plupart des distributions binaires de Linux sont fournies avec une disquette d'amor-
cage qui convient a tous les equipements courants des PC. Cela signi e que le noyau
contient toutes sortes de pilotes precon gures dont vous n'aurez jamais besoin, mais
qui g^achent inutilement votre precieuse memoire. Par consequent, vous devrez gene-
ralement vous constituer votre propre version du noyau, ne contenant que ce dont
vous aurez reellement besoin.
Avec Linux, vous devrez vous habituer a recompiler le noyau. Cette operation est
decrite dans l'ouvrage Le Systeme Linux, de Matt Welsh (voir l'annexe (( Bibliogra-
phie ))). Ici, nous nous limiterons aux options de con gurations qui concernent le
reseau.
La commande make config commencera par vous demander de choisir certaines op-
tions de con guration generale, par exemple si vous possedez un coprocesseur ma-
thematique ou non. L'une de ces options concernera le reseau ; lorsque vous verrez
(( TCP/IP networking )), r epondez y a la question (sinon votre noyau sera incapable
de travailler en reseau).
3.2. Con guration du noyau 43

3.2.1 Options du noyau dans Linux 1.0 et au-dela


Apres cette partie, le programme de con guration vous proposera di erentes choses
commes les pilotes SCSI, etc. Suivra une liste de questions concernant le support du
reseau. Ces options sont en constante evolution au fur et a mesure du developpement
du noyau et de nouveaux pilotes, aussi ce que vous verrez s'acher chez vous pourra
di erer legerement de ce que vous lirez ici. Typiquement, la liste des options o ertes
par la plupart des noyaux Linux aux alentours des versions 1.0 et 1.1 ressemble a ceci :
*
* Network device support
*
Network device support? (CONFIG_ETHERCARDS) [y]

En depit de ce qui est ecrit entre parentheses, vous devez repondre y quel que soit
le type de peripherique reseau, Ethernet, SLIP, ou PPP. En repondant y, le support
Ethernet est valide automatiquement ; mais les autres types de pilotes reseau feront
l'objet de questions separees.
SLIP (serial line) support? (CONFIG_SLIP) [y]
SLIP compressed headers (SL_COMPRESSED) [y]
PPP (point-to-point) support (CONFIG_PPP) [y]
PLIP (parallel port) support (CONFIG_PLIP) [n]

Ces questions concernent les di erentes couches de protocoles supportees par Linux.
SLIP permet le transport de datagrammes IP sur les ports serie ; CSLIP en est une
amelioration, les en-t^etes TCP/IP sont compresses. Notez que cette option ne valide
pas automatiquent CSLIP, mais inclut les fonctions necessaires dans le noyau pour
pouvoir l'utiliser eventuellement.
PPP est un autre protocole utilise pour realiser une liaison reseau a travers des liaisons
serie. Il est bien plus souple que SLIP et n'est pas limite a IP ; il peut tranferer
n'importe quel type de paquet reseau. Si cette option n'appara^t pas chez vous, c'est
que vous possedez une version peu recente de Linux.
PLIP permet d'envoyer des datagrammes IP a travers un port imprimante parallele.
Peu performant, il est surtout utilise pour communiquer tant bien que mal avec des
PC fonctionnant sous MS-DOS, ou sur des machines portables depourvues de cartes
Ethernet.
Les questions suivantes concernent les cartes Ethernet de di erents constructeurs.
De jour en jour, de nouveaux pilotes appara^ssent et par consequent vous verrez de
plus en plus de questions ajoutees a cette section. Si vous desirez realiser un noyau
utilisable sur plusieurs machines equipees de cartes di erentes, vous pouvez valider
plusieurs pilotes.
NE2000/NE1000 support (CONFIG_NE2000) [y]
WD80*3 support (CONFIG_WD80x3) [n]
44 Chapitre 3. Con guration de l'equipement reseau
SMC Ultra support (CONFIG_ULTRA) [n]
3c501 support (CONFIG_EL1) [n]
3c503 support (CONFIG_EL2) [n]
3c509/3c579 support (CONFIG_EL3) [n]
HP PCLAN support (CONFIG_HPLAN) [n]
AT1500 and NE2100 (LANCE and PCnet-ISA) support (CONFIG_LANCE) [n]
AT1700 support (CONFIG_AT1700) [n]
DEPCA support (CONFIG_DEPCA) [n]
D-Link DE600 pocket adaptor support (CONFIG_DE600) [y]
AT-LAN-TEC/RealTek pocket adaptor support (CONFIG_ATP) [n]
*
* CD-ROM drivers
*
...

En n, dans la section consacree aux systemes de chiers, le script de con guration


vous demandera si vous voulez le support de NFS, le systeme de chiers par reseau.
Il vous permet de monter ou d'exporter des disques durs distants a travers le reseau,
ceux-ci apparaissant de maniere transparente comme s'ils etaient locaux, directement
connectes a la machine.
NFS filesystem support (CONFIG_NFS_FS) [y]

3.2.2 Options du noyau a partir de Linux 1.1.14


A partir de la version 1.1.14 de Linux, ou un support de IPX en alpha-test t son
apparition, la procedure de con guration a legerement change. La section concernant
les options generales demande maintenant si l'on desire le support reseau en general.
Elle est immediatement suivie par quelques questions concernant diverses options
possibles.
*
* Networking options
*
TCP/IP networking (CONFIG_INET) [y]

Pour pouvoir utiliser TCP/IP, vous devez repondre y a cette question. Si vous repon-
dez n, vous pourrez toutefois compiler le noyau avec le support IPX.
IP forwarding/gatewaying (CONFIG_IP_FORWARD) [n]

Vous devez valider cette option si votre systeme fonctionne en passerelle entre deux
reseaux Ethernet, ou encore entre un reseau et un lien SLIP/PPP. Bien qu'il n'y ait
aucun inconvenient majeur a laisser cette possibilite en service, vous pouvez preferer
ne pas la valider a n de con gurer votre machine en tant que rewall. Les Firewalls
sont des h^otes connectes a deux reseaux ou plus, mais qui ne routent aucun tra c
entre eux. Ils sont couramment employes pour o rir des acces Internet a moindres
3.2. Con guration du noyau 45

risques pour le reseau local interne. Les utilisateurs sont autorises a se connecter sur
le rewall et acceder ainsi a l'Internet, mais les machines locales sont protegees de
toute attaque exterieure puisqu'aucune connexion ne pourra traverser ce rewall.
*
* (it is safe to leave these untouched)
*
PC/TCP compatibility mode (CONFIG_INET_PCTCP) [n]

Cette option permet d'eviter de declencher un bogue dans certaines versions de


PC/TCP, une implementation commerciale de TCP/IP pour le systeme MS-DOS.
Si vous la validez, vous pourrez toujours communiquer avec le reste du monde, mais
les performances peuvent devenir mediocres sur les liaisons a faible vitesse.
Reverse ARP (CONFIG_INET_RARP) [n]

Ici, il s'agit de valider ou non le protocole RARP (Reverse Address Resolution Pro-
tocol). Il sert aux stations diskless et aux terminaux X, qui ont besoin d'obtenir leur
adresse IP au demarrage. Vous ne devez valider RARP que si vous compter utiliser
de tels clients.
Assume subnets are local (CONFIG_INET_SNARL) [y]

Lorsqu'il envoie des donnees par TCP, le noyau doit les tronconner en plusieurs pa-
quets avant de les passer a la couche IP. Pour les h^otes pouvant ^etre atteints par un
reseau local comme l'Ethernet, il creera des paquets plus grands que pour ceux qui
vont parcourir une longue distance 2 . Si vous ne validez pas SNARL ((( SubNets ARe
Local )), les sous-reseaux sont locaux), le noyau considerera qu'un reseau n'est local
que s'il y a une interface y etant directement rattachee. Toutefois, si vous regardez le
reseau de classe B de l'universite Groucho Marx, la totalite de cette classe B est locale,
mais la plupart des h^otes sont interfaces avec seulement un ou deux sous-reseaux. Si
vous validez SNARL, le noyau pourra considerer que tous les sous-reseaux sont locaux
et utiliser de grands paquets avec toutes les machines du campus.
Si vous avez besoin de paquets de plus petite taille en direction de certains h^otes (parce
que les donnees passent par exemple par une liaison modem SLIP), vous pourrez le
faire gr^ace a l'option mtu de la commande route, qui est brievement decrite a la n
de ce chapitre.
Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n]

L'algorithme de Nagle permet d'eviter d'envoyer des paquets IP particulierement


petits, appeles tinygrams. Ils sont souvent crees par les outils interactifs qui ont a
2 Cette methode permet d'eviter la fragmentation par des liens qui ont une taille de paquet
:
maximale tres reduite.
46 Chapitre 3. Con guration de l'equipement reseau
transmettre par le reseau tres peu de donnees a la fois, comme telnet ou rsh. Sur des
liaisons lentes, comme celles realisees par modem, ils constituent une perte de debit
importante. Cet algorithme tente d'eviter ce phenomene en retenant la transmission
de donnees TCP quelques instants, en certaines circonstances. Vous n'aurez besoin de
supprimer cette fonction que si vous avez de serieux et frequents problemes de perte
de datagrammes.
The IPX protocol (CONFIG_IPX) [n]

Cette option valide le support de IPX, le protocole de transport utilise par les reseaux
Novell. Il est toujours en developpement, et n'est pas tres utilisable pour l'instant.
Le developpement est bloque en raison du manque d'information disponible sur les
di erentes couches de ce protocole, qui n'est pas du domaine public : les speci cations
sont vendues a un prix inadmissible, et selon une clause de non-divulgation. Si la
situation se debloque, il sera peut-^etre possible dans l'avenir d'echanger des donnees
avec des utilitaires MS-DOS utilisant IPX et de router du tra c entre des reseaux
Novell a travers une liaison PPP.
A partir de la version 1.1.16, Linux o re un nouveau type de pilote, le pilote dummy ;
que l'on peut traduire par (( bidon )), vous allez voir pourquoi. La question suivante
appara^t vers le debut de la section concernant les pilotes reseau :
Dummy net driver support (CONFIG_DUMMY) [y]

Ce pilote ne fait pas grand-chose, mais il est tres utile sur des machines isolees ou
reliees uniquement en SLIP ou PPP. C'est, en resume, une interface loopback sup-
plementaire, qui permet aux machines faisant du SLIP mais n'ayant aucune liaison
Ethernet, d'avoir une interface correspondant en permanence a votre adresse IP. Vous
trouverez des explications plus detaillees sur le sujet dans la section The Dummy
Interface du chapitre 5, a la page 74.

3.3 Tour d'horizon des pilotes reseau de Linux


Le noyau de Linux supporte un bon nombre de pilotes pour divers types de periphe-
riques reseau. Cette section propose un bref apercu des di erentes familles existantes,
et le nom des interfaces associees.
Vous trouverez ci-dessous la liste des noms standards attribues aux interfaces reseau
sous Linux. La plupart des pilotes supportent plus d'une interface, dans ce cas celles-ci
sont numerotees a partir de zero (comme eth0, eth1, ainsi de suite).
lo L'interface locale loopback. Utilisee a des ns de tests, ou par quelques
applications reseau. Elle fonctionne comme un circuit ferme dans le-
quel tout datagramme ecrit sera immediatement retourne a la couche
3.4. Installation Ethernet 47

reseau du systeme. Il y a toujours une interface loopback presente dans


le noyau, et il n'y a que peu d'inter^et a en disposer de plusieurs.
eth0, eth1: : : Cartes Ethernet. Il s'agit du nom generique de la plupart de ces
peripheriques.
dl0, dl1: : : Ces interfaces permettent d'acceder a un adaptateur de poche D-Link
DE-600, un autre peripherique Ethernet. Il est un peu special, en ce
sens qu'il est pilote par le port imprimante parallele du PC.
sl0, sl1: : : Interfaces SLIP. Elles sont associees aux ports serie, dans l'ordre ou
elles sont allouees pour une liaison SLIP. Le noyau supporte jusqu'a
quatre interfaces de ce type (16 sur option dans les versions recentes).
ppp0, ppp1: : : Interfaces PPP. Tout comme les precedentes, elles sont associees a
chaque port serie passe en mode PPP. Pour l'instant, il peut y en
avoir jusqu'a quatre, ou plus en modi ant legerement le code source.
plip0, plip1: : : Interfaces PLIP, permettant de transporter des datagrammes IP par
les ports imprimante parallele. Jusqu'a trois interfaces de ce type
sont supportees ; elles sont allouees par le pilote PLIP au moment de
l'amorcage du systeme, pour chaque port parallele.
Lorsque d'autres pilotes de peripheriques verront le jour, comme ISDN, AX.25 (qui
sont en stade alpha de developpement), ou autres, de nouveaux noms feront leur
apparition.
Dans les sections suivantes, nous allons aborder en detail l'utilisation des pilotes de-
crits ci-dessus.

3.4 Installation Ethernet


Le code reseau du noyau de Linux supporte diverses marques de cartes Ethernet. L'es-
sentiel des pilotes a ete ecrit par Donald Becker (becker@cesdis.gsfc.nasa.gov),
auteur d'une famille de pilotes pour les cartes construites autour du circuit 8390
de National Semiconductor, connue maintenant sous le nom de (( serie Becker )). Il
y a egalement de quoi gerer l'adaptateur D-Link, qui permet de connecter un re-
seau Ethernet par le port parallele, ce pilote est realise par David C. Davies (da-
vies@wanton.lkg.dec.com).

3.4.1 C^ablage Ethernet


Si vous installez un reseau Ethernet pour la premiere fois de votre vie, quelques mots
sur son c^ablage ne seront pas de trop ici. L'Ethernet est tres sensible a la qualite des
liaisons ; le c^able doit ^etre termine a chacun des deux bouts par une resistance de 50
,
48 Chapitre 3. Con guration de l'equipement reseau
et vous ne devez pas creer de branches (c'est-a-dire de connexion en etoile). Si vous
employez un c^able coaxial avec des connecteurs en (( T )), ces connecteurs doivent ^etre
branches directement sur la carte Ethernet : vous ne devez jamais inserer un c^able a
cet endroit.
Si vous vous connectez sur un (( gros )) Ethernet, vous devrez brancher votre machine
par l'intermediaire d'un transceiver (appele quelquefois Ethernet Attachment Unit).
Il peut se brancher dans la prise AUI a 15 broches de votre carte Ethernet. Mais il
est aussi possible d'employer un c^able blinde entre le transceiver et la prise AUI.

3.4.2 Cartes supportees


Une liste complete des cartes Ethernet supportees par Linux est disponible dans le
document (( Ethernet HOWTO )), qui est poste tous les mois dans le forum Usenet
comp.os.linux.anwers, par Paul Gortmaker 3.
La liste ci-dessous contient les cartes les plus connues supportees par Linux. La liste
originale est au moins trois fois plus longue. M^eme si votre materiel est cite ici,
consultez d'abord le HOWTO ; il y a souvent de petits details importants a savoir
pour con gurer correctement certains equipements. Un excellent exemple : certaines
cartes Ethernet utilisent par defaut le m^eme canal DMA (acces direct memoire) que
le contr^oleur SCSI Adaptec 1542. Si vous ne changez rien sur ces cartes, votre disque
dur risque de contenir des donnees erratiques a chaque paquet reseau recu...
3Com EtherLink
Sont supportes parfaitement les modeles 3c503 et 3c503/16, ainsi que
les 3c507 et 3c509. La carte 3c501 fonctionnera egalement sous Linux,
mais est bien trop mediocre pour une reelle utilisation.
Novell Eagle NE1000 et NE2000, et une grande quantite de clones. Les modeles
NE1500 et NE2100 sont egalement supportes.
Western Digital/SMC
WD8003 et WD8013 (les m^emes que SMC Elite et SMC Elite Plus)
sont supportees, ainsi que la nouvelle SMC Elite 16 Ultra.
Hewlett Packard
HP 27252, HP 27247B, et HP J2405A.
D-Link Adaptateur (( pocket )) DE-600, DE-100, DE-200, et DE-220-T. Il
existe aussi un patch pour faire fonctionner la DE-650-T, qui est une
carte PCMCIA 4 .
DEC DE200 (32K/64K), DE202, DE100, et DEPCA revision E.
3 Paul peut ^etre joint a l'adresse gpg109@rsphysse.anu.edu.au.
:
4 On peut l'obtenir, ainsi que d'autres utilitaires, sur les sites miroir Linux comme tsx-
:
11.mit.edu ou en France ftp.ibp.fr, dans /pub/linux/packages/laptops.
3.4. Installation Ethernet 49

Allied Teliesis AT1500 et AT1700.


Pour utiliser l'une de ces cartes sous Linux, vous pouvez employer un noyau pre-
compile en provenance de l'une des principales distributions binaires du systeme ;
tous les pilotes correspondants y sont generalement integres. Toutefois, a terme, la
meilleure solution sera de vous compiler votre propre noyau avec la con guration
exacte dont vous aurez besoin.

3.4.3 Autodetection des cartes Ethernet


Lors de l'amorcage de Linux, le noyau va essayer de localiser votre carte Ethernet et
en determiner le type. Le tableau suivant montre l'ordre dans lequel ces tests sont
e ectues (le premier est en haut) et les adresses testees.

Carte Adresses testees


SMC 16 Ultra 0x300, 0x280
3c501 0x280
3c503 0x300, 0x310, 0x330, 0x350, 0x250,
0x280, 0x2a0, 0x2e0
NEx000 0x300, 0x280, 0x320, 0x340, 0x360
HP 0x300, 0x320, 0x340, 0x280, 0x2C0,
0x200, 0x240
DEPCA 0x300, 0x320, 0x340, 0x360

Cette detection automatique pose deux problemes. Le premier est que le code peut
ne pas detecter correctement toutes les cartes ; c'est particulierement vrai dans le cas
de clones bon marche courants et pour quelques cartes de type WD80x3. Le second
probleme, est que le noyau ne prendra en compte qu'une seule carte Ethernet, la
premiere rencontree, et ne cherchera pas plus loin. Ce comportement est volontaire,
car on suppose que, dans ce cas, vous voulez contr^oler quelle carte est assignee a quelle
interface.
Si vous utilisez plusieurs cartes Ethernet dans la m^eme machine, ou si l'autodetection
echoue, il vous faudra indiquer au noyau le materiel utilise et les adresses de base a
prendre en compte.
Avec Net-3, il y a deux facons de faire. L'une consiste a changer ou ajouter les infor-
mations necessaires dans le chier drivers/net/Space.c des sources du noyau. Cette
methode n'est recommandee que si vous connaissez bien le code reseau de Linux.
L'autre solution, bien meilleure, consiste a indiquer ces informations au moment de
l'amorcage de Linux. Si vous utilisez lilo pour lancer votre systeme, il vous est pos-
sible de passer des parametres au noyau en les speci ant par l'option append du chier
50 Chapitre 3. Con guration de l'equipement reseau
lilo.conf. Pour informer Linux de la presence d'une carte Ethernet particuliere, vous
pouvez mettre :
ether=irq,adresse,param1,param2,nom

Les quatre premiers parametres sont numeriques, le dernier est le nom du periphe-
rique. Toutes les valeurs numeriques sont optionnelles ; si l'une d'elles est omise ou
initialisee a zero, le noyau tentera de la detecter automatiquement ou utilisera une
valeur par defaut.
Le premier parametre ajuste la ligne d'IRQ assignee au peripherique. Par defaut, le
noyau tentera une autodetection ; le pilote pour 3c503 a la particularite de selectionner
une IRQ libre parmi les IRQ 5, 9, 3 et 4, et con gure la carte pour cette valeur.
Le parametre adresse donne l'adresse de base d'entrees/sorties de la carte ; la valeur
zero indique qu'il faudra tenter une detection automatique aux adresses citees plus
haut.
Les deux parametres restants peuvent avoir di erentes signi cations selon les pilotes.
Pour ce qui est des cartes utilisant de la memoire partagee, comme les WD80x3,
ils speci ent le debut et la n de cette zone de memoire. D'autres cartes utilisent
param1 pour ajuster le niveau des messages de d eboguage aches. Les valeurs de
1 a 7 correspondent a une verbosite croissante, alors que 8 les supprimera tous ; 0
denote la valeur par defaut. Les pilotes 3c503 utilisent param2 pour selectionner le
transceiver interne (defaut) ou un bo^tier externe (avec une valeur de 1). Le premier
utilise le connecteur BNC, le second le port AUI de la carte.
Si vous avez deux cartes Ethernet, vous pouvez laisser Linux detecter la premiere et
passer les parametres pour la seconde par lilo. Vous devez toutefois faire attention
que le pilote ne trouve pas accidentellement la seconde carte avant la premiere, vous
disposez pour cela de l'option reserve de lilo, qui indique explicitement au noyau
d'eviter de tester l'espace d'E/S occupe par cette seconde carte.
Par exemple, pour que Linux installe un second adaptateur Ethernet a 0x300 en tant
que eth1, vous passerez les parametres suivants :
reserve=0x300,32 ether=0,0x300,eth1

L'option reserve permet d'^etre assure qu'aucun pilote ne tentera d'acceder a l'espace
d'entrees/sorties de la carte pour tenter d'autodetecter quelque peripherique. Vous
pouvez egalement utiliser les parametres du noyau pour forcer l'autodetection de
eth0 :
reserve=0x340,32 ether=0,0x340,eth0

Pour supprimer toute detection automatique, vous pouvez speci er un argument


adresse de valeur -1 :

ether=0,-1,eth0
3.5. Le pilote PLIP 51

3.5 Le pilote PLIP


PLIP signi e Parallel Line IP (IP sur port parallele) et constitue une methode econo-
mique pour communiquer en reseau lorsque vous n'avez que deux machines a connec-
ter. Il utilise le port imprimante parallele et un c^able special, et permet des vitesses
de 10 a 20 kbps.
PLIP fut originellement developpe par la societe Crynwr, Inc. Sa realisation est plut^ot
ingenieuse : Depuis toujours, le port parallele des PC n'est qu'un port imprimante
unidirectionnel ; les huit lignes de donnees ne pouvaient ^etre utilisees que pour envoyer
du PC vers le peripherique, mais pas dans l'autre sens. PLIP s'a ranchit de cette
limitation en utilisant les cinq lignes de statut du port pour l'entree des donnees, ce
qui oblige a transferer des demi-octets. Ce mode operatoire s'appelle le mode PLIP 0.
De nos jours, ces ports unidirectionnels ne semblent plus ^etre utilises ; par consequent,
il y a une extension nommee mode 1 qui utilise l'interface 8 bits.
Pour l'instant, Linux ne supporte que le mode 0. Contrairement aux toutes premieres
versions du code, il tente maintenant d'^etre compatible avec les implementations PLIP
de Crynwr, aussi bien qu'avec le pilote PLIP du programme NCSA telnet. 5 Pour
connecter deux machines par PLIP, il vous faut un c^able special que l'on peut acheter
chez certains revendeurs sous le nom de (( Null Printer )) ou (( Turbo Laplink )). Vous
pouvez toutefois le realiser vous-m^eme ; c'est tres simple et bien plus economique.
L'annexe A vous montrera comment.
Le pilote PLIP de Linux est le resultat du travail d'innombrables participants ; il est
actuellement maintenu par Niibe Yutaka. Lorsqu'il est inclus dans le noyau, il cree
une interface reseau pour chacun des ports imprimante possibles, plip0 correspondant
au premier (lp0), plip1 etant le second (lp1), et ainsi de suite. La correspondance entre
ces interfaces et les ports est la suivante :

Interface Port E/S IRQ


plip0 0x3BC 7
plip1 0x378 7
plip2 0x278 5

Si vous avez con gure votre port parallele di eremment, vous devrez changer ces
valeurs dans le chier drivers/net/Space.c des sources du noyau de Linux et recompiler
une nouvelle version.
Les ports imprimante restent utilisables normalement : ils ne sont pris en charge par
le pilote PLIP que lorsque l'interface correspondante est con guree (( up )).
5 NCSA telnet est un celebre programme pour MS-DOS qui fournit TCP/IP sur Ethernet ou
:
PLIP, et supporte telnet et FTP.
52 Chapitre 3. Con guration de l'equipement reseau
3.6 Les pilotes SLIP et PPP
SLIP (Serial Line IP) et PPP (Point-to-Point Protocol) sont tres utilises pour transfe-
rer des paquets IP par des liaisons serie. Beaucoup de fournisseurs de connectivite IP
o rent des acces a l'Internet par connexion telephonique, a l'aide d'un modem et de
SLIP ou PPP (seul moyen nancierement a la portee des particuliers pour l'instant).
Pour employer ces protocoles, aucune modi cation materielle n'est a e ectuer ; vous
pouvez utiliser n'importe quel port serie. Comme la con guration de ces ports serie
n'est pas speci que a TCP/IP, un chapitre separe y est consacre. Pour plus d'infor-
mations, consultez par consequent le chapitre 4, page 53.
53

Chapitre 4
Con guration des ports serie
Certaines rumeurs rapportent qu'il y aurait des gens n'ayant qu'un ordinateur, et
trop pauvres pour s'o rir une liaison Internet T1. Il para^trait que pour acceder tout
de m^eme au courrier electronique et aux News Usenet, ils utilisent des connexions
SLIP, des reseaux UUCP et des serveurs BBS, qui passent par le reseau telephonique
public.
Ce chapitre est destine a aider tous ceux qui, comme eux, sont relies au reste du monde
gr^ace a un modem. Toutefois, nous ne pourrons entrer dans le detail ici, comme la
con guration du modem en reponse pour realiser un serveur par exemple. Consultez
le document Linux Serial HOWTO de Greg Hankins 1 , qui est poste regulierement
dans le forum Usenet comp.os.linux.announce, pour obtenir des renseignements
plus precis.

4.1 Programmes de communication pour modems


Vous trouverez bon nombre de programmes de communications fonctionnant sous
Linux. Beaucoup d'entre eux sont des emulateurs de terminaux, qui permettent de
se connecter a un autre ordinateur comme depuis un simple terminal. Le programme
traditionnel permettant cela sous UNIX est kermit. Mais ses possibilites sont plut^ot
reduites, il existe bien d'autres logiciels plus souples et ergonomiques, comportant
annuaires telephoniques, langages script, etc. L'un deux, minicom, ressemble beaucoup
aux programmes de communications pour MS-DOS, tant dans son apparence que dans
son utilisation. Il en existe egalement pour X Window, seyon par exemple.
Il existe aussi un certain nombre de logiciels de BBS, pour ceux qui desirent monter
un serveur de ce type. On peut en trouver par exemple sur sunsite.unc.edu dans le
repertoire /pub/Linux/system/Network.
1 On peut joindre Greg a l'adresse gregh@cc.gatech.edu.
:
54 Chapitre 4. Con guration des ports serie
En dehors des emulateurs de terminaux, il existe aussi des programmes utilisant une
liaison serie non interactive pour transporter des donnees entre ordinateurs. En e et, il
est beaucoup plus rapide de telecharger de maniere automatique quelques douzaines de
kilo-octets que de lire votre courrier en restant connecte, par exemple. En contrepartie,
cela demande bien plus de place disque en raison des informations inutiles que vous
ne lirez pas, mais transfererez quand m^eme ; particulierement dans les News Usenet.
Le meilleur exemple de ce type de logiciels de communication est UUCP. Il s'agit
d'une serie de programmes qui copient des chiers entre ordinateurs, executent des
commandes sur la machine distante, etc. UUCP est frequemment utilise pour le trans-
port du courrier electronique et de Usenet dans les reseaux prives. L'ensemble Taylor-
UUCP, de Ian Taylor, qui fonctionne aussi sous Linux, sera decrit dans le chapitre
suivant. Il existe d'autres logiciels non interactifs du m^eme genre, utilises sur le reseau
de BBS Fidonet, et des portages Linux sont disponibles, comme par exemple ifmail.
SLIP se situe entre les deux, permettant un usage interactif ou non. Beaucoup utilisent
SLIP pour appeler leur fournisseur de services IP a n de se connecter a l'Internet,
ou pour acceder a tout autre reseau prive. Ce protocole peut aussi ^etre employe pour
des liaisons permanentes entre deux reseaux, bien que ce ne soit vraiment interessant
que par ISDN 2 .

4.2 Introduction aux peripheriques serie


Les peripheriques qu'o re un noyau UNIX pour acceder aux terminaux serie sont
typiquement appeles ttys. Il s'agit de l'abreviation de TeletypeTM , qui etait l'un des
principaux constructeur de terminaux dans les premiers jours d'UNIX. Le terme est
reste pour designer maintenant tout terminal fonctionnant en mode texte. Tout au
long de ce chapitre, nous utiliserons tty exclusivement pour designer les peripheriques
o erts par le noyau.
Linux fait la distinction entre trois classe de ttys : les consoles (virtuelles), les pseudo-
terminaux (semblables a un tube bi-directionnel, utilises par des applications comme
X11), et les peripheriques serie. Ces derniers sont comptes parmi les ttys, car ils
permettent des sessions interactives via une connexion serie ; que ce soit depuis un
terminal c^able ou un ordinateur distant connecte par telephone.
Les ttys possedent un certain nombre de parametres con gurables, par l'intermediaire
de l'appel systeme ioctl(2). Beaucoup ne concernent que les ports serie, car ce type de
peripherique demande une grande souplesse pour s'adapter a tout type de connexions.
Parmi les parametres les plus importants de la ligne, on trouve la vitesse et la parite.
Mais il existe aussi des drapeaux ( ags) pour la conversion entre majuscules et mi-
nuscules, des retour-chariots en sauts de ligne, etc. Le pilote tty peut aussi supporter
2 Dans certains pays, une liaison permanente par l'equivalent de notre NUME RIS est nanciere-
:
ment abordable pour un particulier ; ce n'est evidemment pas du tout le cas en France.
4.3. Acceder aux ports serie 55

diverses disciplines de ligne, qui permettent de changer completement le comporte-


ment du peripherique. Par exemple, le pilote SLIP de Linux est implemente au moyen
d'une discipline de ligne speciale.
La mesure de la vitesse d'une ligne serie est un peu ambigue. En principe, il s'agit du
nombre de bits par seconde (bps). Quelquefois, vous entendrez des gens exprimer cette
vitesse en bauds, ce qui est incorrect. Ces deux termes ne sont pas interchangeables:
les bauds se referent a une caracteristique physique de quelque peripherique, la fre-
quence a laquelle des impulsions sont transmises. Les bits par seconde denotent une
caracteristique d'une connexion serie existant entre deux points, mesurant le nombre
moyen de bits transmis en une seconde. Il est important de savoir que ces deux valeurs
sont generalement di erentes, car beaucoup de peripheriques encodent plusieurs bits
par impulsion electrique.

4.3 Acceder aux ports serie


Comme pour tous les peripheriques dans un systeme UNIX, on accede aux ports serie
par l'intermediaire de chiers speciaux, situes dans le repertoire /dev. Mais dans le
cas particulier des ports serie, chaque port se voit attribuer deux chiers di erents,
qui confereront au peripherique un comportement di erent selon qu'on utilisera l'un
ou l'autre.
Le premier peripherique est employe lorsque le port est utilise en entree, pour recevoir
des appels ; il a un nombre majeur de 4, et les chiers s'appellent ttyS0, ttyS1, etc. Le
second sert pour utiliser le port en sortie, pour realiser des appels ; le nombre majeur
est 5 et les chiers se nomment alors cua0, cua1, etc.
Les nombres mineurs sont identiques pour les deux types. Si votre modem est connecte
a l'un des ports que l'on appelle souvent COM1 a COM4, le nombre mineur sera le
numero du port de communication plus 63. Si votre equipement est di erent, par
exemple si vous employez une carte multiserie o rant bien plus de 4 ports, consultez
le document Serial HOWTO.
Supposons que votre modem soit connecte sur COM2. Par consequent le nombre
mineur vaudra 65, et pour l'utiliser en appel le nombre majeur sera 5. Il devrait y
avoir un chier de peripherique nomme cua1 ayant ces caracteristiques. Achez la
liste des ttys serie du repertoire /dev. Les colonnes 5 et 6 montrent respectivement
les nombres majeurs et mineurs :
$ ls -l /dev/cua*
crw-rw-rw- 1 root root 5, 64 Nov 30 19:31 /dev/cua0
crw-rw-rw- 1 root root 5, 65 Nov 30 22:08 /dev/cua1
crw-rw-rw- 1 root root 5, 66 Oct 28 11:56 /dev/cua2
crw-rw-rw- 1 root root 5, 67 Mar 19 1992 /dev/cua3

Si vous n'avez rien de tout cela sur votre systeme, vous allez devoir les creer.
56 Chapitre 4. Con guration des ports serie
Passez superutilisateur et tapez :
# mknod -m 666 /dev/cua1 c 5 65
# chown root.root /dev/cua1

Certains suggerent de creer un lien symbolique du nom de /dev/modem vers le peri-


pherique ou le modem est connecte, de sorte que les utilisateurs occasionnels n'aient
pas a se souvenir de noms aussi peu intuitifs que /dev/cua1. Toutefois, vous ne devrez
pas utiliser /dev/modem dans un programme et le vrai /dev/cua1 dans un autre, car
certains logiciels emploient parfois des chiers de verrouillage pour signaler l'utilisa-
tion du peripherique. Par convention, ces chiers portent un nom derive ; par exemple
ce sera LCK..cua1 pour indiquer que /dev/cua1 est occupe. Si di erents programmes
accedaient au m^eme modem par di erents noms de peripheriques, ils ne pourraient
pas reconna^tre leurs chiers de verrouillage les uns des autres, et les applications ne
fonctionneraient pas correctement.

4.4 Les ports serie


Linux supporte une grande variete de cartes serie au standard RS-232, qui est la norme
la plus repandue pour la communication serie dans le monde du PC (et ailleurs). Elles
utilisent di erents circuits electroniques pour transmettre des bits et des informations
de synchronisation, et des lignes additionnelles peuvent ^etre presentes pour signa-
ler des conditions particulieres de la machine ou du modem (detection de porteuse,
contr^ole de ux materiel, etc).
Bien que le contr^ole de ux materiel soit facultatif, il est extr^emement utile. Il permet
a chacune des stations de signaler lorsqu'elle est pr^ete a recevoir plus de donnees, ou
si l'autre c^ote doit attendre un peu que les caracteres recus aient ete traites avant
de continuer. Les lignes utilisees pour cela sont appelees (( Clear to Send )) (CTS) et
(( Request to Send )) (RTS), ce qui a donn e naissance au terme universellement utilise
de (( contr^ole de ux RTS/CTS )) 3 .
Dans les PC, l'interface RS-232 est generalement realisee autour d'un circuit ERAU 4
derive du 16450 de National Semiconductor, ou de la nouvelle version NSC 16550A 5.
La principale di erence entre les 16450 et les 16550 est que ces derniers comportent
un tampon FIFO de 16 octets, alors que le premier ne possede de stockage que pour
1 octet. Le 16550 est donc preferable pour une utilisation a de hautes vitesses, par
rapport au 16450 qu'il vaut mieux eviter au-dela de 9 600 bauds. Linux gere bien
3 Il existe une denomination francaise pour tous les signaux RS-232, basee non pas sur des noms,
:
mais des numeros tellement peu comprehensibles et memorisables que personne ne l'utilise.
4 ERAU : (( E metteur-Recepteur Asynchrone Universel )), UART en anglais.
:
5 Quelques constructeurs, en particulier les fabricants de modems internes equipes de circuits
:
Rockwell, utilisent des composants totalement di erents qui ont ete programmes pour se comporter
comme le NSC 16550.
4.4. Les ports serie 57

entendu tous ces circuits, ainsi que le 8250, qui fut le premier ERAU a equiper les
ordinateurs de type PC.
Dans la con guration par defaut, le noyau teste les quatre ports serie standard COM1
a COM4. Ils se verront assigner les nombres mineurs 64 a 67, comme nous l'avons vu
plus haut.
Si vous voulez con gurer vos ports serie correctement, il vous faudra installer le pro-
gramme setserial de Ted Tso's, ainsi que le script /etc/rc.serial qui sera execute au
demarrage du systeme. Voici un exemple d'un tel script :
# /etc/rc.serial - script de configuration des ports s
erie.
#
# D
etection interruptions
/sbin/setserial -W /dev/cua*

# Configuration des p
eriph
eriques
/sbin/setserial /dev/cua0 auto_irq skip_test autoconfig
/sbin/setserial /dev/cua1 auto_irq skip_test autoconfig
/sbin/setserial /dev/cua2 auto_irq skip_test autoconfig
/sbin/setserial /dev/cua3 auto_irq skip_test autoconfig

# Affichage de la configuration courante


/sbin/setserial -bg /dev/cua*

Consultez la documentation fournie avec setserial pour avoir une explication detaillee
des parametres a employer.
Si votre carte serie n'est pas detectee, ou si la commande setserial -bg montre une
con guration erronee, vous devrez forcer les valeurs correctes en les indiquant explici-
tement. Ce probleme se produit parfois avec des modems internes equipes de circuits
Rockwell. Si, par exemple, l'ERAU est detecte comme etant un NSC 16450, alors qu'il
s'agit en realite d'un compatible NSC 16550, vous devrez modi er la con guration du
port en question ainsi :

/sbin/setserial /dev/cua1 auto irq skip test autoconfig uart 16550

Il existe des options similaires pour forcer le port de communication, l'adresse de base,
et la ligne d'IRQ utilisee. Lisez la page de manuel de setserial(8) pour plus de details.
Si votre modem supporte le contr^ole de ux materiel, assurez-vous qu'il soit bien en
service. Les programmes de communications n'essaient pas de le valider par defaut ;
vous devez, aussi etonnant que cela puisse para^tre, le faire manuellement. La meilleure
solution est de le mettre en service au lancement du systeme en mettant dans le chier
rc.serial une commande stty comme ceci :

$ stty crtscts </dev/cua1


58 Chapitre 4. Con guration des ports serie
Pour veri er si le contr^ole de ux RTS/CTS est actif, faites :
$ stty -a </dev/cua1

Cette commande vous achera le parametrage du port serie concerne avec tous les
details ; chaque drapeau est ache, avec un signe negatif s'il est invalide. Vous devrez
trouver dans la liste, crtscts. Si vous voyez -crtscts, c'est que le contr^ole de ux
n'est pas en service.
59

Chapitre 5
Con guration du reseau
TCP/IP
Nous allons decrire dans ce chapitre toutes les etapes necessaires pour con gurer
TCP/IP sur votre machine. En partant de l'assignation des adresses IP, nous verrons
la con guration des interfaces et, petit a petit, aboutirons a la description de quelques
outils tres pratiques pour traquer les eventuels problemes pouvant survenir sur votre
installation reseau.
Les di erentes operations que nous allons decrire ne seront a e ectuer qu'une seule
fois, pour la majorite d'entre elles. Ensuite, vous n'aurez de modi cations a faire que
lors de l'ajout d'une nouvelle machine sur le reseau, ou si vous recon gurez entierement
le systeme. Quelques commandes seront toutefois a executer a chaque demarrage de
Linux, on les invoque generalement depuis les scripts /etc/rc du systeme.
Tres souvent, la partie de cette procedure speci que au reseau se trouve dans un
script appele rc.net ou rc.inet. Quelquefois, vous en trouverez deux, nommes rc.inet1 et
rc.inet2, le premier initialisant la partie reseau relative au noyau, le second s'occupant
de lancer les services et applications de base. Ici, nous adopterons cette derniere
solution, ces chiers rc.inet1 et rc.inet2 ayant l'avantage de bien clari er les choses.
Nous allons commencer par rc.inet1, et nous traiterons des applications dans les pro-
chains chapitres. Apres avoir assimile celui-ci, vous devriez avoir etabli une sequence
de commandes qui con gurent proprement le reseau TCP/IP sur votre ordinateur.
Vous devrez alors remplacer tous les exemples contenus dans rc.inet1 par vos propres
commandes, et vous assurer que ce script est bien execute au demarrage du systeme.
Les scripts rc fournis dans votre distribution favorite de Linux devraient vous donner
un bon exemple de ce qu'il faut faire.
60 Chapitre 5. Con guration du reseau TCP/IP
5.1 Montage du systeme de chiers proc
Quelques outils de con guration de la version Net-2 ont besoin du systeme de chiers
proc pour communiquer avec le noyau. Il s'agit d'une interface qui permet d'acceder
a certaines informations internes par l'intermediaire de chiers. Lorsque /proc est
monte, vous pouvez lister son contenu comme n'importe quel autre systeme de chiers,
et acher par les methodes habituelles toutes les informations disponibles. Vous y
trouverez par exemple le chier loadavg, contenant la charge de la machine, meminfo,
qui montre l'utilisation instantanee de la memoire et de la zone de swap.
Le code reseau ajoute a tout cela le repertoire net. Il contient un certain nombre
de chiers montrant certaines choses comme les tables ARP du noyau, l'etat des
connexions TCP, les tables de routage, etc. La plupart des outils d'administration
reseau obtiennent leurs informations en lisant ces donnees.
Le systeme de chiers proc (connu aussi sous le nom de procfs) est generalement monte
dans /proc lors du demarrage du systeme. La meilleure methode pour qu'il le soit est
d'ajouter la ligne suivante dans le chier /etc/fstab :
# point de montage du procfs:
none /proc proc defaults

et d'executer (( mount /proc )) depuis votre script /etc/rc.


Ce procfs est maintenant con gure dans la plupart des noyaux par defaut. S'il ne l'est
pas dans le v^otre, vous obtiendrez un message du genre : (( mount: fs type procfs
not supported by kernel )) (syst eme de chiers type procfs non supporte par le
noyau). Il vous faudra dans ce cas recompiler ce noyau en repondant (( yes )) lorsque
la con guration vous demandera si vous desirez le support de procfs.
Un dernier mot a propos de procfs. Bien qu'apparaissant comme n'importe quel reper-
toire, contenant des chiers textes ou binaires de toutes tailles, vous ne devez pas vous
inquieter pour votre precieux espace disque dur : ce ne sont que des chiers virtuels,
simules par le noyau. Le tres gros kcore, par exemple, correspond simplement a toute
la memoire dont vous disposez ; plus vous aurez de RAM, plus il sera gros, mais il
n'occupe aucune place disque.

5.2 Installation des binaires


Si vous utilisez l'une des distributions toutes faites de Linux, elle contiendra probable-
ment la plus grande partie des applications et utilitaires reseau, ainsi qu'un ensemble
coherent d'exemples de con guration. Le seul cas ou vous pourrez avoir a vous procu-
rer et installer cette partie, sera lorsque vous installerez une toute nouvelle version du
noyau, pouvant demander une mise a jour de ces programmes. Souvent, l'evolution
de Linux apporte de profondes modi cations rendant les anciens utilitaires relatifs au
reseau, incompatibles avec la partie correspondante dans le noyau. Il sut souvent
5.3. Un nouvel exemple 61

de recompiler l'ensemble, mais quelquefois il vous faudra quand m^eme changer tous
les programmes. L'ensemble est generalement distribue parallelement aux nouvelles
sources du noyau, dans des chiers appeles net-XXX.tar.gz, ou varXXX correspond au
numero de version. Pour Linux 1.0, il s'agit de 0.32b. Le dernier noyau, a l'heure ou
nous ecrivons ces lignes (1.1.72 et plus), necessite au minimum net-tools-1.1.56.tar.gz.
Si vous desirez compiler et installer les applications TCP/IP standard vous-m^eme,
vous en trouverez les sources sur la plupart des serveurs FTP ou BBS di usant Linux.
Ce sont des versions plus ou moins modi ees des programmes de Net-BSD ou quelques
autres sources. D'autres grosses applications, comme Mosaic, Archie, Gopher ou IRC
doivent ^etre obtenues separement, comme pour tout autre systeme UNIX. La plupart
se compilent sans modi cation sous Linux si vous suivez correctement les instructions.
Le site FTP ociel de Net-3 est sunacm.swan.ac.uk, repris par sunsite.unc.edu
dans le repertoire system/Network/sunacm. Le code derive de BSD par Matthias Ur-
lich peut ^etre obtenu sur ftp.ira.uka.de dans /pub/system/linux/netbsd. En France,
allez d'abord voir sur ftp.ibp.fr, le repertoire /pub/linux contient des miroirs de
di erents sites ; vous ne devriez pas avoir besoin d'utiliser de co^uteuses liaisons inter-
nationales pour vous procurer du code source Linux.

5.3 Un nouvel exemple


Pour toute la suite de ce livre, nous allons prendre un exemple bien plus simple
que l'universite Groucho Marx, et qui devrait ^etre plus proche de ce que vous allez
couramment rencontrer. Considerons donc (( La biere virtuelle )), une petite societe qui
brasse, comme son nom l'indique, de la biere virtuelle. A n de gerer plus ecacement
leurs a aires, nos brasseurs virtuels desirent relier leurs ordinateurs en reseau, et il se
trouve qu'ils fonctionnent tous sous le merveilleux Linux 1.0.
Au m^eme etage, de l'autre c^ote du couloir de l'immeuble, se trouve la societe (( Les
caves virtuelles )), des viticulteurs travaillant etroitement avec nos brasseurs. Ils pos-
sedent leur propre reseau Ethernet. Naturellement, les deux compagnies veulent relier
leurs deux reseaux ensemble une fois qu'ils seront operationnels. Pour commencer,
ils desirent installer une passerelle permettant de transferer des datagrammes entre
ces deux reseaux. Plus tard, ils etabliront un lien UUCP avec le monde exterieur,
a n d'avoir acces au courrier electronique et aux News Usenet. En n, dans l'avenir,
ils pensent installer une connexion SLIP pour pouvoir occasionnellement ^etre relies a
l'Internet.

5.4 Assignation du nom de machine


Pratiquement toutes les applications reseau necessitent qu'il ait ete attribue un nom a
la machine. Generalement, cela est realise lors du demarrage du systeme en executant
62 Chapitre 5. Con guration du reseau TCP/IP
la commande hostname ; pour initialiser le nom d'h^ote a la valeur nom, elle doit ^etre
invoquee ainsi :

# hostname nom

La pratique courante est d'indiquer ici le nom d'h^ote non quali e, c'est-a-dire sans
speci er le nom de domaine. Par exemple, les machines de (( La biere virtuelle )) peuvent
s'appeler trappiste.bibine.com, kro.bibine.com, etc. Ce sont leurs noms ociels,
pleinement quali es. Leur noms d'h^otes locaux seraient alors uniquement la premiere
composante, comme trappiste. Toutefois, comme le nom local est frequemment utilise
pour trouver l'adresse IP de la machine, vous devez vous assurer que le resolver
soit capable de le faire ; cela signi e que vous devez indiquer ce nom dans le chier
/etc/hosts.
Certains suggerent d'utiliser la commande domainname pour indiquer au noyau quel
est le nom de domaine, la partie restante du FQDN. Ainsi, il serait possible de com-
biner la sortie de hostname et de domainname pour obtenir le nom quali e. Pourtant,
cette solution n'est qu'a moitie correcte : la commande domainname est normalement
utilisee pour initialiser le domaine NIS de la machine, qui peut ^etre totalement di e-
rent du domaine DNS auquel cet h^ote appartient.

5.5 Assignation des adresses IP


Si vous con gurez le reseau sur votre machine pour une utilisation locale autonome
(par exemple, juste pour installer le serveur de News INN), vous pouvez sauter cette
section, car la seule adresse IP dont vous avez besoin correspond a l'interface loopback,
et vaudra toujours 127.0.0.1.
Les choses se compliquent un peu avec de vrais reseaux comme l'Ethernet. Si vous
desirez connecter votre systeme a un reseau existant, vous devrez demander a ses
administrateurs de vous donner une adresse IP. Si vous installez vous-m^eme tout un
reseau, ce sera a vous d'attribuer toutes les adresses.
Les h^otes d'un reseau local doivent en principe partager des adresses appartenant au
m^eme reseau IP logique. Par consequent, vous devez attribuer une adresse au reseau.
Si vous devez installer plusieurs reseaux physiques, vous devrez soit leur attribuer des
valeurs reseau di erentes, soit utiliser des sous-reseaux pour partager votre gamme
d'adresses IP possibles en plusieurs sous-reseaux. Nous detaillerons cette derniere
solution dans la section suivante.
Le choix d'une adresse IP reseau depend etroitement de ce que vous comptez en faire.
Si vous avez l'intention de vous connecter a l'Internet dans un avenir proche, il va vous
falloir obtenir des maintenant une adresse ocielle. La meilleure facon de proceder
est de demander a votre fournisseur de connectivite IP de vous aider, c'est son travail.
Sinon, demandez un formulaire de demande d'adresse ((( Network Address Application
5.6. Creation de sous-reseaux 63

Form ))) a hostmaster@internic.net, ou au NIC ((( Network Information Center )))


de votre pays s'il en existe un.
Si votre reseau n'est pas connecte a l'Internet et n'y sera pas dans un avenir proche,
vous ^etes libre de choisir n'importe quelle adresse valide. Assurez-vous simplement
que jamais aucun de vos datagrammes internes ne s'echappe vers le vrai Internet.
Pour en ^etre vraiment s^ur, il vaut mieux utiliser l'une des adresses reseau reservees
pour les usages prives. Le IANA (Internet Assigned Numbers Authority), la (( haute
autorite )) regissant l'attribution des adresses sur l'Internet, a mis au point plusieurs
adresses reseau de classes A, B et C que vous pouvez utiliser librement sans avoir a
vous enregistrer ociellement. Elles ne sont valides qu'a l'interieur de votre reseau
prive et ne sont jamais routees entre les vrais sites Internet. Ces valeurs, de nies dans
le RFC 1597, sont :
Classe Reseaux
A 10.0.0.0
B 172.16.0.0 jusqu'a
172.31.0.0
C 192.168.0.0 jusqu'a
192.168.255.0
Notez que les deuxieme et troisieme blocs contiennent respectivement 16 et 256 re-
seaux.
Choisir vos adresses dans l'un de ces reseaux n'est pas seulement utile lorsque vous
^etes isole de l'Internet ; vous pouvez aussi realiser un acces bien plus restrictif en
employant une machine en tant que passerelle. Pour votre reseau local, la passerelle
sera accessible par son adresse IP interne, alors que le reste du monde la conna^tra
par une adresse ocielle d^ument enregistree (que votre fournisseur de services vous
aura attribuee par exemple). Nous reviendrons sur ce type de con guration lorsque
nous parlerons de SLIP, dans le chapitre 7 (page 101).
Pour toute la suite de cet ouvrage, nous considererons que l'administrateur reseau
de (( La biere virtuelle )) utilise un reseau de classe B, disons 172.16.0.0. Bien s^ur,
une classe C aurait largement su pour satisfaire les besoins de nos brasseurs et
viticulteurs virtuels. Nous avons choisi une classe B pour des raisons de simplicite,
cela rendra les exemples de sous-reseaux de la section suivante bien plus faciles a
comprendre.

5.6 Creation de sous-reseaux


Pour gerer plusieurs reseaux Ethernet (ou d'autres types, selon les pilotes disponibles),
vous devez scinder votre reseau en sous-reseaux. Notez que ce n'est necessaire que si
vous avez plus d'une adresse de di usion ; les liaisons point-a-point ne comptent pas.
Par exemple, si vous avez un reseau Ethernet et un ou plusieurs liens SLIP vers le
64 Chapitre 5. Con guration du reseau TCP/IP

191 72 0 0

191 72 1 0 191 72 2 0

Sous-reseau brasseurs Passerelle Sous-reseau viticulteurs

Fig. 5.1 - Les deux sous-reseaux des brasseurs et viticulteurs.

monde exterieur, vous n'avez pas besoin de creer de sous-reseaux: nous expliquerons
pourquoi dans le chapitre 7.
Pour gerer les deux reseaux locaux Ethernet, l'administrateur des brasseurs virtuels
a decide d'utiliser 8 bits de la partie h^ote comme bits additionnels de sous-reseau.
Cela lui laisse 8 autres bits pour la partie h^ote, permettant 254 machines sur chacun
des sous-reseaux. Il assigne alors le sous-reseau numero 1 aux brasseurs, et donne le
numero 2 aux viticulteurs. Leurs adresses reseaux respectives sont alors 172.16.1.0
et 172.16.2.0. Le masque de sous-reseau vaut 255.255.255.0.
La machine kro, qui est la passerelle entre les deux reseaux, se voit attribuer un
nombre d'h^ote de 1 sur chacun d'eux, ce qui donne respectivement les adresses IP
172.16.1.1 et 172.16.2.1. La gure 5.1 illustre la situation, montrant la passerelle
et les deux sous-reseaux.
Notez que dans cet exemple, nous utilisons un reseau de classe B pour simpli er les
choses ; une classe C serait plus realiste. Sous les versions recentes de Linux, les sous-
reseaux ne sont pas bornes sur 8 bits, par consequent m^eme un reseau de classe C peut
^etre tronconne en plusieurs sous-reseaux. Par exemple, vous pourriez utiliser 2 bits
de la partie h^ote pour le masque reseau, ce qui vous donnerait quatre sous-reseaux
possibles comportant chacun 64 machines 1 .

1 Le dernier nombre de chaque reseau est reserve a l'adresse de di usion, donc il ne s'agirait en
:
realite que de 63 machines possibles par sous-reseau.
5.7. Redaction des chiers hosts et networks 65

5.7 Redaction des chiers hosts et networks


Apres avoir divise votre reseau, vous devez vous arranger pour que la resolution des
noms de quelques machines cruciales soit possible par le chier /etc/hosts. Si vous ne
comptez pas utiliser DNS ou NIS pour la resolution d'adresses, vous devrez indiquer
tous les h^otes dans ce chier.
M^eme si en fonctionnement normal, DNS ou NIS sont en service, vous devez inclure un
petit sous-ensemble de machines dans /etc/hosts. En premier lieu, vous aurez besoin
d'une methode de resolution de noms m^eme lorsqu'aucune interface reseau n'est en
service, par exemple lors du demarrage du systeme. Ce n'est pas qu'une question de
commodite, cela vous permet aussi d'utiliser des noms symboliques dans vos scripts
rc.inet. Ainsi, lors de modi cations d'adresses IP, vous n'aurez qu'a copier une mise
a jour du chier hosts puis reamorcer la machine, au lieu d'^etre oblige de modi er un
grand nombre de chiers rc separement. Generalement, ce sont les noms et adresses des
machines locales que l'on met dans /etc/hosts, plus ceux des passerelles ou eventuels
serveurs NIS s'il en existe 2 .
Vous devrez egalement, lors des premiers essais de mise au point, vous assurer que le
resolver n'utilisera que les informations du chier hosts, sans tenter de se connecter
a un hypothetique serveur de noms. Vos eventuels programmes DNS ou NIS peuvent
^etre fournis avec des exemples de con guration donnant de tres curieux resultats. Pour
^etre certain de n'utiliser exclusivement que /etc/hosts, vous devrez editer le chier
/etc/host.conf. Commentez toutes les lignes qui commencent par le mot cle order en
les faisant preceder d'un diese, et inserez uniquement la ligne :
order hosts

La con guration de la bibliotheque resolver sera traitee en detail dans le chapitre 6.


Le chier hosts contient une entree par ligne, consistant en une adresse IP, un nom
d'h^ote, et une liste facultative d'alias permettant d'appeler plus facilement cette ma-
chine par tout autre nom. Les champs sont separes par des espaces ou des tabulations,
et tout ce qui suivra un signe diese (#) sera considere comme commentaire et sera
ignore.
Les noms d'h^otes peuvent ^etre quali es ou relatifs au domaine local. Dans le cas
de trappiste, on met generalement le nom quali e, trappiste.bibine.com, puis
trappiste seul, de maniere a ce que la machine soit connue aussi bien par son nom
pleinement quali e que par son petit nom local.
Voici un exemple de ce que pourrait ^etre un chier hosts de l'entreprise (( La biere
virtuelle )) : deux noms speciaux ont ete ajoutes, kro-if1 et kro-if2, qui donnent les
adresses des deux interfaces utilisees sur kro.
2 Vous n'aurez besoin de l'adresse des serveurs NIS que si vous utilisez la version NYS de Peter
:
Eriksson. Les autres implementations de NIS trouvent leurs serveurs en cours de route, simplement
en utilisant ypbind.
66 Chapitre 5. Con guration du reseau TCP/IP
#
# Fichier hosts des brasseurs et viticulteurs.
#
# IP FQDN alias
#
127.0.0.1 localhost
#
172.16.1.1 kro.bibine.com kro kro-if1
172.16.1.2 gueuze.bibine.com gueuze
172.16.1.3 trappiste.bibine.com trappiste
#
172.16.2.1 kro-if2
172.16.2.2 brouilly.bibine.com brouilly
172.16.2.3 gamay.bibine.com gamay
172.16.2.4 cahors.bibine.com cahors

Tout comme avec les adresses IP des machines, vous aurez parfois besoin d'utiliser un
nom symbolique pour designer les adresses reseau. Par consequent, le chier /etc/hosts
est accompagne d'un chier semblable, /etc/networks, qui est son equivalent pour les
reseaux. Chez nos brasseurs, nous pourrions installer un chier networks comme celui-
ci 3 :

# /etc/networks de la societe La bi


ere virtuelle.
biere-net 172.16.1.0
pinard-net 172.16.2.0

5.8 Con guration des interfaces reseau


Apres avoir con gure correctement votre equipement comme explique dans le chapitre
precedent, vous devrez faire en sorte que ces peripheriques soient connus de la couche
reseau du noyau. Deux commandes sont necessaires pour cela, qui con gurent les
interfaces et initialisent la table de routage : ifcon g (ou (( if )) signi e interface), et
route. Elles sont generalement invoquees depuis le script rc.inet1 lors du demarrage
du systeme.
La commande ifcon g a pour but de rendre une interface accessible a la couche reseau
du noyau. Cela implique l'assignation d'une adresse IP et quelques autres parametres;
ainsi que l'activation de l'interface, qui sera alors dite (( en service )), ou (( up )), par
opposition a (( hors service )), ou (( down )). Une interface declaree active signi e que le
noyau l'utilisera pour le transport de datagrammes. La facon la plus simple de realiser
cela est de taper :

ifconfig interface addresse-ip

3 Les noms du chier networks ne doivent pas entrer en con it avec ceux du chier hosts, sous
:
peine de reactions tres bizarres de certains programmes.
5.8. Con guration des interfaces reseau 67

Cette commande assignera l'adresse adresse-ip a interface, et activera celle-ci.


Tous les autres parametres seront mis a des valeurs par defaut. Par exemple, le masque
reseau sera derive de la classe du reseau de l'adresse IP, comme 255.255.0.0 pour une
adresse de classe B. La commande ifcon g est decrite en detail a la n de ce chapitre.
La commande route, quant a elle, permet d'ajouter ou de supprimer des entrees dans
la table de routage du noyau ; sa syntaxe est (en partie) la suivante :

route [add|del] cible

Les arguments add et del determinent l'action a e ectuer : add ajoute la route vers
cible, alors que del la supprime.

5.8.1 L'interface loopback


La toute premiere interface a activer est l'interface loopback :

# ifconfig lo 127.0.0.1

Occasionnellement, vous rencontrerez aussi le nom localhost utilise a la place de cette


adresse IP. Le programme ifcon g cherchera ce nom dans le chier /etc/hosts, ou une
entree doit le declarer comme etant le nom correspondant a l'adresse 127.0.0.1 :
# Exemple d'entr
ee du fichier /etc/hosts pour localhost
localhost 127.0.0.1

Pour voir quelle est la con guration courante d'une interface, appelez simplement
ifcon g en lui passant le nom de l'interface en argument :
$ ifconfig lo
lo Link encap Local Loopback
inet addr 127.0.0.1 Bcast [NONE SET] Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0

Comme vous le voyez, l'interface loopback s'est vu assigner un masque reseau de


255.0.0.0, puisque 127.0.0.1 est une adresse de classe A. Aucune adresse de di u-
sion n'est positionnee, et il n'y en a de toutes facons pas vraiment besoin avec cette
interface si particuliere. Toutefois, si vous utilisez le demon rwhod sur cette machine,
vous pourrez avoir besoin d'initialiser l'adresse de di usion de l'interface loopback
pour que ce programme fonctionne correctement. Vous trouverez comment faire dans
la section (( Tout sur ifcon g )), un peu plus loin dans ce chapitre.
68 Chapitre 5. Con guration du reseau TCP/IP
Maintenant, vous pouvez presque commencer a jouer avec votre (( mini-reseau )). Il ne
manque qu'une chose : une entree dans la table de routage qui indique a IP qu'il peut
utiliser cette interface comme route vers 127.0.0.1. On lui indique par :

# route add 127.0.0.1

La encore, vous pouvez indiquer le nom localhost au lieu de l'adresse IP.
Ensuite, vous devez tester que tout marche bien, par exemple en utilisant ping. Le
programme ping est un peu l'equivalent d'un sonar pour le reseau 4. On emploie ping
pour veri er qu'il est bien possible d'atteindre une adresse donnee, et pour mesurer
le temps de propagation entre le moment ou l'on envoie un datagramme et ou il nous
revient. On appelle parfois ce delai le (( temps moyen de propagation )), ou (( round-trip
time )).
# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=32 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=32 time=0 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=32 time=0 ms
^C

--- localhost ping statistics ---


3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0/0/1 ms

En appelant ping comme ci-dessus, il emettra des paquets inde niment jusqu'a ce qu'il
soit interrompu par l'utilisateur. Le ^C visible dans l'exemple correspond au moment
ou le programme a ete arr^ete par Ctrl-C 5 .
Notre exemple montre que les paquets a destination de 127.0.0.1 sont correctement
delivres et qu'une reponse nous est retournee quasi instantanement. Cela prouve que
nous avons reussi a con gurer notre premiere interface reseau.
Si la sortie que vous obtenez de ping ne ressemble pas a ce qui est montre ci-dessus,
c'est que vous avez un probleme quelque part. Veri ez que les programmes ifcon g
et route que vous utilisez sont compatibles avec la version du noyau, et avant tout,
que ce noyau a bien ete compile avec le support du reseau (vous pouvez le veri er
par la presence du repertoire /proc/net). Si vous obtenez le message d'erreur (( Net-
work unreachable )), signi ant que le reseau est inaccessible, c'est que vous vous ^etes
probablement trompe en tapant la commande route. Veri ez que vous utilisez bien la
m^eme adresse que celle indiquee a ifcon g.
Les etapes que nous venons de voir sont susantes pour faire fonctionner des appli-
cations reseau sur une machine isolee. Apres avoir ajoute les lignes de con guration
4 Souvenez-vous... (( Echoes )), Pink Floyd...
:
5 Certaines implementations de ping necessitent la commande
: ping -s pour obtenir le m^eme
resultat, typiquement celles des systeme BSD.
5.8. Con guration des interfaces reseau 69

que nous avons vues dans le chier rc.inet1 et vous ^etre assure que ces scripts rc.inet
sont bien appeles depuis /etc/rc, vous pouvez reamorcer votre machine et essayer dif-
ferentes applications. Par exemple, (( telnet localhost )) devrait etablir une connexion
avec votre propre machine, en vous proposant une invite login.
L'interface loopback n'est pas utile qu'en tant qu'exemple dans les livres sur le reseau,
ou comme test de con guration. Elle est utilisee par quelques applications lors du
fontionnement normal 6 . Par consequent, vous devez toujours la con gurer, que votre
machine soit connectee a un reseau ou non.

5.8.2 Interfaces Ethernet


La con guration d'une interface Ethernet est tres semblable a celle de l'interface
loopback, elle demande juste quelques parametres supplementaires si vous employez
des sous-reseaux.
A (( La biere virtuelle )), nous avons subdivise le reseau IP, qui etait a l'origine de
classe B, en reseaux de classe C. Pour que l'interface reconnaisse ce fait, nous devons
appeler ifcon g de la maniere suivante :
# ifconfig eth0 gueuze netmask 255.255.255.0

Cette commande assigne l'adresse IP de gueuze (172.16.1.2) a l'interface eth0. Si


nous avions omis le masque reseau, ifcon g l'aurait deduit de la classe de l'adresse
reseau, ce qui aurait donne 255.255.0.0. Une petite veri cation nous donne mainte-
nant :
# ifconfig eth0
eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42
inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0

Vous pouvez voir que ifcon g initialise automatiquement l'adresse de di usion (le
champ Bcast ci-dessus) selon la methode usuelle, en mettant a 1 tous les bits de la
partie h^ote de l'adresse reseau. De plus, le MTU ((( Maximum Transfer Unit )), la
taille maximale des trames Ethernet que le noyau generera pour cette interface) a
ete positionne a 1 500 octets. Toutes ces valeurs peuvent ^etre forcees par des options
speciales que nous decrirons plus tard.
Tout comme avec l'interface loopback, nous devons installer une entree dans la table
de routage pour informer le noyau de ce reseau accessible par eth0. Chez nos brasseurs
virtuels, il faudra donc taper la commande route suivante :
# route add -net 172.16.1.0
6 Par exemple, toutes les applications basees sur les RPC utilisent l'interface loopback pour s'en-
:
registrer aupres du demon portmapper au demarrage du systeme.
70 Chapitre 5. Con guration du reseau TCP/IP
A premiere vue, cela semble tenir de la magie, puisqu'il n'appara^t pas clairement
comment route peut detecter par quelle interface cette route doit passer. Pourtant,
le truc est simple : le noyau regarde toutes les interfaces qui ont ete con gurees et
compare l'adresse de destination (172.16.1.0 dans ce cas) avec la partie reseau de
l'adresse de l'interface (c'est-a-dire, un (( ET )) bit a bit entre l'adresse de l'interface
et le masque reseau). La seule qui correspond est eth0.
Mais qu'est-ce que cette option -net est donc censee faire ? Elle est utilisee car route
peut traiter aussi bien des routes vers des reseaux que des routes vers de simples h^otes
(comme vous l'avez vu plus haut dans le cas de localhost). Lorsqu'on lui passe une
adresse en notation sur 4 octets, le programme tente de deviner s'il s'agit d'un reseau
ou d'un h^ote, en regardant les bits de la partie h^ote. Si cette partie h^ote de l'adresse
vaut zero, route considere qu'il s'agit d'un reseau ; et d'une adresse d'h^ote dans le cas
contraire. Par consequent, route penserait que 172.16.1.0 est un h^ote et non pas un
reseau, car le programme ne sait pas que nous utilisons un sous-reseau. Nous devons
donc lui indiquer explicitement qu'il s'agit d'un reseau, en lui passant l'option -net.
Bien s^ur, la commande ci-dessus est un peu penible a taper, et peut entra^ner des
fautes de frappe. Une approche plus pratique consiste a employer les noms de reseaux
que nous avons de nis dans le chier /etc/networks auparavant. Du coup, notre com-
mande devient plus lisible ; et l'on peut m^eme supprimer l'option -net puisque route
sait maintenant que 172.16.1.0 correspond a un reseau.
# route add biere-net

Maintenant que nous avons termine les etapes de base de la con guration, nous al-
lons veri er que notre interface Ethernet fonctionne correctement. Choisissez un h^ote
connecte a votre reseau local, par exemple kro, et tapez :
# ping kro
PING kro: 64 byte packets
64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms
64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms
64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms
64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms
^C

----gueuze.bibine.com PING Statistics----


4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 3/8/12

Si vous ne voyez pas quelque chose ressemblant a cela sur votre ecran, c'est sans
nul doute que quelque chose ne va pas. Si vous rencontrez un taux inhabituel de
paquets perdus, il s'agit probablement d'un probleme materiel, comme des resistances
de terminaison absentes, un c^ablage incorrect, voire... l'oubli de connecter la machine
au reseau. Si vous ne recevez aucun paquet, testez la con guration de l'interface par la
commande netstat. Les statistiques sur les paquets emis et recus aches par ifcon g
devraient vous indiquer si, au moins, des datagrammes ont ete envoyes. Si vous avez
5.8. Con guration des interfaces reseau 71

un acces physique a la machine distante, allez voir egalement les statistiques qu'elle
indique. Vous pourrez ainsi determiner exactement ou les paquets se sont perdus. De
plus, veri ez les informations de routage par la commande route pour voir si les deux
h^otes sont correctement con gures a ce niveau. Invoquee sans arguments, route ache
la totalite de la table de routage du noyau (l'option -n lui fait acher les adresses IP
au lieu des noms des machines) :
# route -n
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.1 * 255.255.255.255 UH 1 0 112 lo
172.16.1.0 * 255.255.255.0 U 1 0 10 eth0

La signi cation detaillee de ces champs est expliquee plus loin, dans la section (( La
commande netstat )). La colonne Flag contient une liste des drapeaux positionnes pour
chaque interface : U signi e qu'elle est active, et H indique que l'adresse de destination
est un h^ote. Si le drapeau H est mis alors que vous vouliez que cette route soit une route
reseau, il vous faut retaper la commande route avec l'option -net. Pour veri er qu'une
route est utilisee, testez si la valeur indiquee dans le champ Use de l'avant-derniere
colonne s'incremente entre deux invocations de ping.

5.8.3 Routage par une passerelle


Dans la section precedente, nous n'avons vu que le cas d'une machine sur un unique
reseau Ethernet. Or, il est courant de rencontrer des interconnexions de reseaux par
l'intermediaire de passerelles. Ces passerelles peuvent se contenter de relier deux re-
seaux ou plus, ou bien o rir egalement un acces au monde exterieur, l'Internet. Pour
utiliser une passerelle, il va falloir donner quelques informations supplementaires a la
couche reseau du noyau.
Par exemple, les reseaux Ethernet des entreprises (( La biere virtuelle )) et (( Les caves
virtuelles )) sont interconnectes par une passerelle, en l'occurrence la machine kro.
En considerant que kro a deja ete correctement con guree, nous n'aurons juste qu'a
rajouter une autre entree a la table de routage de gueuze, qui indiquera au noyau
qu'il peut atteindre toutes les machines du reseau des viticulteurs par l'intermediaire
de kro. La commande route e ectuant cette operation est celle indiquee ci-dessous ;
le mot cle gw lui signale que le prochain argument denote une passerelle (gateway) :
# route add pinard-net gw kro

Bien entendu, chaque machine du reseau des viticulteurs a laquelle vous voudrez par-
ler devra comporter une route correspondante vers le reseau des brasseurs. Sinon,
vous ne pourriez qu'envoyer des donnees depuis gueuze vers, par exemple, gamay ;
mais aucune reponse de cette derniere ne pourrait revenir, les paquets etant irreme-
diablement perdus.
72 Chapitre 5. Con guration du reseau TCP/IP
Cet exemple ne decrit qu'une passerelle permettant l'echange de datagrammes entre
deux reseaux Ethernet isoles. Maintenant, supposons que kro soit aussi connectee a
l'Internet (disons, par une liaison supplementaire SLIP). Nous voudrions alors que les
datagrammes a destination de n'importe quel reseau autre que celui des brasseurs soit
passes a kro. On peut realiser cela en la declarant comme passerelle par defaut :

# route add default gw kro

Le nom de reseau default est un raccourci pour indiquer 0.0.0.0, qui denote la route
par defaut. Vous n'avez pas besoin d'ajouter ce nom au chier /etc/networks, il est
integre directement dans la commande route.
Si vous constatez de nombreuses pertes de paquets en essayant ping vers une machine
situee a une ou plusieurs passerelles de la, ce peut ^etre le signe d'un reseau tres charge.
La perte de datagrammes n'est pas tellement le fait de de ciences techniques, mais
elle est surtout liee aux exces momentanes de charge sur les passerelles, qui peuvent
entra^ner un temps de transfert inconsiderement long, voire l'omission de quelques
paquets.

5.8.4 Con guration d'une passerelle


Con gurer une machine pour qu'elle puisse echanger des paquets entre deux reseaux
Ethernet est extr^emement simple. Considerons que nous sommes revenus sur kro, qui
est equipee de deux cartes Ethernet, chacune connectee a l'un des deux reseaux. Tout
ce que vous avez a faire se resume a con gurer chaque interface separement, en leur
donnant leur adresse IP respective, et le tour est joue.
Il est tres pratique de rajouter les informations sur ces deux interfaces au chier hosts
comme nous le montrons ci-dessous, a n de pouvoir les appeler aussi par des noms :
172.16.1.1 kro.bibine.com kro kro-if1
172.16.2.1 kro-if2

La serie de commandes a invoquer pour con gurer les deux interfaces devient alors :
# ifconfig eth0 kro-if1
# ifconfig eth1 kro-if2
# route add biere-net
# route add pinard-net

5.8.5 L'interface PLIP


Avec une liaison PLIP pour connecter deux machines, les choses sont un petit peu
di erentes de ce que vous avez vu avec l'Ethernet. PLIP realise ce que l'on appelle
5.8. Con guration des interfaces reseau 73

une liaison point-a-point, car ce type de liaison met en jeu deux h^otes ((( points ))),
par opposition aux grands reseaux.
Prenons un exemple. Admettons que l'un des employes de (( La biere virtuelle )) possede
un ordinateur portable, connecte a kro par PLIP. Le portable s'appelle le e et ne
possede qu'un seul port parallele. A l'amorcage, ce port parallele sera enregistre en
tant que plip1. Pour activer le lien, vous devrez con gurer l'interface plip1 a l'aide des
commandes suivantes 7 :
# ifconfig plip1 leffe pointopoint kro
# route add default gw kro

La premiere commande con gure l'interface, signalant au noyau qu'il s'agit d'une
liaison point-a-point, l'autre c^ote ayant l'adresse de kro. La seconde installe la route
par defaut, utilisant kro comme passerelle. Sur cette derniere, une commande ifcon g
similaire sera necessaire pour activer la liaison (route n'est pas utile ici) :
# ifconfig plip1 kro pointopoint leffe

Ce qui est interessant ici, c'est que l'interface plip1 sur kro n'a pas une adresse IP
separee, mais peut aussi se voir attribuer l'adresse 172.16.1.1 8.
Nous avons donc maintenant con gure le routage du portable vers le reseau des bras-
seurs ; mais il nous faut encore trouver une methode pour router les paquets de n'im-
porte quel h^ote de ce reseau vers le e. Une solution particulierement lourde consiste
a rajouter une route speci que sur chaque h^ote de ce reseau, declarant kro comme
passerelle vers le e :
# route add leffe gw kro

Lorsque l'on est confronte a l'etablissement de routes temporaires comme ici, faire
appel au routage dynamique est une solution nettement meilleure. Pour cela, une me-
thode consiste a employer gated, un demon de routage, que vous devrez installer sur
chaque h^ote du reseau de maniere a distribuer les informations de routage dynami-
quement. Cependant, la meilleure solution est encore proxy ARP (Address Resolution
Protocol, protocole de resolution d'adresses). Avec proxy ARP, kro repond a n'im-
porte quelle requ^ete ARP pour le e en envoyant sa propre adresse Ethernet. Le
resultat est que tous les paquets a destination de le e arriveront en realite a kro, qui
les renverra alors a l'ordinateur portable. Nous reviendrons sur proxy ARP dans la
section (( Checking the ARP Tables )).
Les futures versions des utilitaires reseau pour Linux contiendront un outil nomme
plipcon g, qui permettra de choisir la ligne d'IRQ a utiliser pour le port imprimante.
Plus tard, il pourrait m^eme ^etre remplace par une commande ifcon g plus generale.
7 Notez bien que pointopoint n'est pas une faute typographique ; c'est vraiment le nom de
:
l'option.
8 Par precaution, ne con gurez toutefois de liaisons PLIP, SLIP ou PPP que lorsque vous avez
:
completement initialise les tables de routages pour vos reseaux. Avec certaines anciennes versions de
Linux, votre route reseau pourrait se mettre a pointer sur le lien point-a-point.
74 Chapitre 5. Con guration du reseau TCP/IP
5.8.6 Les interfaces SLIP et PPP
Bien que SLIP et PPP ne soient pas autre chose que de simples liaisons point-a-point
comme les connexions PLIP, il y a beaucoup plus a dire a leur propos. Generalement,
l'etablissement d'une liaison SLIP implique l'appel d'un numero de telephone du site
distant par l'intermediaire d'un modem, et passer la ligne serie en mode SLIP. PPP
s'utilise de la m^eme maniere. Les outils necessaires pour realiser des liaisons SLIP ou
PPP seront decrits dans les chapitres 7 et 8.

5.8.7 L'interface dummy


L'interface dummy (muette) est un peu exotique, neanmoins elle est plut^ot utile. Elle
est surtout destinee aux machines isolees, ou celles dont la seule connexion IP est une
liaison de type SLIP. En fait, ce dernier cas revient au premier, lorsque le systeme
n'est pas connecte.
Le probleme de ces machines isolees est qu'elles n'ont qu'un seul peripherique reseau
actif, l'interface loopback, qui se voit normalement attribuer l'adresse 127.0.0.1. Mais
parfois, il est necessaire d'envoyer des donnees a l'adresse IP (( ocielle )) de cet h^ote
local. Considerons par exemple l'ordinateur portable le e, que nous deconnectons de
tout reseau le temps de cet exemple. Une application fonctionnant sur cette machine
veut envoyer quelque donnee vers un autre programme sur ce m^eme ordinateur. La
recherche de le e dans /etc/hosts renvoie l'adresse 172.16.1.65, par consequent notre
application essaie d'utiliser cette valeur. Comme pour l'instant, la seule interface
active est le loopback, le noyau n'est absolument pas au courant que 172.16.1.65
reference aussi cette machine ! En consequence, il elimine ce datagramme et renvoie
une erreur a l'application.
C'est la que l'interface dummy entre en jeu. Elle permet de resoudre ce probleme en
servant de seconde interface loopback, a laquelle on attribue l'adresse 172.16.1.65.
On ajoute bien entendu une route vers elle, et ainsi chaque datagramme a destination
de 172.16.1.65 sera delivre localement. Les commandes necessaires pour etablir cette
con guration sont :
# ifconfig dummy leffe
# route add leffe

5.9 Tout sur ifcon g


La commande ifcon g possede bien plus de parametres que nous n'en avons utilise
jusqu'a present. Sa syntaxe exacte est :

ifconfig interface [[-net|-host] adresse [parametres]]


5.9. Tout sur ifcon g 75

L'argument interface est bien s^ur le nom de l'interface, et adresse correspond a


l'adresse IP a lui assigner. Ce peut ^etre indi eremment une adresse exprimee en no-
tation sur 4 octets, ou un nom de machine que ifcon g recherchera dans les chiers
/etc/hosts et /etc/networks. Les options -net et -host forcent la commande a consi-
derer l'adresse comme un reseau ou un h^ote, respectivement.
Si ifcon g est invoquee uniquement avec le nom de l'interface, cette commande ache
alors la con guration courante de l'interface en question. Sans aucun parametre, elle
considerera toutes celles qui sont con gurees; une option -a permet de lui faire acher
egalement les interfaces inactives. Sur eth0, la sortie de ifcon g peut donner quelque
chose comme ceci :
# ifconfig eth0
eth0 Link encap 10Mbps Ethernet HWaddr 00:60:8C:53:D3:65
inet addr 193.56.58.85 Bcast 193.56.58.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets 414652 errors 3 dropped 3 overruns 3
TX packets 518279 errors 0 dropped 0 overruns 0

Les champs MTU et Metric montrent respectivement le MTU et la valeur metrique pour
cette interface. La valeur metrique est utilisee par certains systemes d'exploitation
pour determiner le prix ou l'ecacite d'une route. Pour l'instant, Linux n'utilise pas
cette valeur, mais elle est de nie pour des raisons evidentes de compatibilite.
Les lignes RX et TX montrent combien de paquets ont ete recus (RX) ou transmis
(TX) sans erreurs, combien d'erreurs se sont produites, combien de paquets furent
elimines (probablement par manque de memoire), et combien ont ete perdus en raison
de debit trop important. Ces (( overruns )) se produisent generalement lorsque les
paquets arrivent trop rapidement, et que le noyau n'a pas eu le temps de servir la
derniere interruption alors qu'une autre arrive. Les drapeaux aches par ifcon g
correspondent plus ou moins aux noms des options de sa ligne de commande ; nous
allons les expliquer ci-dessous.
Voici la liste des parametres reconnus par la commande ifcon g, avec les noms des
drapeaux correspondants. Les options qui ne sont que des bascules de conditions
particulieres permettent egalement de les supprimer si elles sont precedees du signe
(( moins )) (-).

up Cette option marque l'interface comme etant accessible a la couche


reseau du noyau. Elle est implicite lorsqu'une adresse est donnee sur
la ligne de commandes. Elle peut aussi ^etre utilisee pour remettre en
service une interface qui a ete arr^etee momentanement par l'option
down.
Elle correspond aux drapeaux UP et RUNNING.
down Marque l'interface comme etant inaccessible a la couche IP du noyau.
Cela interdit tout tra c IP a travers l'interface. Notez que cette op-
tion ne supprime pas les entrees de la table de routage pouvant utiliser
76 Chapitre 5. Con guration du reseau TCP/IP
cette interface. Si vous decidez de mettre une interface hors service
de facon permanente, vous devrez egalement supprimer tout routage
passant par elle et, si possible, o rir une alternative pour l'achemi-
nement des datagrammes.
netmask masque
Assigne le masque de sous-reseau a utiliser pour cette interface. Il
peut ^etre donne soit par un nombre hexadecimal sur 32 bits precede
de 0x (comme en langage C), soit en notation traditionnelle sur 4
octets.
pointopoint adresse
Cette option est utilisee pour les liaisons point-a-point qui ne mettent
en jeu que deux machines. Elle est necessaire pour con gurer, par
exemple, des interfaces SLIP ou PLIP.
Si une adresse point-a-point est initialisee, la commande ifcon g af-
chera alors le drapeau POINTOPOINT.
broadcast adresse
L'adresse de di usion est generalement constituee a partir de la va-
leur reseau en mettant tous les bits de la partie h^ote a 1. Quelques
implementations de IP (notamment les systemes derives de BSD 4.2)
utilisent un schema di erent, ou la partie h^ote est mise a zero). L'op-
tion broadcast est la, entre autres, pour s'adapter a ces environne-
ments etranges.
Si une adresse de di usion est positionnee, ifcon g achera le dra-
peau BROADCAST.
metric nombre
Option employee pour assigner une valeur metrique a l'entree de la
table de routage creee pour cette interface. Cette valeur est utilisee
par RIP (Routing Information Protocol) pour construire les tables
de routage pour le reseau 9. La valeur metrique mise par defaut par
ifcon g est zero. Si vous n'employez pas de demon RIP, vous n'aurez
pas besoin de cette option ; si vous le faites, vous n'aurez que tres
rarement besoin de changer cette valeur.
mtu octets Permet d'ajuster la taille de l'unite de transfert ((( Maximum Trans-
mission Unit ))), qui correspond au nombre maximum d'octets que
l'interface est capable de manipuler en une seule transaction. Pour
9 RIP choisit la route optimale vers un h^ote donne en se basant sur la (( longueur )) du chemin
:
a parcourir. Elle est calculee en ajoutant toutes les valeurs metriques individuelles de chaque liaison
entre les machines rencontrees. Par defaut, un saut ((( hop ))) a une valeur de 1, mais ce peut ^etre
n'importe quelle valeur entiere inferieure a 16 (une route egale a 16 est consideree comme in nie, et
inutilisable). Le parametre metric permet d'ajuster cette valeur, qui est alors di usee par le demon
de routage.
5.10. La commande netstat 77

l'Ethernet, la valeur par defaut est 1 500 ; pour les interfaces SLIP
c'est 296.
arp Il s'agit d'une option speci que aux reseaux comme l'Ethernet ou le
packet-radio. Elle met en service le protocole de resolution d'adresses,
ARP, a n de detecter les adresses physiques des machines attachees
au reseau. Pour les reseaux cites, elle est toujours en service par
defaut.
Si ARP est hors service, ifcon g achera le drapeau NOARP.
-arp Supprime l'utilisation de ARP sur cette interface.
promisc Passe l'interface en mode global (promiscuous mode). Sur un reseau
Ethernet (par exemple), cela a pour e et de faire recevoir tous les
paquets a l'interface, qu'ils soient destines a un autre h^ote ou non. On
peut ainsi analyser le tra c sur le reseau a l'aide de ltres de paquets
ou autres outils. Generalement, cette technique appelee (( Ethernet
snooping )) est une bonne methode pour traquer certains problemes
reseau quasi indetectables autrement.
D'un autre c^ote, elle permet aux personnes malintentionnees de son-
der ce qui passe sur le reseau, a la recherche de mots de passe ou
pour realiser d'autres actions illegales. Pour se proteger, une solution
consiste a ne laisser personne connecter impunement sa machine sur
votre reseau Ethernet. Une autre option est d'utiliser des protocoles
d'authenti cation securises, comme Kerberos, ou le login SRA 10 .
Cette option correspond au drapeau PROMISC.
-promisc Annule le mode global.
allmulti Les adresses multicast sont un genre d'adresses de di usion limitees
a un groupe de machines qui n'ont pas necessairement besoin de se
trouver sur le m^eme sous-reseau. Elles sont supportees sous Linux a
partir du noyau version 1.1.72, en alpha-test.
Cette option correspond au drapeau ALLMULTI.
-allmulti Invalide les adresses multicast.

5.10 La commande netstat


Tournons-nous maintenant vers un outil presque indispensable pour tester la con gu-
ration et l'activite du reseau: la commande netstat, qui est en fait une collection de
plusieurs outils rassembles en un seul. Nous allons en detailler chaque fonction.
10 L'ensemle SRA peut ^etre obtenu sur ftp.tamu.edu dans le repertoire /pub/sec/TAMU.
:
78 Chapitre 5. Con guration du reseau TCP/IP
5.10.1 Achage de la table de routage
Invoquee avec l'option -r, netstat ache la table de routage du noyau sous la m^eme
forme que la commande route que nous avons deja vue. Sur la machine gueuze, cela
nous donne :

# netstat -nr
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.1 * 255.255.255.255 UH 1 0 50 lo
172.16.1.0 * 255.255.255.0 U 1 0 478 eth0
172.16.2.0 172.16.1.1 255.255.255.0 UGN 1 0 250 eth0

L'option -n indique a netstat d'acher les adresses IP selon la notation sur 4 octets
plut^ot que d'indiquer les noms symboliques des h^otes et des reseaux. C'est particulie-
rement utile lorsque l'on veut eviter des recherches de noms a travers le reseau (via
un serveur DNS ou NIS).
La seconde colonne montre la passerelle vers laquelle pointe l'entree de la table. Si au-
cune passerelle n'est utilisee, un asterisque est ache a la place. La troisieme colonne
indique la (( generalite )) de la route. Lorsqu'on lui demande de trouver une route pour
une certaine adresse IP, le noyau regarde toutes les entrees de la table de routage,
faisant un ET bit a bit de l'adresse et de ce masque avant de la comparer a la cible
de cette route.
La quatrieme colonne indique les di erents drapeaux qui caracterisent cette route :

G La route utilise une passerelle (gateway).


U L'interface est en service (up).
H On ne peut joindre qu'un simple h^ote par cette route. C'est pas
exemple le cas pour l'entree loopback 127.0.0.1.
D Ce drapeau est positionne si l'entree de la table a ete generee par un
message ICMP de redirection (voir la section 2.5).
M Positionne si l'entree de la table a ete modi ee par un message ICMP
de redirection.

La colonne Ref de la sortie de netstat montre le nombre de references a cette route,


c'est-a-dire combien d'autres routes (par des passerelles par exemple) necessitent sa
presence. Les deux dernieres colonnes indiquent le nombre de fois ou cette entree a
ete utilisee, et l'interface a laquelle les datagrammes sont envoyes.
5.10. La commande netstat 79

5.10.2 Achage des statistiques sur une interface


L'option -i de netstat permet l'achage des statistiques des interfaces reseau actuel-
lement con gurees. Si l'on y rajoute l'option -a, ce seront toutes les interfaces qui
seront indiquees, et non plus seulement celles actuellement en service. Sur gueuze,
la sortie de netstat nous donne ceci :
$ netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags
lo 0 0 3185 0 0 0 3185 0 0 0 BLRU
eth0 1500 0 972633 17 20 120 628711 217 0 0 BRU

Les champs MTU et Met montrent le MTU et la valeur metrique courants pour
cette interface. Les colonnes RX et TX indiquent combien de paquets ont ete recus
(RX-OK) ou emis (TX-OK) sans erreurs, avec erreurs (RX-ERR/TX-ERR), combien
furent elimines (RX-DRP/TX-DRP) et combien furent perdus en raison de debit trop
haut pour le noyau (RX-OVR/TX-OVR).
La derniere colonne indique quels drapeaux sont positionnes. Ce sont les initiales des
noms qui sont aches lorsque vous demandez l'etat de la con guration de l'interface
par la commande ifcon g.
B Une adresse de di usion est positionnee.
L Cette interface est un peripherique loopback.
M Tous les paquets sont recus (mode global).
O ARP est hors service.
P Il s'agit d'une connexion point-a-point.
R L'interface est en fonctionnement.
U L'interface est en service.

5.10.3 Achage des connexions


La commande netstat supporte un ensemble d'options permettant de visualiser les
sockets actives ou passives. Ce sont les options -t, -u, -w et -x qui montrent respec-
tivement les connexions TCP, UDP, RAW, et UNIX. Si vous ajoutez -a, les sockets
en attente de connexion (a l'ecoute d'un port par exemple) sont egalement achees.
Vous aurez ainsi une liste de tous les serveurs qui sont actuellement en service sur
votre systeme.
Le resultat de netstat -ta sur kro est :
80 Chapitre 5. Con guration du reseau TCP/IP
$ netstat -ta
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (State)
tcp 0 0 *:domain *:* LISTEN
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 kro:smtp gueuze:1040 ESTABLISHED
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 localhost:1046 gamay:telnet ESTABLISHED
tcp 0 0 *:chargen *:* LISTEN
tcp 0 0 *:daytime *:* LISTEN
tcp 0 0 *:discard *:* LISTEN
tcp 0 0 *:echo *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:login *:* LISTEN

Nous voyons que la plupart des serveurs sont simplement en attente de connexion.
Toutefois, la quatrieme ligne indique une connexion SMTP en cours depuis gueuze,
et la sixieme nous apprend qu'il existe une connexion telnet sortante vers la machine
gamay 11 .
L'emploi de l'option -a seule achera toutes les sockets de toutes les categories.

5.11 Test des tables ARP


Il est des occasions ou il peut ^etre utile de visualiser, voire de modi er le contenu
des tables ARP du noyau, par exemple si vous suspectez qu'une adresse Internet
dupliquee est la cause de problemes reseaux intermittents. L'outil arp est destine a
de telles situations. Sa syntaxe est la suivante :
arp [-v] [-t materiel] -a [nom-de-machine]
arp [-v] [-t materiel] -s nom-de-machine materiel
arp [-v] -d nom-de-machine [nom-de-machine: : : ]

Tous les arguments nom-de-machine peuvent ^etre soit des noms d'h^otes en clair, soit
des adresses IP en notation sur 4 octets.
La premiere invocation ache les entrees ARP pour les adresses IP ou h^otes speci es,
ou tous les h^otes connus si aucun nom-de-machine n'est donne. Par exemple, sur kro,
nous pourrions obtenir :
# arp -a
IP address HW type HW address

11 Vous pouvez savoir si une connexion est sortante ou entrante a partir des ports mis en jeu. Le
:
numero de port ache sur l'h^ote appelant sera toujours un simple entier, alors que sur la machine
appelee, un service connu sera actif, pour lequel netstat utilisera le nom symbolique trouve dans le
chier /etc/services.
5.11. Test des tables ARP 81

172.16.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1


172.16.1.2 10Mbps Ethernet 00:00:C0:90:B3:42
172.16.2.4 10Mbps Ethernet 00:00:C0:04:69:AA

Ce qui montre les adresses Ethernet de kro, gueuze et trappiste.


Avec l'option -t, vous pouvez limiter l'achage au type de materiel speci e. Ce
peut ^etre ether, ax25 ou pronet, correspondant respectivement a l'Ethernet 10 Mbps,
AMPR AX.25 et les equipements token ring IEEE 802.5.
L'option -s sert a ajouter de facon permanente l'adresse Ethernet de nom-de-machine
dans les tables ARP. L'argument materiel speci e l'adresse materielle, qui est par
defaut une adresse Ethernet sous la forme de six nombres hexadecimaux separes
par le signe (( : )). Vous pouvez aussi initialiser l'adresse materielle d'autres types
d'equipement, gr^ace a l'option -t.
Vous pouvez avoir a ajouter manuellement une adresse IP a la table ARP si pour une
raison quelconque, les requ^etes ARP vers la machine distante echouent ; par exemple
si son pilote ARP est bogue ou s'il existe une autre machine sur le reseau qui, suite
a une erreur de con guration, possede la m^eme adresse IP. Forcer manuellement les
adresses IP dans la table ARP est aussi une methode (plut^ot violente) pour se proteger
des h^otes de votre reseau qui tenteraient de se faire passer pour d'autres.
Appeler arp avec l'option -d a pour e et de supprimer toutes les entrees ARP rela-
tives a l'h^ote concerne. Ce peut ^etre un moyen de forcer l'interface a faire une nouvelle
tentative d'obtention de l'adresse Ethernet pour l'adresse IP en question. Cette fonc-
tion est tres utile lorsqu'une machine mal con guree a di use une information ARP
erronee (bien s^ur, vous devrez corriger la con guration de ce systeme avant).
L'option -s peut aussi servir a implementer proxy ARP. Il s'agit d'une technique
speciale ou un h^ote, appelons-le relais, agit comme une passerelle vers un autre h^ote
que nous nommerons truc en pretendant que les deux adresses se referent au m^eme
h^ote, relais. Il e ectue cela en di usant une entree ARP pour truc qui pointe sur
sa propre interface Ethernet. Du coup, lorsqu'une machine enverra une requ^ete ARP
pour truc, relais retournera une reponse contenant sa propre adresse Ethernet. La
machine demandeuse enverra alors tous les datagrammes vers relais, qui les passera
gentiment a truc, l'autre bout n'y voyant que du feu.
Cette gymnastique peut devenir necessaire quand, par exemple, vous voulez acceder
a truc depuis une machine MS-DOS possedant une implementation completement
defectueuse de TCP, qui ne comprend pas trop bien les methodes de routage. Avec
proxy ARP, cette machine MS-DOS aura l'impression que truc est sur le sous-reseau
local, et n'aura donc pas besoin de savoir comment router des datagrammes a travers
une passerelle.
Proxy ARP est aussi tres utile lorsqu'une machine doit faire passerelle uniquement de
temps en temps, par exemple a travers une liaison telephonique. Dans un precedent
exemple, nous avons rencontre l'ordinateur portable le e, qui etait connecte a kro
par une liaison PLIP, mais seulement de temps a autre. Bien s^ur, cela ne marchera
82 Chapitre 5. Con guration du reseau TCP/IP
que si l'adresse de la machine pour laquelle vous voulez o rir proxy ARP se trouve
sur le m^eme sous-reseau IP que votre passerelle. Par exemple, gueuze pourrait faire
du proxy ARP pour n'importe quel h^ote du sous-reseau des brasseurs (172.16.1.0),
mais ce serait impossible pour une machine sur celui des viticulteurs (172.16.2.0).
La syntaxe a employer pour o rir un service proxy ARP a truc est donnee ci-dessous ;
il est bien entendu que l'adresse Ethernet indiquee doit ^etre celle de relais.
# arp -s truc 00:00:c0:a1:42:e0 pub

Cette entree proxy ARP peut ^etre supprimee par :


# arp -d truc

5.12 L'avenir
Le reseau sous Linux est en perpetuelle evolution. De profonds changements dans le
noyau apporteront une methode de con guration tres souple permettant de con gurer
les peripheriques reseau en cours de route. Par exemple, la commande ifcon g prendra
des arguments qui permettront de choisir l'IRQ et le canal DMA.
La commande route se verra ajouter bient^ot des options supplementaires, comme mtu
pour modi er le MTU d'une route particuliere, qui modi era, pour cette route seule-
ment, le MTU speci e pour l'interface correspondante. Vous utiliserez cette possibilite
pour les routes passant par des passerelles, lorsque la liaison entre la passerelle et la
machine de destination necessite un MTU tres faible.
Par exemple, supposons que la machine alambic soit connectee a kro par une liaison
SLIP. Lors de l'envoi de donnees depuis gueuze vers alambic, la couche reseau de
alambic utilisera des paquets allant jusqu'a 1 500 octets puisqu'ils sont emis sur
l'Ethernet. La liaison SLIP, elle, fonctionne avec un MTU de 296 octets, aussi il
faudrait que le code reseau de kro fragmente ces paquets IP en morceaux plus petits
tenant dans 296 octets. Si, au lieu de cela, vous aviez con gure la route sur gueuze
pour utiliser depuis le debut 296 octets, cette fragmentation relativement co^uteuse
aurait pu ^etre evitee :
# route add alambic gw kro mtu 296

Notez que l'option mtu permet aussi de supprimer selectivement les e ets de la regle
SNARL ((( les sous-reseaux sont locaux ))). Il s'agit de l'option de con guration du
noyau decrite dans le chapitre 3.
En n, consultez les pages de manuel et les documentations de la version de Linux et
des commandes que vous possedez. A l'heure ou nous ecrivons ces lignes, certaines de
ces nouvelles caracteristiques sont deja operationnelles.
83

Chapitre 6
Con guration du serveur de
noms et du resolver
Nous avons vu dans le chapitre 2 que le reseau TCP/IP peut employer di erentes
methodes pour convertir les noms des machines en adresses IP. La plus simple, qui ne
tire aucun parti de la facon dont l'espace de noms est organise, utilise une table stockee
dans le chier /etc/hosts. Elle n'est utilisable que sur de petits reseaux locaux geres
par un seul administrateur, et n'ayant aucun acces au monde exterieur. Le format de
ce chier a ete decrit dans le chapitre 5.
L'autre alternative consiste a utiliser BIND, Berkeley Internet Name Domain, pour la
resolution de noms en adresses. La con guration de BIND peut ^etre un vrai pensum,
mais une fois qu'elle est terminee, les modi cations dans la topologie du reseau de-
viennent aisees. Sous Linux, tout comme dans beaucoup d'autres systemes UNIX, le
service des noms est realise par le programme appele named. Au demarrage, il charge
un ensemble de chiers de reference dans son cache interne et attend les requ^etes en
provenance des machines distantes ou des processus utilisateur locaux. Il y a plusieurs
facons de con gurer BIND, et toutes ne necessitent pas la presence d'un serveur de
noms sur chaque h^ote.
Ce chapitre ne pourra pas faire beaucoup plus que vous donner une esquisse de la
maniere de faire fonctionner un serveur de noms. Si vous comptez employer BIND
dans un environnement plus important qu'un petit reseau local, avec probablement
un lien sur l'Internet, vous devrez acheter un bon livre traitant du sujet, comme (( DNS
and BIND )) de Cricket Liu (voir [AlbitzLiu92]). Pour une documentation a jour, vous
devrez prendre connaissance des informations contenues dans les sources de BIND.
En dehors des pages de manuel et des notes, vous y trouverez un guide complet,
(( BIND Operator's Guide )), ou BOG. Ne vous laissez pas tromper par ce titre : il
s'agit vraiment d'un document tres utile. Il existe egalement un forum Usenet dedie
aux questions relatives au DNS, dont le nom est comp.protocols.tcp-ip.domains.
84 Chapitre 6. Con guration du serveur de noms et du resolver
6.1 La bibliotheque resolver
Le terme (( resolver )) ne designe pas une application particuliere, mais une biblio-
theque de fonctions. Il s'agit d'un ensemble de routines contenues sous Linux dans la
bibliotheque C standard. Les principales sont gethostbyname(2) et gethostbyaddr(2),
qui recherchent toutes les adresses IP appartenant a un nom d'h^ote, et vice versa. Elles
peuvent ^etre con gurees pour ne rechercher l'information que dans le chier hosts, in-
terroger un certain nombre de serveurs de noms, ou utiliser la base de donnees hosts
de NIS (Network Information Service). D'autres applications, comme smail, peuvent
inclure des pilotes pour chacune de ces methodes et leur con guration demande un
soin tout particulier.
Les parties s'occupant du DNS dans le resolver proviennent a l'origine des sources
de BIND, qui contiennent egalement le serveur de noms named que nous detaillerons
plus loin dans ce chapitre. A partir de la version 4.6.8 de la bibliotheque C de Linux,
le code de la derniere version de BIND (4.9 ou plus recent) est inclus en standard.
BIND-4.9 apporte une possibilite nouvelle au resolver, la liste de recherche, que nous
allons decrire. Pour tout le reste, les di erentes versions des bibliotheques devraient
avoir un comportement identique.

6.1.1 Le chier host.conf


Le chier central qui contr^ole le comportement du resolver est host.conf. Il se trouve
dans /etc et indique aux fonctions de la bibliotheque quels services utiliser, et dans
quel ordre.
Dans host.conf, chaque option doit se trouver sur une ligne separee. Les champs
peuvent ^etre delimites par des espaces ou des tabulations. Le signe diese (#) introduit
un commentaire qui s'etend jusqu'a la n de la ligne. Les options disponibles sont :
order Determine l'ordre dans lequel les services vont ^etre sollicites. Les
valeurs valides sont bind pour l'interrogation du serveur de noms,
hosts pour une recherche dans le chier /etc/hosts, et nis pour utiliser
NIS. Tous peuvent ^etre speci es, eventuellement.
multi Prend les arguments on ou o , indiquant si un h^ote cite dans le chier
/etc/hosts est autorise a posseder plusieurs adresses IP, ou non. Cette
option n'a aucun e et sur les requ^etes DNS ou NIS.
nospoof Comme nous l'avons explique dans le chapitre precedent, DNS vous
permet de trouver le nom d'h^ote appartenant a une adresse IP donnee
en utilisant le domaine in-addr.arpa. Les tentatives d'envoi d'un
faux nom sont appelees le (( spoo ng )). Pour se preserver, le resolver
peut ^etre con gure pour tester si l'adresse IP originale est vraiment
associee avec le nom obtenu. Si ce n'est pas le cas, le nom est rejete
6.1. La bibliotheque resolver 85

et une erreur est retournee. Ce comportement est mis en service en


mettant nospoof on.
alert Cette option prend les arguments on ou o . Si elle est en service (on),
toute tentative de spoo ng (voir ci-dessus) sera enregistree dans les
chiers trace du systeme via syslog.
trim Prend en argument un nom de domaine, qui sera elimine des noms
d'h^otes avant la recherche. Tres utile pour les entrees hosts, ou vous
pouvez ne trouver que des noms de machines sans domaine local.
La recherche d'un h^ote comprenant le domaine local verra ce dernier
supprime, permettant ainsi a la recherche dans /etc/hosts d'aboutir.
L'option trim est cumulative, votre h^ote pouvant alors ^etre considere
comme local a plusieurs domaines.
Un exemple d'un tel chier pour la machine kro est fourni dans la gure 6.1 ci-dessous.

# /etc/host.conf
# Nous utilisons named, mais pas NIS (pas encore)
order bind hosts
# Autorise les adresses multiples
multi on
# Prevention des tentatives de spoofing
nospoof on
# Supprime domaine local (pas vraiment necessaire).
trim bibine.com.

Fig. 6.1 - Exemple de chier host.conf.

6.1.2 Variables d'environnement du resolver


La con guration inscrite dans host.conf peut ^etre modi ee par un certain nombre de
variables d'environnement qui sont :
RESOLV HOST CONF
Speci e un chier a lire a la place de /etc/host.conf.
RESOLV SERV ORDER
Remplace l'option order donnee dans host.conf. Les services sont
hosts, bind et nis, separes par une espace, une virgule, un point,
ou un deux-points (:).
RESOLV SPOOF CHECK
Determine les mesures a prendre en cas de spoo ng. Completement
invalide par o . Les valeurs warn et warn o mettent le test de spoo-
86 Chapitre 6. Con guration du serveur de noms et du resolver
ng en service, mais valident ou invalident l'enregistrement dans les
chiers trace, respectivement. Une valeur de * met le test en service,
mais laisse l'enregistrement des traces tel que con gure dans le chier
host.conf.
RESOLV MULTI Les valeurs on ou o sont utilisees pour prendre le dessus sur celles
indiquees a l'option multi dans host.conf.
RESOLV OVERRIDE TRIM DOMAINS
Speci e la liste des domaines a supprimer, remplacant celle donnee
dans host.conf par l'option trim.
RESOLV ADD TRIM DOMAINS
Speci e une liste de domaines a supprimer, qui s'ajoutera a celle
donnee dans host.conf par l'option trim.

6.1.3 Con guration des recherches DNS |resolv.conf


Lorsque vous con gurez le resolver pour qu'il utilise le service BIND pour la recherche
de noms, vous devez aussi lui indiquer quels serveurs de noms il doit utiliser. Il y a
un chier separe destine a cet usage, resolv.conf. S'il n'existe pas, ou s'il est vide, le
resolver considerera que le serveur de noms se trouve sur votre propre machine.
Pour utiliser un serveur de noms sur votre h^ote local, il vous faut le con gurer se-
parement, comme nous le decrirons dans les sections suivantes. Si vous ^etes connecte
a un reseau local et que vous avez la possibilite d'utiliser un serveur de noms deja
existant, cette solution sera toujours a preferer.
L'option la plus importante dans resolv.conf est nameserver, qui indique l'adresse IP
du serveur de noms a contacter. Si vous en speci ez plusieurs, en utilisant cette
option plusieurs fois, ils seront essayes dans l'ordre donne. Par consequent, vous devez
toujours indiquer le plus able en premier. L'implementation courante autorise jusqu'a
trois declarations nameserver dans le chier resolv.conf. Si aucune option nameserver
n'est precisee, le resolver tentera de se connecter sur celui qui est local a la machine.
Deux autres options, domain et search, vous permettent d'employer des raccourcis
pour les h^otes appartenant a votre domaine local. Generalement, pour vous connecter
sur une machine de votre reseau, vous preferez taper un nom simple et court comme
gauss, et laisser le resolver rajouter la partie mathematiques.groucho.edu tout
seul.
C'est le but de l'option domain. Elle vous permet de speci er un domaine par defaut,
qui sera rajoute si le DNS echoue lors de la resolution d'un nom. Par exemple, en
recherchant gauss, il ne trouvera pas (( gauss. )) puisqu'il n'y a aucun domaine de
haut niveau de ce nom. Si on lui indique mathematiques.groucho.edu comme
domaine par defaut, il fera sa requ^ete sur gauss.mathematiques.groucho.edu, qui
cette fois aboutira.
6.1. La bibliotheque resolver 87

Tout cela est tres bien, nous direz-vous ; mais des que l'on sort du Departement
Mathematiques, nous revoila avec ces noms pleinement quali es. Et bien s^ur, vous
voudriez aussi pouvoir utiliser des raccourcis comme quark.physique pour atteindre
les machines dans le domaine du Departement de Physique.
Et c'est ici que la liste de recherche entre en jeu : l'option search permet d'indiquer une
liste de recherche, qui correspond a une generalisation de la declaration domain. La
ou cette derniere n'autorise qu'un seul domaine par defaut, search permet de speci er
toute une liste de domaines, chacun etant essayes jusqu'a ce que la recherche aboutisse.
Cette liste utilise des espaces ou des tabulations comme caractere de separation.
Les declarations domain et search sont mutuellement exclusives, et ne peuvent appa-
ra^tre plus d'une fois. Si aucune d'elles n'est indiquee, le resolver tentera de deviner le
domaine par defaut a partir du nom d'h^ote local, en utilisant l'appel systeme getdo-
mainname(2). Si le nom n'a pas de partie domaine, c'est le domaine racine qui sera
utilise par defaut.
} Si vous decidez de mettre une instruction search dans resolv.conf, vous devez faire
tres attention aux domaines que vous declarez dans la liste. Les bibliotheques resolver
de version anterieure a BIND-4.9 construisaient une liste de recherche par defaut a
partir du nom de domaine, si aucune liste n'etait precisee. Cette liste par defaut etait
constituee du domaine par defaut lui-m^eme, plus tous ses domaines parents, jusqu'a
la racine. Cela a pose quelques problemes car les requ^etes DNS aboutissaient a des
serveurs de noms qui n'auraient jamais d^u ^etre concernes.
Supposons que vous vous trouviez a (( La biere virtuelle )), et que vous vouliez vous
connecter a la machine foot.groucho.edu. Mais, ayant un peu abuse des productions
de cette honorable societe, vos doigts derapent sur le clavier et au lieu de taper foot,
vous mettez foo, qui n'existe pas. Le serveur de noms de GMU vous indiquera donc
qu'il ne conna^t aucun h^ote de ce nom. Avec l'ancienne implementation de la liste
de recherche, le resolver commencerait alors a rajouter bibine.com, puis com au
bout. Ce dernier cas pose un gros probleme car groucho.edu.com pourrait ^etre un
domaine valide. Leur serveur de noms pourrait m^eme trouver une machine foo dans
leur domaine, ce qui n'est pas du tout ce que vous vouliez 1 !
Dans certaines applications, ces recherches boguees peuvent poser des problemes de
securite. Par consequent, vous devez generalement limiter les domaines de votre liste
de recherche a votre organisation locale, ou equivalent. Au Departement de Ma-
thematiques de l'universite Groucho Marx, la liste de recherche serait initialisee a
maths.groucho.edu et groucho.edu.
Si vous trouvez que les domaines par defaut sont un peu diciles a apprehender,
regardez cet exemple de chier resolv.conf pour (( La biere virtuelle )) :
# /etc/resolv.conf
# Notre domaine
domain bibine.com

1 Pour une explication detaillee de ce probleme, consultez le RFC 1535.


:
88 Chapitre 6. Con guration du serveur de noms et du resolver
#
# Nous utilisons kro comme serveur de noms central:
nameserver 172.16.1.1

Lors de la recherche du nom trappiste, le resolver cherchera trappiste, et ne le


trouvant pas, trappiste.bibine.com.

6.1.4 Fiabilite du Resolver


Si vous ^etes connecte sur un reseau local faisant partie d'un reseau plus important,
vous devez absolument utiliser les eventuels serveurs de noms centraux. Ils develop-
peront petit a petit des caches extr^emement bien fournis, puisque toutes les requ^etes
leur seront passees. Toutefois, cette methode a ses failles : lorsqu'un incendie detruisit
un jour le c^able de la dorsale de notre universite, plus aucun travail ne fut possible
sur notre reseau local car aucun resolver ne pouvait plus atteindre aucun serveur de
noms. Il etait impossible d'utiliser les terminaux X, les imprimantes, etc.
Bien que cette situation soit tres rare, il vaut mieux prendre ses precautions contre
les pannes, toujours possibles.
Vous pouvez par exemple installer un serveur de noms local, qui gere les machines
de votre domaine local et renvoie les requ^etes pour tous les autres noms aux ser-
veurs principaux. Bien entendu, cela n'est possible que si vous possedez votre propre
domaine local.
Alternativement, vous pouvez maintenir une sauvegarde des h^otes de votre reseau
dans le chier /etc/hosts. A ce moment-la, vous mettriez dans le chier /etc/host.conf
la ligne (( order bind hosts )) a n que le resolver utilise ce chier hosts en cas de panne
du serveur de noms central.

6.2 Utilisation de named


Le programme qui realise le service de noms sur la plupart des machines UNIX s'ap-
pelle en general named (prononcez naime-de). Il s'agit d'un programme serveur de-
veloppe a l'origine pour BSD, o rant un service de noms aux clients, aussi bien qu'a
d'autres serveurs de noms. La version actuellement utilisee sous Linux semble ^etre
BIND-4.8.3. La nouvelle version, BIND-4.9.3, est encore en b^eta-test a l'heure ou
nous ecrivons ce livre 2 . Elle comporte de nombreuses nouveautes, comme des zones
securisees pour restreindre les transferts a certains h^otes ou reseaux. Consultez la
documentation fournie avec le code source pour plus de details.
A partir de maintenant, nous considerons que vous comprenez et ma^trisez la facon
dont DNS, le Domain Name System, fonctionne. Si tout ce qui va suivre vous para^t
confus, relisez le chapitre 2, qui contient les notions de base necessaires.
2 BIND-4.9 est developpe par Paul Vixie, paul@vix.com.
:
6.2. Utilisation de named 89

Le programme named est en principe lance au demarrage du systeme et fonctionne


continuellement jusqu'a l'arr^et de la machine. Il prend ses informations dans un chier
de con guration nomme /etc/named.boot, ainsi que dans divers autres chiers qui
contiennent des correspondances entre domaines et adresses, et d'autres donnees de
ce type. Ces derniers sont appeles chiers de zone. Le format et la semantique de ces
chiers constituent l'objet de la section suivante.
Pour lancer named, tapez simplement :

# /usr/sbin/named

Aussit^ot, named va lire le chier named.boot et tous les chiers de zone indiques
dedans. Il ecrit son numero de processus dans /var/run/named.pid sous forme ASCII,
telecharge des donnees depuis le serveur primaire si necessaire, puis se met a l'ecoute
du port 53 en attente de requ^etes DNS 3 .

6.2.1 Le chier named.boot


Le chier named.boot est generalement tres petit et ne contient pratiquement que des
pointeurs vers des chiers de reference, dans lesquels se trouvent les informations de
la zone et des pointeurs sur d'autres serveurs de noms. Les commentaires commencent
par un point-virgule et s'etendent jusqu'a la n de la ligne. Avant de detailler le format
de ce chier, regardons un exemple pratique : le chier named.boot de la machine kro,
gure 6.2 4 .

;
; Fichier /etc/named.boot pour la machine kro.bibine.com
;
directory /var/named
;
; domaine fichier
;---------------------------------------------------
cache . named.ca
primary bibine.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 72.191.in-addr.arpa named.rev

Fig. 6.2 - Le chier named.boot de la machine kro.


3 Si vous utilisez une version precompilee, il existe plusieurs binaires de named pour Linux,
:
con gures di eremment. Certains ecrivent leur chier named.pid dans in /etc; d'autres dans /tmp
ou /var/tmp, etc. Il est egalement possible que vous ayez installe le programme ailleurs que dans
/usr/sbin.
4 Notez que les noms de domaines sont indiques sans point nal. D'anciennes versions de named
:
semblent traiter un point nal dans named.boot comme une erreur, et ne tiennent pas compte de la
ligne incriminee, sans le signaler. BIND-4.9.3 corrige ce probleme.
90 Chapitre 6. Con guration du serveur de noms et du resolver
Les commandes cache et primary que l'on peut voir dans cet exemple chargent des
informations dans named. Ces informations sont prises dans les chiers de reference
indiques dans le second argument ; ils representent les RR (resource records) du DNS,
que nous allons voir ci-dessous.
Ici, nous avons con gure named en tant que serveur de noms primaire pour trois
domaines, comme l'indiquent les trois lignes primary de la n du chier. La premiere
de ces lignes, par exemple, indique a named qu'il doit agir comme serveur primaire
pour bibine.com, en prenant les informations de zone dans le chier named.hosts. Le
mot cle directory lui indique que tous les chiers de zone sont situes dans le repertoire
/var/named.
L'entree cache est tres speciale et doit ^etre presente sur pratiquement toutes les ma-
chines comportant un serveur de noms. Sa fonction est double : elle indique a named
de valider son cache et de charger les informations sur les domaines racine depuis
le chier cache speci e (named.ca dans notre exemple). Nous reviendrons sur ces do-
maines racine un peu plus loin.
Voici une liste des options les plus importantes que vous pouvez utiliser dans na-
med.boot :

directory Designe un repertoire dans lequel resident les chiers de zone. Le nom
de ces chiers peut ensuite ^etre indique relativement a ce repertoire.
Il est possible d'avoir plusieurs repertoires en indiquant chaque fois
le mot-cle directory. Selon le standard adopte sous Linux, ce doit ^etre
en principe /var/named.
primary Prend deux arguments, un nom de domaine et un nom de fichier,
declarant le serveur de nom local comme ayant autorite pour le do-
maine indique. En tant que serveur primaire, named charge les infor-
mations de zone depuis le chier de reference speci e.
Generalement, il y aura au moins une entree primary dans chaque
chier named.boot, pour la recherche inverse du reseau 127.0.0.0, qui
correspond au reseau loopback.
secondary Prend comme arguments un nom de domaine, une liste d'adres-
ses, et un nom de fichier. D eclare le serveur de noms local comme
etant le serveur ma^tre secondaire pour le domaine indique.
Un serveur secondaire contient aussi les donnees ayant autorite pour
le domaine, mais il ne les recupere pas dans des chiers ; il essaie de
les telecharger depuis le serveur primaire. L'adresse IP d'au moins un
serveur primaire doit ^etre fournie a named dans la liste d'adresses. Le
serveur de noms local contactera tour a tour chacune d'elles jusqu'a
ce qu'il ait reussi a transferer la base de donnees de la zone, qui sera
alors stockee dans le chier de sauvegarde speci e dans le troisieme
argument. Si aucun des serveurs primaires ne repond, les informations
6.2. Utilisation de named 91

de zone seront chargees depuis cette sauvegarde.


Le programme named tentera alors de remettre a jour ces informa-
tions a intervalles reguliers. Tout cela sera decrit plus loin, avec le
RR de type SOA.
cache Prend un domaine et un nom de fichier en arguments. Ce chier
contient les informations sur les domaines racine, qui est une liste
d'enregistrements pointant vers les serveurs de noms racine. Seuls les
enregistrements NS et A seront reconnus. Le domaine doit ^etre soit
le nom du domaine racine, soit un simple point (.).
Cette information est absolument cruciale pour named : si la ligne
cache n'appara^t pas dans le chier d'amorcage, named ne creera
pas du tout de cache. Les performances seront alors serieusement
degradees et la charge du reseau extr^emement augmentee si le serveur
suivant n'est pas sur le reseau local. De plus, named sera incapable de
joindre les serveurs racine, et par consequent il ne resoudra aucune
adresse, exceptees celles pour lesquelles il a autorite.
forwarders Prend une liste d'adresses en argument. Les adresses IP gurant
dans cette liste designent des serveurs de noms que named peut in-
terroger s'il echoue dans la resolution d'une requ^ete en utilisant son
cache local. Elles sont essayees dans l'ordre indique, jusqu'a ce que
l'un de ces serveurs reponde a la requ^ete.
slave Cette instruction fait du serveur un serveur de noms esclave, c'est-
a-dire qu'il ne fera jamais de recherche recursive par lui-m^eme, mais
les transmettra aux serveurs indiques par forwarders.
Il y a encore deux options que nous ne decrirons pas ici, sortlist et domain. De plus,
il existe deux directives pouvant ^etre utilisees a l'interieur de ces chiers de la base
de donnees : $INCLUDE et $ORIGIN. Elles sont rarement utilisees, aussi nous ne les
decrirons pas non plus.

6.2.2 Les chiers de la base de donnees


Les chiers de reference lus par named, comme named.hosts, possedent toujours un
domaine associe, qui est appele l'origine. Il s'agit du nom de domaine speci e par les
commandes cache et primary. A l'interieur d'un chier de reference, vous ^etes autorise
a indiquer noms de machines et domaines, par rapport a cette origine. Un nom donne
dans un chier de con guration sera considere comme absolu s'il se termine par un
point, sinon il sera compris comme relatif a l'origine. Cette origine peut ^etre elle-m^eme
indiquee par le signe (( @ )) (A commercial).
Les donnees contenues dans un chier de reference sont divisees en enregistrements
appeles resource records, ou RR en abrege. Ils constituent la plus petite unite d'infor-
92 Chapitre 6. Con guration du serveur de noms et du resolver
mation disponible depuis le DNS. Chaque RR a un type. Le type A, par exemple, fait
correspondre un nom d'h^ote a une adresse IP, et un enregistrement de type CNAME
associe un alias a un nom ociel de machine. Par exemple, jetons un il a la gure 6.4,
qui represente le chier named.hosts de l'entreprise (( La biere virtuelle )).
Les resource records des di erents chiers de reference partagent un format commun :
[domaine] [ttl ] [classe] type donn
ees

Les champs sont separes par des espaces ou des tabulations. Une entree peut s'etendre
sur plusieurs lignes s'il y a une parenthese ouvrante avant le premier caractere de saut
de ligne, et si le dernier champ est suivi d'une parenthese fermante. Tout ce qui se
trouve entre un signe point-virgule et le saut de ligne suivant est considere comme un
commentaire et donc ignore.
domaine Il s'agit du nom de domaine auquel s'appliquent les entrees. Si aucun
domaine n'est donne, le RR est considere comme s'appliquant au
domaine du precedent RR.
ttl A n de forcer les resolvers a supprimer l'information au bout d'un
certain temps, chaque RR se voit attribuer une duree de vie maxi-
male, appele time to live, ou ttl. Le champ ttl speci e le temps en
secondes pendant lequel l'information restera valide apres qu'elle a
ete recuperee sur le serveur. Il s'agit d'un nombre decimal comportant
8 chi res au plus.
Si aucune valeur ttl n'est donnee, c'est la valeur du champ minimum
du precedent enregistrement SOA qui sera prise par defaut.
classe Il s'agit d'une classe d'adresses, comme IN pour les adresses IP, HS
pour des objets Hesiod. Pour le reseau TCP/IP, ce sera IN.
S'il n'y a aucun champ classe, c'est la classe du RR precedent qui
sera prise.
type Decrit le type du RR. Les types d'enregistrement les plus courants
sont A, SOA, PTR, et NS. Nous verrons bient^ot a quoi ils correspon-
dent.
donn
ees Contient les donnees associees avec le RR. Le format de ce champ
depend du type de l'enregistrement. Il sera decrit separement, avec
chaque type de RR.

Voici ci-dessous une liste non exhaustive des RR a utiliser dans les chiers de reference.
Il y en a d'autres, que nous ne decrirons pas : ils sont experimentaux et tres peu
employes.
6.2. Utilisation de named 93

SOA SOA signi e (( Start of Authority )) et signale que l'enregistrement qui


suit contient les informations ayant autorite pour ce domaine. Chaque
chier de reference inclus par une instruction primary doit contenir
un enregistrement SOA pour cette zone. Il contient les champs sui-
vants :

origine Il s'agit du nom canonique du serveur de noms pri-


maire pour ce domaine. Il est en general indique de
maniere absolue.
contact L'adresse electronique de la personne responsable
de la maintenance du domaine, mais avec le signe
`@' remplace par un point. Par exemple, si la per-
sonne responsable a (( La biere virtuelle )) est l'uti-
lisateur marcel, alors ce champ contiendra mar-
cel.bibine.com.
num
ero de s
erie
Le numero de version du chier de zone, exprime
sous la forme d'un nombre decimal entier. Chaque
fois que des donnees sont modi ees, ce nombre doit
^etre incremente.
Ce numero de serie est utilise par les serveurs de
noms secondaires pour savoir quand les informations
de zone ont change. Pour rester a jour, les serveurs
secondaires demandent l'enregistrement SOA du pri-
maire a intervalles reguliers et comparent le numero
de serie a celui du SOA se trouvant dans leur cache.
S'il a change, les serveurs secondaires telechargent
alors toute la base de donnees de la zone depuis le
serveur primaire.
rafra^
chissement
Speci e l'intervalle, en secondes, entre les veri ca-
tions periodiques des enregistrements SOA du ser-
veur primaire pour les eventuelles mises a jour. La
encore, il s'agit d'un nombre decimal entier exprime
sur 8 chi res au plus.
Generalement, la topologie du reseau ne change pas
tres souvent, aussi ce nombre doit indiquer approxi-
mativement une journee pour les grands reseaux,
voire davantage pour les plus petits.
tentatives Ce nombre determine les intervalles auxquels un ser-
veur secondaire doit tenter de recontacter le serveur
94 Chapitre 6. Con guration du serveur de noms et du resolver
primaire si une requ^ete ou un rafra^chissement de
zone echoue. Il ne doit pas ^etre trop faible, sinon
une panne momentanee du serveur ou un probleme
reseau peut amener le serveur secondaire a g^acher
inutilement des ressources reseau. On choisit en ge-
neral une heure, ou une demi-heure.
expiration Indique le temps, en secondes, au bout duquel un
serveur secondaire doit eliminer toutes les informa-
tions de zone s'il n'a pas pu contacter le serveur pri-
maire. Normalement, vous devez mettre au moins
une semaine (60 4800 secondes), mais l'augmenter
jusqu'a un mois reste encore raisonnable.
minimum Il s'agit de la valeur ttl par defaut pour les RR qui
n'en contiennent pas explicitement une. Cette valeur
speci e le temps maximal pendant lequel les autres
serveurs de noms doivent conserver le RR dans leur
cache. Il ne s'applique qu'aux requ^etes normales, et
n'a aucun rapport avec le temps au bout duquel un
serveur secondaire doit essayer de mettre a jour les
informations de zone.
Si la topologie de votre reseau ne change pas sou-
vent, une semaine, voir plus, constitue un bon choix.
Si certains RR sont modi es plus frequemment, vous
pourrez toujours leur assigner des valeurs ttl indivi-
duelles. Si, d'un autre c^ote, votre reseau est souvent
modi e, vous pourrez peut-^etre ramener cette valeur
a environ une journee (86 400 secondes).
A Cet enregistrement associe une adresse IP a un nom de machine. Le
champ de donnees contient l'adresse en notation sur 4 octets.
Pour chaque h^ote, il ne doit exister qu'un enregistrement de type A.
Le nom utilise est considere comme le nom ociel, ou nom canonique,
de la machine. Tous les autres noms sont des alias et doivent ^etre
associes au nom canonique par un enregistrement de type CNAME.
NS Les enregistrements NS servent a speci er un serveur primaire de
zone et tous ses serveurs secondaires. Ils pointent vers un serveur de
noms ma^tre de la zone concernee, le champ de donnees contenant le
nom de ce serveur de noms.
Vous rencontrerez des enregistrements NS dans deux situations : lors-
que vous deleguez l'autorite a une zone subordonnee, et dans la base
de donnees de la zone subordonnee elle-m^eme. Les listes de serveurs
speci es dans les zones parent et deleguees doivent correspondre.
6.2. Utilisation de named 95

A n de resoudre le nom vers lequel pointe un enregistrement NS, un


enregistrement A supplementaire peut ^etre necessaire, le fameux glue
record qui donne l'adresse IP du serveur de noms. Les glue records
sont necessaires dans le chier de zone lorsque le serveur pointe est
hors du domaine delegue.
CNAME Cet enregistrement associe un alias au nom canonique d'un h^ote. Le
nom canonique est celui indique par un enregistrement A ; les alias
y sont simplement lies par un CNAME, mais ne possedent pas leur
propre enregistrement.
PTR Ce type d'enregistrement est utilise pour associer les noms dans le
domaine in-addr.arpa avec les noms d'h^otes. Il sert a la recherche
des noms en fonction de l'adresse IP (recherche inverse). Le nom
indique doit ^etre le nom canonique.
MX Cet RR annonce un echangeur de courrier (mail exchanger) pour un
domaine. Le sujet est decrit dans la section (( Mail Routing on the
Internet )), chapitre 13. La syntaxe d'un enregistrement MX est :
[domaine] [ttl] [classe] MX pr
ef
erence h^
ote

L'argument h^ote nomme l'echangeur de courrier pour domaine.


Chaque echangeur est associe a une preference, nombre entier. Un
programme agent de transport de courrier desirant delivrer un mes-
sage a domaine essaiera tous les h^otes qui ont un enregistrement MX
pour ce domaine, jusqu'a ce qu'il aboutisse. Celui dont la valeur de
preference est la plus faible sera essaye en premier, et ainsi de suite.
HINFO Donne des informations sur l'equipement materiel et logiciel de la
machine. Sa syntaxe est :
[domaine] [ttl] [classe] HINFO mat
eriel logiciel

Le champ materiel indique le type d'ordinateur. Plusieurs conven-


tions sont utilisees ; une liste de noms valides est donnee dans (( As-
signed Numbers )), RFC 1340. S'il contient des espaces, il doit ^etre
delimite par des double quotes (" "). Le champ logiciel indique le
systeme d'exploitation utilise. La encore, il faut choisir l'un des noms
reconnus, indiques dans le document RFC 1340.

6.2.3 Redaction des chiers de reference


Les gures 6.3, 6.4, 6.5 et 6.6 donnent des exemples des chiers d'un serveur de noms
de l'entreprise (( La biere virtuelle )), situe sur la machine kro. En raison de la nature
du reseau (un simple reseau local), l'exemple est assez simple. Si vos besoins sont plus
96 Chapitre 6. Con guration du serveur de noms et du resolver
complexes et que vous n'arrivez pas a faire fonctionner named, procurez-vous le livre
DNS and BIND de Cricket Liu et Paul Albitz ([AlbitzLiu92]).
Le chier cache named.ca presente dans la gure 6.3 montre un exemple d'enregis-
trement pour un serveur de noms racine. Un chier cache typique decrit en general
environ une douzaine de serveurs de noms. Vous pouvez obtenir la liste courante des
serveurs de noms pour le domaine racine en employant l'utilitaire nslookup decrit dans
la section suivante 5 .
;
; /var/named/named.ca Fichier cache pour les brasseurs.
; Nous ne sommes pas sur l'Internet, par consequent
; nous n'avons besoin d'aucun serveur racine.
; Pour activer ces enregistrements, supprimez les
; points-virgules qui les mettent en commentaire.
;
; . 99999999 IN NS NS.NIC.DDN.MIL
; NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103
; . 99999999 IN NS NS.NASA.GOV
; NS.NASA.GOV 99999999 IN A 128.102.16.10

Fig. 6.3 - Le chier named.ca.

6.2.4 Veri cation de la con guration du serveur de noms


Pour veri er le fonctionnement d'un serveur de noms, l'outil adapte s'appelle nslookup.
Il peut ^etre utilise aussi bien en ligne de commandes que de maniere interactive. Dans
le premier cas, on le lance simplement par :

nslookup nom-de-machine

Et nslookup interroge alors le serveur de noms declare dans le chier resolv.conf,


a propos de nom-de-machine (Si ce chier contient plusieurs serveurs, nslookup en
choisit un au hasard).
Le mode interactif est bien plus interessant. En plus de pouvoir obtenir des ren-
seignements sur des h^otes individuels, vous pouvez demander n'importe quel type
d'enregistrement DNS et telecharger la totalite des informations de zone pour un
domaine.
Invoque sans arguments, nslookup ache le serveur de noms qu'il utilise et passe en
mode interactif. A l'invite >, vous pouvez alors entrer n'importe quel domaine sur
5 Notez que vous ne pouvez pas interroger votre serveur de noms a propos des serveurs racine si
:
aucun chier d'informations les concernant n'est installe. Pour contourner ce probleme, vous pouvez
soit indiquer un autre serveur de noms a nslookup, soit utiliser l'exemple donne dans la gure 6.3
comme point de depart, puis obtenir ainsi la liste complete des serveurs valides.
6.2. Utilisation de named 97

;
; /var/named/named.hosts H^
otes locaux chez les brasseurs.
; L'origine est bibine.com
;
@ IN SOA kro.bibine.com. marcel.bibine.com. (
16 ; num
ero de s
erie
86400 ; rafra^
chissement une fois par jour
3600 ; tentatives: une heure
3600000 ; expiration: 42 jours
604800 ; minimum: 1 semaine
)
IN NS kro.bibine.com.
;
; le courrier local est distribue sur kro
IN MX 10 kro
;
; adresse loopback
localhost. IN A 127.0.0.1
; Ethernet des brasseurs
kro IN A 172.16.1.1
kro-if1 IN CNAME kro
; kro est aussi un serveur de News Usenet
news IN CNAME kro
gueuze IN A 172.16.1.2
trappiste IN A 172.16.1.3
; Ethernet des viticulteurs
kro-if2 IN A 172.16.2.1
gamay IN A 172.16.2.2
cahors IN A 172.16.2.3
brouilly IN A 172.16.2.4

Fig. 6.4 - Le chier named.hosts.

;
; /var/named/named.local Recherche inverse de 127.0.0
; L'origine est 0.0.127.in-addr.arpa.
;
@ IN SOA kro.bibine.com. alfred.bibine.com. (
1 ; num
ero de s
erie
360000 ; rafra^
chissement: 100 heures
3600 ; tentatives: une heure
3600000 ; expiration: 42 jours
360000 ; minimum: 100 heures
)
IN NS kro.bibine.com.
1 IN PTR localhost.

Fig. 6.5 - Le chier named.local.


98 Chapitre 6. Con guration du serveur de noms et du resolver
;
; /var/named/named.rev Recherche inverse de notre adresse IP
; L'origine est 72.191.in-addr.arpa.
;
@ IN SOA kro.bibine.com. alfred.bibine.com. (
16 ; num
ero de s
erie
86400 ; rafra^
chissement une fois par jour
3600 ; tentatives: une heure
3600000 ; expiration: 42 jours
604800 ; minimum: 1 semaine
)
IN NS kro.bibine.com.
; brewery
1.1 IN PTR kro.bibine.com.
2.1 IN PTR gueuze.bibine.com.
3.1 IN PTR trappiste.bibine.com.
; winery
1.2 IN PTR kror-if1.bibine.com.
2.2 IN PTR gamay.bibine.com.
3.2 IN PTR cahors.bibine.com.
4.2 IN PTR brouilly.bibine.com.

Fig. 6.6 - Le chier named.rev.

lequel vous desirez des renseignements. Par defaut, il demande les enregistrements de
classe A, ceux contenant l'adresse IP relative au nom du domaine.
Vous pouvez changer ce comportement par la commande (( set type=type )) ou type
est l'un des RR decrits plus haut, ou bien (( ANY )), c'est-a-dire tous.
Voici un exemple de session nslookup :
$ nslookup
Default Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

> sunsite.unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

Non-authoritative answer:
Name: sunsite.unc.edu
Address: 152.2.22.81

Si vous recherchez un nom qui n'a pas d'adresse IP associee, mais d'autres enregistre-
ment dans la base de donnees DNS, nslookup retournera le message d'erreur (( No type
A records found )). Toutefois, vous pouvez lui faire querir d'autres enregistrements
que le type A par la commande set type. Par exemple, pour obtenir l'enregistrement
SOA de unc.edu, vous feriez :
6.2. Utilisation de named 99

> unc.edu
*** No address (A) records available for unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

> set type=SOA


> unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60

Non-authoritative answer:
unc.edu
origin = ns.unc.edu
mail addr = shava.ns.unc.edu
serial = 930408
refresh = 28800 (8 hours)
retry = 3600 (1 hour)
expire = 1209600 (14 days)
minimum ttl = 86400 (1 day)

Authoritative answers can be found from:


UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU internet address = 128.109.157.30

Vous pouvez de la m^eme facon obtenir les MX, etc.


> set type=MX
> unc.edu
Non-authoritative answer:
unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu
lambada.oit.unc.edu internet address = 152.2.22.80

Authoritative answers can be found from:


UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU internet address = 128.109.157.30

Demander le type ANY retournera tous les RR associes a un nom donne.


En dehors de la mise au point et du deboguage, nslookup permet d'obtenir la liste
des serveurs de noms racine courants. Vous pouvez l'obtenir en demandant tous les
enregistrements NS associes au domaine racine :
> set typ=NS
> .
Name Server: fb0430.mathematik.th-darmstadt.de
Address: 130.83.2.30

Non-authoritative answer:
(root) nameserver = NS.INTERNIC.NET
(root) nameserver = AOS.ARL.ARMY.MIL
(root) nameserver = C.NYSER.NET
(root) nameserver = TERP.UMD.EDU
(root) nameserver = NS.NASA.GOV
(root) nameserver = NIC.NORDU.NET
100 Chapitre 6. Con guration du serveur de noms et du resolver
(root) nameserver = NS.NIC.DDN.MIL

Authoritative answers can be found from:


(root) nameserver = NS.INTERNIC.NET
(root) nameserver = AOS.ARL.ARMY.MIL
(root) nameserver = C.NYSER.NET
(root) nameserver = TERP.UMD.EDU
(root) nameserver = NS.NASA.GOV
(root) nameserver = NIC.NORDU.NET
(root) nameserver = NS.NIC.DDN.MIL
NS.INTERNIC.NET internet address = 198.41.0.4
AOS.ARL.ARMY.MIL internet address = 128.63.4.82
AOS.ARL.ARMY.MIL internet address = 192.5.25.82
AOS.ARL.ARMY.MIL internet address = 26.3.0.29
C.NYSER.NET internet address = 192.33.4.12
TERP.UMD.EDU internet address = 128.8.10.90
NS.NASA.GOV internet address = 128.102.16.10
NS.NASA.GOV internet address = 192.52.195.10
NS.NASA.GOV internet address = 45.13.10.121
NIC.NORDU.NET internet address = 192.36.148.17
NS.NIC.DDN.MIL internet address = 192.112.36.4

Pour avoir une liste complete des commandes disponibles, dans nslookup, tapez la
commande help.

6.2.5 Autres outils pratiques


Il existe quelques utilitaires pouvant vous aider dans votre t^ache d'administration d'un
serveur de noms ; nous allons en decrire brievement deux. Consultez la documentation
fournie avec ces programmes pour en avoir le mode d'emploi.
Le programme hostcvt est un outil qui vous aidera pour la con guration initiale en
convertissant votre chier /etc/hosts en chiers de reference pour named. Il genere les
deux chiers contenant les enregistrements A et PTR (recherche inverse), et prend
soin des eventuels alias. Bien s^ur, il ne fera pas tout le travail pour vous ; vous devrez
tout de m^eme editer le resultat, ne serait-ce que pour ajuster les di erentes valeurs
de temporisation dans le SOA, ou rajouter des MX, par exemple. Mais il peut malgre
tout vous faire economiser quelques cachets d'aspirine. Ce programme fait partie de
la distribution source de BIND, mais on peut aussi le trouver seul sur quelques sites
di usant Linux.
Apres avoir con gure votre serveur de noms, vous pouvez avoir envie de tester le
resultat. L'outil ideal (et le seul, a notre connaissance), s'appelle dnswalk. Il s'agit d'un
programme en langage perl qui traverse votre base de donnees DNS, a la recherche des
erreurs courantes et en veri ant que les informations sont coherentes. Il a ete di use
sur le forum Usenet comp.sources.misc recemment, et devrait ^etre disponible sur
tous les sites qui archivent ce groupe (ftp.uu.net si vous ne trouvez vraiment pas de
site plus proche de chez vous).
101

Chapitre 7
IP sur ligne serie | SLIP
Les protocoles SLIP et PPP permettent l'acces a l'Internet aux moins fortunes. En
dehors d'un modem et d'une carte serie equipee d'un bon circuit avec tampon FIFO,
aucun equipement supplementaire n'est necessaire. Leur utilisation n'est pas plus
compliquee que celle d'une bo^te aux lettres, et le nombre croissant de fournisseurs de
connectivite IP par telephone rend ce type d'acces abordable pour tout le monde 1 .
Linux supporte aussi bien SLIP que PPP. Ce dernier protocole, dont le pilote est
l'uvre de Michael Callahan et Alfred Longyear, sera decrit dans le chapitre suivant.

7.1 Generalites
Pour utiliser SLIP ou PPP, vous devez con gurer un minimum de reseau comme nous
l'avons decrit auparavant dans cet ouvrage. Vous devez au moins posseder l'interface
loopback et o rir une methode quelconque de resolution de noms. Si vous comptez vous
connecter a l'Internet, vous devrez bien entendu employer le DNS. L'option la plus
simple et neanmoins ecace est de mettre l'adresse d'un serveur de noms accessible
dans votre chier resolv.conf, puis d'ajouter l'option bind dans /etc/host.conf si elle
n'y est pas deja. Le serveur speci e sera alors interroge des que le lien SLIP sera actif.
Plus ce serveur de noms sera proche du lieu ou vous ^etes connecte, plus rapide sera
la reponse.
Cette solution n'est toutefois pas optimale, car toutes les resolutions de noms pas-
seront par votre liaison SLIP/PPP. Si le debit demande vous inquiete, vous pouvez
aussi installer un serveur de noms cache seulement. Il ne gere pas vraiment un do-
maine, mais fonctionne comme un relais pour toutes les requ^etes DNS generees par
votre machine. Son avantage sera le cache, gr^ace auquel les requ^etes n'auront a passer
1 C'est encore loin d'^etre vrai en France.
:
102 Chapitre 7. IP sur ligne serie | SLIP
qu'une seule fois par la liaison serie. Un chier named.boot de serveur cache seulement
ressemble a ceci :
; Fichier named.boot pour serveur de noms cache seulement
directory /var/named

primary 0.0.127.in-addr.arpa db.127.0.0 ; r


eseau loopback
cache . db.cache ; serveurs racine

En plus de ce chier, il vous faudra initialiser db.cache par une liste valide de serveurs
de noms racine ; consultez la n du chapitre 6 pour cela.

7.2 Mode d'emploi de SLIP


Les serveurs proposant une connectivite IP o rent souvent ce service par l'interme-
diaire de comptes utilisateurs speciaux : au lieu d'un banal shell, c'est un programme
ou un script qui est execute lorsque vous entrez dans le systeme ; il passe la liaison se-
rie en mode SLIP et con gure l'interface reseau appropriee. Il vous faut donc e ectuer
les m^emes operations de votre c^ote.
Dans certains systemes d'exploitation, le pilote SLIP est un programme fonctionnant
au niveau utilisateur ; sous Linux il est partie integrante du noyau, ce qui le rend
beaucoup plus rapide. Cela necessite toutefois que la ligne serie soit convertie en mode
SLIP explicitement, ce qui est realise par une discipline de ligne speciale : SLIPDISC.
Le mode d'operation normal du tty est DISC0, qui n'echange des donnees qu'avec les
processus utilisateurs, gr^ace aux fonctions standards read(2) et write(2) et le pilote
SLIP est incapable d'ecrire ou de lire sur ce tty. En mode SLIPDISC, les r^oles sont
inverses : tout processus utilisateur est interdit de lecture ou d'ecriture, et les donnees
du port serie sont directement passees au pilote SLIP.
Ce pilote SLIP conna^t plusieurs variantes du protocole. En dehors du SLIP ordinaire,
il comprend aussi CSLIP, qui e ectue ce que l'on appelle la compression d'en-t^etes
Van Jacobson sur les paquets IP sortants 2, qui ameliore dans de grandes proportions
la vitesse en utilisation interactive. De plus, il existe des versions 6 bits de chacun de
ces protocoles.
La facon la plus simple de passer un port serie en mode SLIP est d'utiliser le pro-
gramme slattach. Considerons que votre modem est branche sur /dev/cua3 et que
vous vous ^etes connecte avec succes sur le serveur SLIP. Vous executerez alors :
# slattach /dev/cua3 &

La discipline de ligne de cua3 basculera en SLIPDISC et le port sera attache a l'une


des interfaces reseau SLIP. S'il s'agit de votre premiere liaison, la ligne sera atta-
2 La compression d'en-t^etes Van Jacobson est decrite dans le RFC 1144.
:
7.2. Mode d'emploi de SLIP 103

chee a l'interface sl0 ; la seconde serait sur sl1, et ainsi de suite. Les noyaux actuels
supportent 4, 8 ou 16 liaisons SLIP simultanees.
L'encapsulation choisie par defaut par slattach est CSLIP. Vous pouvez choisir un
autre mode gr^ace a l'option -p ; pour le mode SLIP normal (sans compression) ce
serait :

# slattach -p slip /dev/cua3 &

D'autres modes sont disponibles : cslip, slip6, cslip6 (pour la version 6 bits),
et adaptive. Ce dernier mode laisse le noyau detecter automatiquement quel type
d'encapsulation SLIP est employe par le site distant.
Vous devez utiliser la m^eme encapsulation a chaque bout. Par exemple, si votre cor-
respondant emploie CSLIP, vous devez le faire aussi, sinon la liaison sera incorrecte.
Les sympt^omes sont en general qu'un ping ne revient pas, et l'autre c^ote de la liaison
peut acher le message d'erreur (( Can't build ICMP header )) sur la console. Il est
possible d'eviter cela en utilisant le mode adaptatif (option adaptive).
Pour tous renseignements, consultez la page de manuel de slattach(8).
Apres avoir passe la ligne en SLIP, vous devez con gurer l'interface reseau. La encore,
il faut utiliser les commandes standards ifcon g et route. Supposons que nous ayons,
a partir de la machine kro, appele un serveur nomme gogoslip. Nous devons taper
les commandes suivantes :
# ifconfig sl0 kro-slip pointopoint gogoslip
# route add gogoslip
# route add default gw gogoslip

La premiere commande con gure l'interface en tant que liaison point-a-point avec
gogoslip, les deux autres ajoutent une route vers cette machine et positionne celle
par defaut a gogoslip tout en l'utilisant comme passerelle.
Il faut noter deux choses a propos de la commande ifcon g montree dans cet exemple.
La premiere, c'est l'option pointopoint qui speci e l'adresse de la machine distante, la
seconde etant l'utilisation de kro-slip comme adresse de l'interface SLIP locale.
Nous avons dit auparavant que l'on pouvait utiliser la m^eme adresse qui est assignee a
l'interface Ethernet de kro pour SLIP. Dans le cas present, kro-slip pourrait tres bien
n'^etre qu'un alias de 172.16.1.1. Toutefois, il peut arriver que l'on soit oblige d'utiliser
une adresse completement di erente pour la liaison SLIP ; c'est le cas par exemple
lorsque le reseau utilise une adresse IP de reseau non enregistree ociellement, comme
cela se passe a (( La biere virtuelle )). Nous reviendrons sur ce sujet en detail dans la
section suivante.
Jusqu'a la n de ce chapitre, nous utiliserons toujours kro-slip pour designer l'adresse
de l'interface SLIP locale.
104 Chapitre 7. IP sur ligne serie | SLIP
A la n de la session, vous devez d'abord supprimer toutes les routes vers gogoslip
par l'option del de la commande route, puis mettre l'interface hors service, et envoyer
le signal HUP a slattach (hangup, deconnexion de ligne). Ensuite, vous couperez la
liaison modem.
# route del default
# route del gogoslip
# ifconfig sl0 down
# kill -HUP 516

7.3 Le probleme des reseaux IP prives


Vous vous souvenez que nous avons dit dans le chapitre 5 que (( La biere virtuelle ))
utilise une adresse reseau qui est reservee uniquement aux usages internes : aucun pa-
quet de ce reseau ne sera route sur l'Internet. Cela signi e que les h^otes de l'entreprise
ne peuvent pas parler a des machines connectees sur l'Internet, car les trames seraient
discretement eliminees par le premier routeur venu.
Pour contourner ce probleme, nous allons con gurer kro comme une sorte de rampe
de lancement permettant d'acceder aux services Internet. Pour le monde exterieur,
elle se presentera comme un h^ote tout a fait normal, avec une adresse IP d^ument
enregistree (probablement assignee par le fournisseur de services). Pour avoir acces a
l'Internet, par exemple a un serveur FTP, les utilisateurs doivent se connecter sur kro
et invoquer le client FTP sur cette machine, de sorte que la connexion paraisse venir
d'un h^ote valide. Pour les autres applications, il peut y avoir des solutions evitant cette
connexion intermediaire. Les utilisateurs de WWW par exemple, peuvent employer
ce que l'on appelle un serveur proxy sur kro, qui fera le relais des requ^etes vers les
serveurs demandes.
C'est une solution assez lourde, bien entendu. Mais, en plus d'avoir elimine la paperas-
serie necessaire a l'enregistrement d'un reseau IP, elle apporte le bene ce de realiser
une con guration rewall tres ecace. Les rewalls sont des h^otes dedies destines a
o rir des acces limites a l'Internet aux utilisateurs d'un reseau local, sans exposer ce
reseau aux attaques exterieures.
Considerons que nos brasseurs se sont vu attribuer pour la session SLIP, l'adresse IP
192.168.5.74. Tout ce que vous aurez a faire pour realiser la con guration decrite ci-
dessus sera d'indiquer cette adresse dans le chier /etc/hosts, en l'appelant kro-slip.
La procedure d'etablissement du lien SLIP reste inchangee.

7.4 Utilisation de dip


Jusqu'ici, tout etait plut^ot simple. Neanmoins, vous souhaiterez sans doute automa-
tiser toutes les etapes de maniere a n'avoir qu'une seule commande a taper pour que
7.4. Utilisation de dip 105

tout se fasse tout seul. C'est le r^ole du programme dip. 3 . La version actuelle, a l'heure
ou nous ecrivons ces lignes, est 3.3.7. Il a ete enormement modi e par un grand nombre
de personnes, aussi il n'est plus possible de parler d'un unique programme dip. Ces
di erentes variantes de developpement aboutiront heureusement un jour a une seule
version de nitive.
Le programme dip o re un petit langage script permettant de dialoguer avec le modem
et le serveur, passer en mode SLIP et con gurer les interfaces. Il est tres primitif et
limite, mais susant dans la plupart des cas. Ce langage changera peut-^etre dans une
future version, plus elaboree.
Pour pouvoir con gurer l'interface SLIP, dip a besoin des privileges root. Il serait
tentant de l'installer setuid a root, pour que tout utilisateur ordinaire puisse appeler
un service SLIP sans qu'il soit necessaire de lui donner l'acces superutilisateur. C'est
pourtant une methode extr^emement dangereuse, car con gurer de mauvaises inter-
faces ou routes par defaut avec dip peut paralyser completement votre reseau. Pis, cela
autoriserait n'importe quel utilisateur a telephoner n'importe ou, entre autres choses.
Aussi, si vous avez vraiment besoin d'autoriser un utilisateur a initialiser lui-m^eme
des liaisons SLIP, la meilleure solution est d'ecrire un petit programme frontal pour
chaque serveur a connecter, qui lui seul realisera l'appel a dip en tant que root avec
les scripts adaptes a chaque cas, en toute securite. 4

7.4.1 Exemple de script


Supposons que l'h^ote avec lequel nous voulons realiser notre connexion SLIP soit
gogoslip, et que nous ayons deja ecrit un script appele gogoslip.dip. Nous appellerons
dip de cette facon :
# dip gogo.dip
DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)
Written by Fred N. van Kempen, MicroWalt Corporation.

connected to gogoslip.mou.com with addr 192.168.5.74


#

Le script correspondant est presente dans la gure 7.1.


Apres s'^etre connecte a gogoslip et avoir mis SLIP en service, dip va se detacher
du terminal et se mettre en arriere-plan. Vous pouvez alors commencer a utiliser
les services reseaux habituels par la liaison SLIP. Pour terminer la session, invoquez
simplement dip avec l'option -k. Cela enverra simplement un signal HUP au processus
indique dans /etc/dip.pid, que dip a cree au demarrage.
# dip -k

3 dip signi e Dialup IP, son auteur est Fred van Kempen.
:
4 Le programme diplogin peut (et doit) ^etre setuid root, egalement. Voyez la n de ce chapitre.
:
106 Chapitre 7. IP sur ligne serie | SLIP

# Exemple de script dip pour appeler gogoslip

# Set local and remote name and address


# Initialise les adresses locale et distante
get $local kro-slip
get $remote gogoslip

port cua3 # choix du port s


erie
speed 38400 # choix de la vitesse
modem HAYES # type de modem
reset # remise 
a z
ero du modem et du tty
flush # nettoie le tampon de r
eception modem

# Pr
eparation de l'appel
send ATQ0V1E1X1\r
wait OK 2
if $errlvl != 0 goto error
dial 41988
if $errlvl != 0 goto error
wait CONNECT 60
if $errlvl != 0 goto error

# Voil
a, nous sommes connect
es
sleep 3
send \r\n\r\n
wait ogin: 10
if $errlvl != 0 goto error
send Skro\n
wait ssword: 5
if $errlvl != 0 goto error
send salut\n
wait running 30
if $errlvl != 0 goto error

# Nous sommes sur le syst


eme distant, qui lance SLIP.
print Connect
e 
a $remote avec l'adresse $rmtip
default # Positionne ce lien comme route par d
efaut
mode SLIP # Et nous passons aussi en mode SLIP.
# Les erreurs arrivent ici:

error:
print La connexion SLIP avec $remote a 
echou
e.

Fig. 7.1 - Un exemple de script pour le programme dip.


7.4. Utilisation de dip 107

Dans le langage de script de dip, les mots cles pre xes par le symbole dollar ($)
denotent les noms de variables. Le programme conna^t un certain nombre de va-
riables prede nies, que nous allons detailler plus loin ; $remote et $local, par exemple,
contiennent les noms des deux machines, respectivement distante et locale, de la liai-
son point-a-point.
Les deux premieres instructions du script sont des commandes get, qui est la methode
par laquelle dip initialise une variable. Ici, la machine locale est kro-slip et la machine
distante gogoslip.
Les cinq instructions suivantes initialisent le terminal et le modem : reset envoie une
commande de remise a zero du modem ; pour les modems compatibles Hayes, il s'agit
de ATZ. La ligne suivante elimine le cas echeant tous les caracteres deja recus par le
modem a n que le dialogue avec le serveur puisse s'etablir proprement. Cette sequence
de dialogue est tres simple : elle appelle le numero 41988, le numero de telephone
de gogoslip, et se connecte sous le compte utilisateur Skro avec le mot de passe
salut. La commande wait indique a dip d'attendre la cha^ne de caracteres donnee
comme premier argument pendant le nombre de secondes indique dans le second.
La condition if imbriquee dans la procedure teste qu'aucune erreur ne s'est produite
pendant l'execution de la commande.
Les dernieres commandes executees sont default, qui assigne la route par defaut a la
liaison SLIP, et mode, qui valide le mode SLIP sur la ligne serie et con gure l'interface
et la table de routage pour vous.

7.4.2 Manuel de reference de dip


Bien que tres utilise, dip n'est pas encore tres bien documente. Nous allons malgre tout
vous donner un resume des principales commandes. Vous pourrez avoir un apercu de
la fonction de chacune d'elles en appelant dip en mode test et en tapant la commande
help. Pour trouver la syntaxe d'une commande, vous pouvez l'entrer sans arguments ;
bien s^ur, cela ne marche pas pour celles qui ne prennent pas d'argument.
$ dip -t
DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)
Written by Fred N. van Kempen, MicroWalt Corporation.

DIP> help
DIP knows about the following commands:

databits default dial echo flush


get goto help if init
mode modem parity print port
reset send sleep speed stopbits
term wait

DIP> echo
Usage: echo on|off
DIP> _
108 Chapitre 7. IP sur ligne serie | SLIP
Tout au long de la section suivante, les exemples qui achent l'invite DIP mon- >

trent comment entrer une commande en mode test et ce qu'elle ache a l'ecran. Les
exemples depourvus de cette invite doivent ^etre consideres comme des extraits de
scripts.

Les commandes modem


Dip o re un certain nombre de commandes permettant la con guration de la ligne
serie et du modem. Certaines parlent d'elles-m^emes, comme port, qui selectionne le
port serie a utiliser, ou speed, databits, stopbits et parity, qui permettent d'initialiser
les parametres courants de la ligne (respectivement vitesse, nombre de bits, bits de
stop, et parite).
La commande modem selectionne un type de modem. Pour l'instant, et pour encore
longtemps sans doute, le seul type supporte est HAYES (majuscules requises). L'indi-
cation du type de modem est obligatoire, sinon dip refusera d'executer les commandes
dial (numerotation) et reset. La commande reset envoie une cha^ne de remise a zero
du modem ; elle depend du type selectionne. Pour les modeles compatibles HAYES,
il s'agit de ATZ.
L'instruction ush peut ^etre utilisee pour (( vidanger )) toutes les reponses (ou les
parasites) que le modem a deja recues. Sinon, un script de dialogue suivant immedia-
tement un reset par exemple pourrait ^etre perturbe s'il lit OK ou d'autres reponses
de commandes precedentes.
La commande init selectionne une cha^ne d'initialisation a envoyer au modem avant
la numerotation. Pour les modems Hayes, il s'agit par defaut de (( ATE0 Q0 V1 X1 )),
qui positionne l'echo des commandes et de longues reponses, et supprime le test de la
presence de la tonalite sur la ligne.
En n, la commande dial envoie la cha^ne d'initialisation au modem et e ectue la
numerotation pour appeler le site distant. La commande de numerotation par defaut
est ATD pour le type Hayes.

echo et term
La commande echo est une aide au deboguage. Dans ce mode, dip ache sur la console
tout ce qu'il envoie au port serie. L'e et peut ^etre annule par echo o .
Vous pouvez aussi quitter momentanement le mode script et passer en mode terminal.
Dans ce mode, vous pouvez utiliser dip comme n'importe quel autre programme de
terminal. Pour le quitter, entrez Ctrl-] (combinaison de touches peu pratique sur un
clavier francais).
7.4. Utilisation de dip 109

La commande get
C'est par elle qu'on initialise les variables. La forme la plus simple est l'assignation
d'une constante, comme nous l'avons fait dans gogoslip.dip. Vous pouvez egalement
demander a l'utilisateur de saisir la donnee, en speci ant le mot cle ask au lieu d'une
valeur :
DIP> get $local ask
Enter the value for $local: _

Une troisieme methode consiste a obtenir la valeur depuis la machine distante. Aussi
bizarre que cela puisse para^tre, c'est tres utile dans certains cas. Beaucoup de serveurs
SLIP ne vous autoriseront pas a utiliser votre propre adresse IP sur cette liaison,
mais vous en assigneront une dynamiquement lorsque vous appellerez, en achant un
message vous informant de la valeur a prendre. Si ce message est de la forme (( Your
address: 192.168.5.74 )), ce qui est courant, alors le bout de code dip suivant saura
la recuperer tout seul :
# fin du dialogue login
wait address: 10
get $locip remote

La commande print
Elle est destinee a acher du texte sur le terminal ou dip a ete lance. N'importe quelle
variable peut ^etre utilisee dans le texte, comme ceci :
DIP> print Utilisation du port $port 
a la vitesse de $speed
Utilisation du port cua3 
a la vitesse de 38400

Noms de variables
Le programme dip ne comprend qu'un ensemble prede ni de variables. Leur nom
commence toujours par le signe dollar ($) et doit ^etre en lettres minuscules.
Les variables $local et $locip contiennent le nom de la machine locale et son adresse IP.
Si l'on initialise le nom d'h^ote, dip stockera le nom canonique dans $local, et mettra
l'adresse correspondante dans $locip. La m^eme chose se passe pour $locip.
Les variables $remote et $rmtip ont la m^eme fonction, pour le nom de la machine
distante et son adresse ; et $mtu contient la valeur du MTU pour la connexion.
Ces cinq variables sont les seules qui peuvent se voir assigner des valeurs directement
par la commande get. Un h^ote, ou toute autre variable, ne peut ^etre initialise que par
les commandes correspondantes, mais peut ^etre utilise dans les instructions print ; ce
sont $modem, $port et $speed.
110 Chapitre 7. IP sur ligne serie | SLIP
Le resultat des commandes executees se trouve dans la variable $errlvl. Une valeur de
0 indique que tout s'est bien passe, une valeur non nulle denote une erreur.

Les commandes if et goto


La commande if est un saut conditionnel, et non pas une implementation complete
du if habituel. Sa syntaxe est :

if variable op
erateur valeur goto 
etiquette

L'expression doit ^etre une simple comparaison entre l'une des variables $errlvl, $locip
et $rmtip ; variable doit ^etre un nombre entier ; l'operateur peut ^etre ==, !=, <, >,
<=, et >=.
La commande goto branche l'execution du script a la ligne suivant l'etiquette indiquee.
Une etiquette doit ^etre le premier mot sur la ligne et doit ^etre suivie immediatement
par le caractere deux-points (:).

send, wait, et sleep


Ces commandes aident a implementer des scripts de dialogue simples : send envoie ses
arguments sur la ligne serie. Il ne supporte pas les variables, mais comprend toutes
les sequences d'echappement du langage C comme \n et \b. Le caractere tilde (~) sert
d'abreviation pour le couple retour-chariot/saut de ligne.
Dans l'autre sens, wait prend un nom en argument et lit tout ce qui arrive du port serie
jusqu'a ce qu'il reconnaisse ce mot, qui ne doit contenir aucun blanc. Vous pouvez
ajouter un temps maximal (en secondes) comme deuxieme argument ; si le mot n'est
pas trouve pendant ce laps de temps, l'analyse s'arr^etera et la variable $errlvl sera
positionnee a la valeur 1.
L'instruction sleep peut ^etre utilisee pour attendre un certain temps, la encore l'in-
tervalle est exprime en secondes.

mode et default
Ces commandes servent a basculer la ligne serie en mode SLIP et a con gurer l'inter-
face.
La commande mode est la derniere que dip doit executer avant de passer en arriere-
plan. A moins qu'une erreur ne se produise, on ne revient pas de cette commande.
La commande mode prend un protocole en argument ; pour l'instant dip ne reconna^t
que SLIP et CSLIP. La version courante de dip ne conna^t pas le mode SLIP adaptatif.
Apres avoir passe la discipline de ligne en SLIP, dip execute ifcon g a n de con gurer
7.5. Utilisation en mode serveur 111

l'interface pour une liaison point-a-point, et appelle route pour positionner la route
vers la machine distante.
Si, de plus, le script execute la commande default avant mode, dip fera aussi pointer
la route par defaut sur cette liaison.

7.5 Utilisation en mode serveur


La con guration de votre client SLIP etait la partie la plus dicile. Faire le contraire,
c'est-a-dire faire fonctionner votre systeme en serveur SLIP, est bien plus simple.
Vous pouvez pour cela utiliser dip en mode serveur, ce qui peut ^etre realise en l'ap-
pelant sous le nom diplogin. Son chier de con guration principal est /etc/diphosts,
qui associe des comptes utilisateurs avec des adresses assignees a chacun. Alterna-
tivement, vous pouvez aussi utiliser sliplogin, un outil derive de BSD qui o re une
con guration beaucoup plus etendue, vous permettant d'executer des shell-scripts a
la connexion et deconnexion de chaque machine. En fait, c'est le programme le plus
adapte pour realiser un serveur SLIP.
Quel que soit votre choix, vous devrez preparer un compte utilisateur par client SLIP
appele a se connecter. Par exemple, supposons que vous voulez o rir un service SLIP
a Marcel Dugenou, a dugenou.beta.org. Vous pourrez creer un compte baptise
dugenou en ajoutant la ligne suivante dans votre chier passwd :
dugenou:*:501:60:Compte SLIP de Marcel Dugenou:/tmp:/usr/sbin/diplogin

Ensuite, il reste bien s^ur a positionner le mot de passe avec la commande passwd.
Maintenant, lorsque dugenou entre sur le systeme, dip se lance en tant que serveur.
Pour veri er si l'utilisateur est autorise a utiliser SLIP, il regardera dans le chier
/etc/diphosts. Ce chier detaille les droits d'acces et les parametres de connexion
pour chaque utilisateur SLIP. L'entree de dugenou pourrait ressembler a ceci :
dugenou::dugenou.beta.org:Marcel Dugenou:SLIP,296

Le premier champ est le nom de l'utilisateur. Le second peut contenir un mot de


passe supplementaire (voir plus bas). Le troisieme est le nom ou l'adresse IP de la
machine appelante. Ensuite vient le champ d'informations, sans aucune signi cation
pour le programme (pas encore, du moins). Le dernier champ decrit les parametres
de connexion. C'est une liste dont le separateur est la virgule, speci ant le protocole
(pour l'instant donc, soit SLIP ou CSLIP), suivi par le MTU.
Lorsque dugenou arrive, diplogin extrait les informations le concernant du chier
diphosts, et si le champ du mot de passe n'est pas vide, il le lui demande. La cha^ne
entree par l'utilisateur est comparee avec celle (en clair, non cryptee) contenue dans
diphosts. Si elles ne correspondent pas, l'utilisateur est refuse.
112 Chapitre 7. IP sur ligne serie | SLIP
Sinon, diplogin passe alors la ligne serie en mode CSLIP ou SLIP et initialise l'interface
et la route. Cette connexion reste etablie jusqu'a ce que l'utilisateur se deconnecte et
que le modem coupe la ligne ; diplogin remettra alors la discipline de ligne normale et
s'arr^etera.
Attention, diplogin necessite les privileges du superutilisateur. Si vous n'utilisez pas
dip avec les permissions setuid root, diplogin devra ^etre une copie separee (et non un
simple lien) a n de pouvoir en toute securite le positionner setuid, sans a ecter dip.
113

Chapitre 8
Le protocole Point-a-Point |
PPP
8.1 Sous les P, le protocole
Tout comme SLIP, PPP est un protocole permettant d'envoyer des datagrammes par
une connexion serie ; mais il est plus complet que le premier. Il autorise chaque partie
a negocier certaines options, comme l'adresse IP et le MTU, et comporte di erentes
methodes d'authenti cation. Chacune de ces possibilites fait l'objet d'un protocole
separe. Ici, nous ne decrirons que brievement ces di erentes (( briques )) qui composent
PPP, pour en savoir plus, nous vous conseillons de lire ses speci cations dans le
RFC 1548, et tous ceux qui y sont relatifs 1 .
La couche la plus basse de PPP s'appelle HDLC, qui est l'abreviation de (( High-Level
Data Link Control )) 2 , qui de nit les trames PPP individuelles et o re un checksum
sur 16 bits. Contrairement a l'encapsulation plus primitive de SLIP, une trame PPP
est capable de contenir des paquets d'autres protocoles que IP, comme Novell IPX ou
Appletalk. PPP realise cela en rajoutant un champ protocole a la trame HDLC de
base qui identi e le type de paquet transfere.
LCP, le protocole de contr^ole de liaison (Link Control Protocol), est utilise par-dessus
HDLC pour la negociation d'options relatives a la liaison, comme le MRU (Maximum
Receive Unit), qui indique la taille de datagramme maximale qu'un c^ote du lien est
capable de recevoir.
Au stade de la con guration, l'authenti cation client est une etape importante dans
l'etablissement de la liaison. Bien que facultative, c'est vraiment un plus pour les
1 Ces documents sont indiques dans la bibliographie presentee a la n de ce livre.
:
2 En fait, HDLC est un protocole bien plus general, de ni par l'ISO (International Standards
:
Organization).
114 Chapitre 8. Le protocole Point-a-Point | PPP
serveurs accessibles sur appel telephonique. Generalement, la machine appelee (le ser-
veur) demande au client de s'identi er en prouvant qu'il conna^t une cle secrete. Si
l'appelant echoue, la connexion se termine immediatement. Sous PPP, l'identi cation
est bidirectionnelle : l'appelant peut aussi demander au serveur de s'identi er. Ces pro-
cedures sont totalement independantes les unes des autres ; il existe deux protocoles
permettant deux types distincts d'authenti cation, que nous decrirons plus loin. Ils
s'appellent PAP (Password Authentication Protocol) et CHAP (Challenge Handshake
Authentication Protocol).
Chaque protocole reseau route par la liaison serie, comme IP, Appletalk, etc., est
con gure dynamiquement par un protocole de contr^ole reseau, (( Network Control
Protocol )), ou NCP. Par exemple, pour envoyer des datagrammes IP, les deux c^otes
de PPP doivent d'abord negocier quelle adresse IP chacun d'eux utilisera. Le protocole
de contr^ole utilise a cet e et est IPCP, le protocole de contr^ole de protocoles Internet,
(( Internet Protocol Control Protocol )).

En plus du transfert de datagrammes IP standard, PPP supporte aussi la compression


Van Jacobson de ces trames IP. Il s'agit d'une technique de reduction des en-t^etes
TCP jusqu'a une taille de 3 octets, egalement utilisee dans CSLIP et que l'on appelle
en principe la compression d'en-t^etes Van Jacobson, ou compression VJ en abrege.
Son emploi peut ^etre negocie au depart par IPCP.

8.2 PPP sous Linux


Sous Linux, PPP est compose de deux parties ; un pilote bas niveau HDLC situe dans
le noyau, et un demon pppd fonctionnant au niveau utilisateur, gerant les di erents
protocoles de contr^ole. Dans la version courante, le petit utilitaire chat est aussi fourni,
qui permet l'etablissement de la liaison en gerant la communication par modem et le
dialogue avec le serveur d'une facon simple mais ecace.
Le pilote PPP inclus dans le noyau est ecrit par Michael Callahan, qui fut rejoint
par Al Longyear. Le demon pppd utilise est une implementation libre supportant
egalement SunOS, 386BSD et quelques autres systemes, realisee au depart par Drew
Perkins et maintenue actuellement par Paul Mackerras; la partie Linux est maintenue
par Alfred Longyear. Le programme chat est l'uvre de Karl Fox 3 .
Comme SLIP, PPP est implemente par une discipline de ligne speciale. Pour utiliser
une ligne serie sous PPP, vous commencez par etablir une connexion modem tradi-
tionnelle, puis basculez la ligne en mode PPP. Dans ce mode, toutes les donnees sont
passees au pilote PPP, qui teste la validite des trames HDLC (chacune comporte un
checksum sur 16 bits), puis les traite. Actuellement, seuls les datagrammes IP sont
3 Karl Fox peut ^etre joint a l'adresse karl@morningstar.com. Al Longyear et Paul Mackerras
:
sont tres pris ; si vous avez des questions concernant PPP il vaut mieux les poser dans le forum
Usenet comp.protocols.ppp ou l'un des groupes Linux, ou encore dans le canal (( Net )) des listes de
di usion Linux.
8.3. Utilisation de pppd 115

supportes, avec la compression VJ en option. Si Linux supporte un jour IPX, le pilote


PPP sera mis a jour pour savoir les gerer aussi.
Le pilote inclus dans le noyau est assiste par pppd, le demon PPP, qui e ectue les
phases d'initialisation et d'authenti cation necessaires avant que tout tra c soit pos-
sible sur la liaison. Le comportement de ce programme peut ^etre ajuste par un certain
nombre d'options. Comme PPP est plut^ot complexe, il est impossible de les expliquer
toutes dans un seul chapitre ; par consequent ce livre ne pourra pas traiter tous les as-
pects de pppd, ce sera juste une introduction. Pour obtenir plus d'informations, consul-
tez les pages de manuel et la documentation fournie avec la distribution source de pppd,
ou vous trouverez l'essentiel de ce qui n'est pas traite dans cet ouvrage. Si vous avez
toujours des problemes, tournez-vous vers le forum Usenet comp.protocols.ppp, ou
vous pourrez dialoguer avec la plupart des gens impliques dans le developpement de
pppd.

8.3 Utilisation de pppd


Pour vous connecter a l'Internet par une liaison PPP, il vous faut une con guration
reseau minimale, c'est-a-dire au moins l'interface loopback et une methode de reso-
lution de noms, tout cela a ete explique dans les precedents chapitres. Pour utiliser
DNS sur une liaision serie, consultez le chapitre 7 qui detaille ce cas particulier.
Comme exemple pratique, nous allons encore une fois considerer que vous ^etes sur la
machine kro. Vous avez deja appele le serveur PPP, que nous appellerons pabo, et
^etes entre sur le systeme sous le compte utilisateur ppp. La machine pabo a deja
lance son pilote PPP. Apres ^etre sorti du programme de communications que vous
avez employe pour appeler le serveur, vous faites alors :
# pppd /dev/cua3 38400 crtscts defaultroute

Cette commande va basculer la ligne serie cua3 en mode PPP et etablir une liaison IP
avec l'h^ote pabo. La vitesse de transfert utilisee sur le port serie sera 38 400 bps.
L'option crtscts valide le contr^ole de ux RTS/CTS, ce qui est indispensable avec des
vitesses superieures a 9 600 bps.
La premiere chose que fait pppd est de negocier plusieurs caracteristiques de la liai-
son par le protocole LCP. Generalement, les options par defaut fonctionneront, nous
n'entrerons donc pas dans les details.
Pour l'instant, nous allons egalement considerer que pabo ne demande aucune iden-
ti cation, et que par consequent la phase de con guration est terminee.
Le programme pppd va alors negocier les adresses IP a utiliser en employant IPCP, le
protocole de contr^ole IP. Puisque nous n'avons speci e aucune adresse particuliere en
appelant pppd dans l'exemple ci-dessus, il va essayer de prendre les adresses obtenues
par le resolver sur les noms de chaque h^ote. Chacun annoncera alors son adresse a
l'autre.
116 Chapitre 8. Le protocole Point-a-Point | PPP
Generalement, ce comportement par defaut est parfait. M^eme si votre machine est
sur un reseau Ethernet, vous pouvez employer la m^eme adresse IP pour les deux
interfaces. Neanmoins, pppd permet d'utiliser une adresse di erente, ou m^eme de
demander a l'autre c^ote de vous en assigner une. Ces options sont decrites dans la
section (( Options de con guration IP )).
Apres la phase de con guration IPCP, pppd va preparer la couche reseau de votre
systeme a l'utilisation d'une liaison PPP. Tout d'abord, il con gure l'interface PPP
comme un lien point-a-point, en prenant ppp0 pour la premiere interface active, ppp1
pour la seconde, et ainsi de suite. Ensuite, il va initialiser une entree dans la table
de routage qui pointe vers l'h^ote connecte a l'autre bout de la liaison. Dans l'exemple
ci-dessus, pppd mettra aussi la route par defaut sur pabo, car nous lui avons passe
l'option defaultroute 4 . Par consequent, tous les datagrammes a destination de ma-
chines hors de votre reseau local seront envoyes a pabo. Il existe di erents autres
schemas de routage rendus possibles par pppd, nous les verrons en detail un peu plus
loin.

8.4 Les chiers d'options


Avant que pppd n'analyse les arguments de sa ligne de commande, il recherche di e-
rents chiers pouvant contenir des options par defaut. Ces chiers peuvent indiquer
n'importe quelle option valide, sur plusieurs lignes si necessaire; les commentaires
sont introduits par le signe diese (#).
Le chier /etc/ppp/options est le premier recherche, a chaque demarrage de pppd.
L'utiliser pour initialiser certaines valeurs par defaut est une bonne idee, car cela evite
aux utilisateurs de forcer certains parametres pouvant compromettre la securite. Par
exemple, pour faire que pppd demande a chaque fois que l'autre c^ote s'identi e (avec
PAP ou CHAP), il sut d'ajouter l'option auth dans ce chier. Elle ne pourra plus
^etre forcee par l'utilisateur, et il devient alors impossible d'etablir une connexion PPP
avec des systemes absents de votre base de donnees d'authenti cation.
L'autre chier d'options, qui est lu apres /etc/ppp/options, s'appelle .ppprc dans le
repertoire personnel de l'utilisateur. Il permet a chacun de speci er ses propres options
par defaut.
Voici un exemple de chier /etc/ppp/options :

# Options globales pour pppd sur kro.bibine.com


auth # demande l'authentification
usehostname # utilise le nom d'h^
ote local pour CHAP
lock # emploie les fichiers de verrouillage style UUCP
domain bibine.com # notre nom de domaine

4 La route par defaut ne sera mise que s'il n'en existe pas deja une.
:
8.5. Appel telephonique par le programme chat 117

Les deux premieres options concernent l'identi cation et seront decrites plus bas.
Le mot cle lock rend pppd compatible avec la methode UUCP pour le verrouillage
des peripheriques. Dans cette convention, chaque processus accedant a un port serie,
disons /dev/cua3, cree un chier nomme LCK..cua3 dans le repertoire spool/uucp
pour signaler que le peripherique est en cours d'utilisation. Cela permet d'eviter que
certains autres programmes tentent d'acceder au port serie au m^eme moment.
L'inter^et de mettre ces options dans le chier de con guration global, c'est qu'elles
ne pourront plus ^etre forcees par quiconque par la suite, o rant ainsi un niveau de
securite raisonnable. Notez que quelques-unes n'obeissent pas a cette regle, la cha^ne
connect par exemple.

8.5 Appel telephonique par le programme chat


Le fait d'^etre oblige d'etablir la connexion manuellement avant de lancer pppd vous
a peut-^etre rebute. A la di erence de dip, pppd ne possede pas son propre langage
script pour l'appel d'un serveur, mais necessite qu'un programme externe quelconque
prenne en charge cette operation. La commande necessaire peut ^etre automatiquement
executee par pppd, si on la lui passe en argument de l'option connect ; il redirigera
alors l'entree et la sortie standard de la commande vers le port serie. Certains utilisent
expect, ecrit par Don Libes. Il comporte un langage tres puissant base sur Tcl et est
etudie exactement pour ce type d'applications.
Le paquetage pppd contient un programme similaire appele chat, qui vous permet de
rediger des scripts de dialogue dans le style UUCP. Il s'agit de sequences de cha^nes
de caracteres que l'on attend du serveur distant, et des reponses que nous devons
envoyer pour chacune d'elles. Nous les appellerons respectivement attente et envoi ;
en voici un exemple typique, extrait d'un script de dialogue :
ogin: dugenou ssword: salut

Ici, chat attendra que le systeme distant nous envoie l'invite de login, et nous lui
repondrons par le nom de l'utilisateur dugenou. Nous n'attendons que la cha^ne
ogin:. Ainsi, que la premi ere lettre soit majuscule ou minuscule, ou remplacee par
un malheureux parasite, sera sans importance. Ensuite, nous attendons que l'on nous
demande le mot de passe (ssword:), et nous envoyons la reponse.
Un script de dialogue n'est pas autre chose. Bien s^ur, pour etablir la communication,
il faut egalement y inclure les commandes necessaires au modem. Supposons que
vous disposez d'un modem Hayes (le contraire serait etonnant), et que le numero de
telephone du serveur est 318714. Pour appeler pabo, la commande chat complete est
alors :
$ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN
118 Chapitre 8. Le protocole Point-a-Point | PPP
Par de nition, la premiere cha^ne doit ^etre une attente, mais comme le modem ne
dira jamais rien tant que nous ne lui avons pas adresse la parole, nous indiquons
une cha^ne vide pour que chat n'attende pas inde niment. Nous envoyons ensuite
ATZ, la commande de remise a  zero des modems compatibles Hayes, et attendons sa
reponse (OK). La cha^ne suivante envoie la commande de numerotation et le numero
de telephone, et attend le message CONNECT en reponse. La encore, cette attente est
suivie d'une cha^ne vide car nous ne voulons rien envoyer pour l'instant, il nous faut
attendre l'invite du serveur. La suite de ce script fonctionne exactement comme nous
l'avons decrit plus haut.
L'option -v indique a chat d'enregistrer toutes les activites dans les chiers trace du
systeme, par le demon syslog ; c'est le niveau local2 qui est utilise 5.
Speci er le script de dialogue sur la ligne de commandes presente un certain risque,
car tout utilisateur peut se servir de ps et visualiser cette ligne de commandes. Vous
pouvez eviter ce probleme en mettant ce script dans un chier, disons par exemple
appel-pabo. Il sura d'indiquer a chat, par l'option -f suivie du nom de chier, d'aller
lire le script dedans. Maintenant, l'appel a pppd se passe donc comme ceci :
# pppd connect "chat -f appel-pabo" /dev/cua3 38400 -detach \
crtscts modem defaultroute

En plus de l'option connect qui speci e le script de dialogue, nous avons ajoute deux
autres options a la commande : -detach, qui demande a pppd de ne pas se detacher
de la console et passer en arriere-plan, et le mot cle modem, qui lui permet de gerer
la ligne serie dans le cas particulier d'un modem, par exemple en deconnectant la
ligne apres l'appel. Si vous n'utilisez pas ce mot cle, pppd ne testera pas la ligne DCD
(detection de porteuse) et ne detectera jamais la deconnexion eventuelle de la machine
distante.
Tous ces exemples sont plut^ot simples ; chat permet de faire des scripts bien plus
complexes. Il o re par exemple l'interessante possibilite de pouvoir abandonner la
session en retournant une erreur, en fonction des reponses obtenues. Les messages sur
lesquels on utilisera typiquement cette fonction sont BUSY ou NO CARRIER, que votre
modem indiquera si le numero appele est occupe ou ne repond pas. Pour que chat
reconnaisse immediatement ces messages, vous pouvez les indiquer au debut du script
par le mot cle ABORT :
$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...

De m^eme, vous pouvez changer le temps d'attente maximal de toute partie du dialogue
en inserant l'option TIMEOUT. Consultez la page de manuel de chat(8) pour les details.
Quelquefois, vous aurez aussi besoin de conditions d'execution de certaines parties
du script. Par exemple, lorsque vous ne recevez pas l'invite de la machine appelee,
5 Si vous modi ez syslog.conf pour rediriger ces traces dans un chier, assurez-vous qu'il ne soit
:
pas lisible par tout le monde, car chat enregistre tout le dialogue, tel quel, y compris les mots de
passe.
8.6. Deboguer votre con guration PPP 119

vous pouvez vouloir lui envoyer un BREAK, ou un retour-chariot. C'est realisable


en ajoutant un script secondaire a une attente de cha^ne : il consiste en une serie de
sequences attente/envoi, comme le script principal, mais qui sont separees par des
tirets. Le script secondaire est execute lorsque la cha^ne attendue a laquelle il est
rattache n'est pas recue dans le temps imparti. Nous pourrions modi er l'exemple
precedent de cette facon :
ogin:-BREAK-ogin: ppp ssword: GaGariN

Maintenant, lorsque chat ne recoit pas l'invite login dans le temps prevu, le script
secondaire est execute et envoie un BREAK, puis attend a nouveau. Si l'invite appa-
ra^t, le script continue a se derouler normalement, sinon chat se termine en retournant
une erreur au systeme ou au programme qui l'a appele.

8.6 Deboguer votre con guration PPP


Par defaut, pppd enregistrera tous les messages d'avertissement ou d'erreurs par la
(( facilit
e )) daemon de syslog. Vous devrez ajouter une entree a syslog.conf qui redirigera
ces messages vers un chier ou m^eme la console, sinon syslog les ignorera purement et
simplement. L'entree suivante envoie ces messages dans le chier /var/log/ppp-log :
daemon.* /var/log/ppp-log

Si votre con guration PPP ne marche pas du premier coup, vous pourrez consulter
ce chier de trace pour avoir une idee de ce qui ne va pas. Si vous ne trouvez rien,
il faudra utiliser l'option debug de pppd, pour qu'il ajoute plus d'informations. Cette
option lui fera enregistrer le contenu de tous les paquets de contr^ole envoyes ou recus.
Tous les messages passent par syslog, au niveau daemon.
En n, il est possible de valider le deboguage au niveau du noyau en invoquant pppd
avec l'option kdebug. Celle-ci doit ^etre suivie d'un argument numerique qui est un OU
avec les valeurs suivantes : 1 pour les messages generaux, 2 pour l'enregistrement du
contenu de toutes les trames HDLC entrantes, 4 pour celles sortantes. Pour capturer
les messages de deboguage du noyau, vous devez soit employer une version de syslogd
qui lit aussi le chier /proc/kmsg, soit le demon klogd. Tous deux dirigent les messages
de deboguage du noyau vers la (( facilite )) kernel de syslog.

8.7 Options de con guration IP


IPCP est utilise pour negocier deux parametres IP au moment de la con guration.
Generalement, chaque c^ote envoie un paquet IPCP de requ^ete de con guration, indi-
quant les valeurs qu'il desire au lieu de celles par defaut. Le correspondant examine
chaque option a son tour et acquitte ou rejette la demande.
120 Chapitre 8. Le protocole Point-a-Point | PPP
Avec pppd, vous disposez d'un contr^ole presque total des options IPCP qu'il tentera de
negocier. Vous pouvez les ajuster par di erentes commandes que nous allons presenter
ci-dessous.

8.7.1 Choix des adresses IP


Dans l'exemple ci-dessus, pppd appelait pabo et etablissait une liaison IP. Aucune
precaution n'etait prise quant au choix d'adresses IP particulieres de chaque c^ote de
la liaison. Nous avions simplement pris l'adresse de kro comme adresse IP locale, et
laisse pabo indiquer la sienne. Quelquefois neanmoins, il est necessaire d'avoir un
contr^ole sur les adresses mises en jeu ; pour cela pppd propose plusieurs options.
Pour demander une adresse particuliere, il sut en principe de l'indiquer a pppd par
l'option suivante :

adresse locale:adresse distante

Vous pouvez utiliser pour adresse locale et adresse distante, aussi bien des noms
de machines que des adresses IP en notation sur 4 octets 6 . Avec cette option, pppd
tentera d'utiliser la premiere adresse comme sa propre adresse IP, et la seconde pour
la machine distante. Si cette derniere rejette l'une ou l'autre pendant la negociation
IPCP, aucune liaison IP ne sera etablie 7.
Si vous ne desirez assigner que l'adresse locale et accepter toute adresse distante que
l'autre c^ote annoncera, il vous sut de ne rien mettre a l'emplacement de la variable
adresse distante. Par exemple, pour que kro utilise l'adresse 130.83.4.27 au lieu
de la sienne, vous passeriez l'option 130.83.4.27: sur la ligne de commandes. De
m^eme, pour n'assigner que l'adresse distante, vous laisseriez le champ adresse locale
en blanc. Par defaut, pppd utilisera alors l'adresse associee au nom de la machine.
Certains serveurs PPP gerant beaucoup de connexions assignent les adresses de ma-
niere dynamique : elles sont choisies lorsqu'un systeme se connecte, et liberees a la
deconnexion. Lors de l'appel de tels services, vous devez vous assurer que pppd ne
demande aucune adresse IP particuliere au serveur, mais qu'au contraire il est pr^et a
accepter celles qui lui seront imposees. Cela signi e que vous ne devez pas speci er
d'argument adresse locale, pour le moins. De plus, vous devrez utiliser l'option
noipdefault, qui indique au programme d'attendre que l'autre c^ ote lui indique son
adresse IP au lieu de prendre celle de la machine locale.
6 L'utilisation de noms de machines avec cette option a certaines consequences sur l'authenti -
:
cation CHAP. Consultez la section correspondante dans ce chapitre.
7 Vous pouvez autoriser la machine distante a vous imposer une adresse IP malgre tout
:
par l'option ipcp-accept-local, et vous pouvez accepter l'adresse qu'elle desire pour elle par
ipcp-accept-remote. Consultez la page de manuel pour plus de d etails.
8.7. Options de con guration IP 121

8.7.2 Routage via une liaison PPP


Apres avoir initialise l'interface reseau, pppd positionne generalement une route, uni-
quement vers l'h^ote distant. Si celui-ci est sur un reseau, vous voudrez sans doute
avoir la possibilite de vous connecter a des machines (( derriere )) lui ; c'est-a-dire qu'il
faudra une route vers un reseau.
Nous avons deja vu plus haut que pppd peut ^etre parametre pour positionner une
route par defaut gr^ace a l'option defaultroute, qui est tres utile si le serveur PPP
que vous avez appele est cense ^etre votre passerelle vers l'Internet.
Le cas inverse, ou votre systeme agit comme une passerelle pour un simple h^ote, est
aussi relativement simple a realiser. Prenons par exemple un employe de l'entreprise
(( La biere virtuelle )), dont l'ordinateur domestique s'appelle houblon. Lorsqu'il se
connecte a kro par PPP, il utilise une adresse appartenant au sous-reseau des bras-
seurs. Sur kro, nous pouvons alors passer l'option proxyarp a pppd, qui installera une
entree proxy ARP pour houblon. Cela rendra automatiquement houblon accessible
depuis toutes les machines du reseau des brasseurs, et de celui des viticulteurs.
Toutefois, les choses ne sont pas toujours aussi simples que ca, par exemple lorsque
l'on relie deux reseaux locaux. En principe, cela demande l'ajout d'une route reseau
speci que, car chacun peut avoir sa propre route par defaut. Par-dessus le marche,
si les deux bouts utilisaient le lien PPP comme route par defaut, cela genererait une
boucle, et les paquets a destination inconnue feraient des aller et retour entre chaque
bout de la liaison jusqu'a ce que leur ttl expire.
Comme exemple, supposons que (( La biere virtuelle )) installe une succursale dans une
autre ville. Celle-ci possede un reseau Ethernet qui lui est propre, possedant l'adresse
reseau IP 172.16.3.0, c'est-a-dire le sous-reseau 3 du reseau de classe B des brasseurs.
Cette succursale veut se connecter au reseau principal du siege par PPP pour mettre
a jour leurs chiers clients et les tarifs, etc. La encore, kro joue le r^ole de passerelle ;
son correspondant s'appelle, disons, province et son adresse IP vaut 172.16.3.1.
Lorsque province se connecte a kro, il positionne la route par defaut vers kro, comme
de coutume. Sur la machine kro, toutefois, nous devrons installer une route reseau
pour le sous-reseau 3, qui passera par province. Pour cela, nous allons employer une
possibilite de pppd dont nous n'avons pas encore parle : la commande ip-up. Il s'agit
d'un shell-script ou d'un programme situe dans le repertoire /etc/ppp, qui est execute
apres que l'interface PPP a ete con guree. Lorsque ce chier existe, il est appele
automatiquement par pppd avec les parametres suivants :

ip-up interface p erique vitesse adresse locale adresse distante


eriph

Le parametre interface indique l'interface reseau utilisee, peripherique est le che-


min d'acces au port serie (/dev/tty s'il s'agit de stdin/stdout), et vitesse corres-
pond a la vitesse d'utilisation de ce port serie. Bien entendu, adresse locale et
adresse distante correspondent aux adresses IP de chaque c^ ote de la liaison et sont
122 Chapitre 8. Le protocole Point-a-Point | PPP
exprimees en notation sur 4 octets. Dans notre cas, le script ip-up pourrait contenir,
entre autres lignes de code, celles-ci :
#!/bin/sh
case $5 in
172.16.3.1) # La machine province
route add -net 172.16.3.0 gw 172.16.3.1;
...
esac
exit 0

De la m^eme facon, /etc/ppp/ip-down est appele pour annuler toutes les actions de
ip-up lorsque la liaison est interrompue.
Toutefois, ce schema de routage n'est pas encore complet. Nous avons positionne des
entrees dans la table de routage de chaque h^ote PPP, mais, pour l'instant, aucune
autre machine de l'un ou l'autre des reseaux n'est au courant de cette liaison PPP.
Ce n'est pas un gros probleme si tous les h^otes de la succursale ont leur route par
defaut pointant vers province, et si tous les h^otes du reseau des brasseurs passent
par defaut par kro. Mais si ce n'est pas le cas, la seule solution sera d'employer un
demon de routage comme gated. Apres avoir cree la route reseau sur kro, le demon
de routage di usera cette nouvelle route a toutes les machines connectees aux reseaux
concernes.

8.8 Protocole de contr^ole de liaison


Nous avons deja rencontre LCP, Link Control Protocol, le protocole de contr^ole de
liaison qui permet la negociation des di erents parametres utilises pour notre lien
PPP.
Les deux options les plus importantes qu'il negocie sont le MRU (Maximum Re-
ceive Unit) et ce que l'on appelle communement l'async map, Asynchronous Control
Character Map. Il y a d'autres options de con guration, mais elles sont bien trop
specialisees pour ^etre presentees ici. Consultez le document RFC 1548 pour en avoir
une description detaillee.
L'async map est utilisee sur les liaisons asynchrones comme les lignes telephoniques
pour identi er les caracteres de contr^ole qui doivent ^etre encodes (remplaces par une
sequence speci que de deux caracteres). Par exemple, vous pouvez avoir besoin d'en-
coder les caracteres XON et XOFF utilises pour le contr^ole de ux logiciel si quelque
modem mal con gure est trompe par la reception de XOFF. Parmi les autres bons
candidats, citons Ctrl-] (le caractere d'echappement de telnet). PPP vous permet
d'encoder n'importe quel caractere du code ASCII entre 0 et 31 en le declarant dans
l'async map.
L'async map est un champ de 32 bits, dont le moins signi catif correspond au caractere
ASCII NUL, et le plus signi catif au caractere ASCII 31. Si un bit est mis a 1, il signale
8.8. Protocole de contr^ole de liaison 123

que le caractere correspondant doit ^etre encode avant d'^etre envoye sur la ligne. Par
defaut, l'async map vaut 0xffffffff, c'est-a-dire que tous les caracteres de contr^ole
seront encodes.
Pour indiquer a votre correspondant qu'il n'a besoin d'encoder que quelques caracteres
de contr^ole, vous pouvez speci er une nouvelle async map a pppd gr^ace a l'option
asyncmap. Par exemple, si seulement ^S et ^Q (ASCII 17 et 19, couramment utilis es
pour XON et XOFF) doivent ^etre traites, utilisez l'option suivante :

asyncmap 0x000A0000

Le Maximum Receive Unit, ou MRU, signale au correspondant la taille maximale


des trames HDLC que nous voulons recevoir. Bien que cela puisse vous rappeler la
valeur MTU (Maximum Transfer Unit), il n'y a pas grand rapport. Le MTU est
un parametre de l'interface, au niveau noyau, et indique la taille maximale d'une
trame IP que cette interface peut gerer. Le MRU est tout au plus un avertissement
a la machine correspondante de ne pas generer de trames plus grandes que la valeur
speci ee ; l'interface peut neanmoins ^etre tout a fait capable de recevoir des paquets
allant jusqu'a 1 500 octets.
Choisir un MRU n'est par consequent pas tellement une question de capacite de
transfert, c'est surtout un moyen d'obtenir le meilleur resultat. Si vous comptez utiliser
des applications interactives sur la liaison, baisser le MRU jusqu'a une valeur de 296
est une bonne idee, ainsi un eventuel paquet plus large (provenant d'une session FTP
par exemple) ne (( gelera )) pas momentanement le curseur sur votre ecran. Pour dire a
pppd de demander un MRU de 296, il sut de lui passer l'option mru 296. E tonnant,
non ? Toutefois, de petites valeurs n'ont d'inter^et que si vous n'avez pas supprime la
compression d'en-t^etes VJ (elle est validee par defaut).
Le programme pppd conna^t aussi quelques options permettant de con gurer le com-
portement general de la procedure de negociation, comme le nombre maximal de
requ^etes de con guration qui peuvent ^etre echangees avant d'abandonner tout espoir.
Sauf si vous savez exactement ce que vous faites, ne touchez a rien.
En n, il y a deux options concernant les messages d'echo LCP. Le protocole PPP
de nit deux messages, Echo Request et Echo Response (demande et reponse d'echo).
Le demon pppd utilise cette possibilite pour tester si une liaison est toujours opera-
tionnelle. Vous pouvez la valider par l'option lcp-echo-interval suivie d'une duree
exprimee en secondes. Si aucune trame n'est recue de la machine distante pendant
cet intervalle, pppd va generer une demande d'echo et attendre une reponse. Si rien
n'arrive, la liaison se terminera apres un certain nombre de tentatives, dont le nombre
peut ^etre positionne par l'option lcp-echo-failure. Par defaut, cette possibilite
n'est pas en service.
124 Chapitre 8. Le protocole Point-a-Point | PPP
8.9 La securite sous PPP
Un demon PPP mal con gure peut ouvrir une breche devastatrice dans la securite
de votre systeme. Cela peut revenir a laisser n'importe qui brancher sa machine sur
votre reseau Ethernet (et c'est tres dangereux). Nous allons voir dans cette section
quelques-unes des mesures a prendre pour obtenir une con guration securisee.
Pour que pppd puisse con gurer l'interface reseau et la table de routage, il necessite
les privileges superutilisateur, ce qui pose un probleme. Vous le resoudrez en principe
en mettant le programme setuid a root. Or, pppd permet aux utilisateurs d'initia-
liser di erentes options pouvant avoir trait a la securite. Pour se proteger de toute
attaque en provenance d'un utilisateur, il est fortement conseille d'initialiser quelques
valeurs par defaut dans le chier global /etc/ppp/options, en particulier celles indi-
quees dans l'exemple de la section (( Les chiers d'option )). Quelques unes, comme
les options d'authenti cation, ne peuvent pas ^etre forcees par l'utilisateur, et o rent
alors une protection raisonnable contre les manipulations de personnes maladroites
ou malintentionnees.
Bien entendu, vous devez aussi vous proteger du systeme avec lequel vous vous connec-
tez en PPP. Pour s'a ranchir des h^otes se faisant passer pour d'autres, vous devez
toujours demander une identi cation de la machine. De plus, vous ne devez pas au-
toriser les systemes appelants a utiliser une adresse IP de leur choix, mais leur en
imposer une, ou leur donner le choix entre plusieurs. Nous allons voir tout ca.

8.10 Authenti cation sous PPP


8.10.1 CHAP ou bien PAP ?
Avec PPP, chaque systeme peut demander a son correspondant de s'identi er par l'un
des deux protocoles d'authenti cation. Ce sont PAP (Password Authentication Proto-
col) et CHAP (Challenge Handshake Authentication Protocol). Lorsqu'une connexion
est etablie, chaque c^ote peut demander que l'autre s'identi e, quel que soit l'appelant
ou l'appele. Nous parlerons abusivement de (( client )) et (( serveur )) dans les pages qui
suivent, uniquement dans le but de distinguer plus facilement le systeme identi ant
du systeme identi e, n'y voyez donc qu'une commodite de langage.
Un demon PPP demande l'identi cation en envoyant une requ^ete LCP de con gura-
tion speci ant le protocole desire pour cette operation.
PAP est base sur un systeme similaire aux mots de passe Unix. Le client s'identi e en
envoyant un nom d'utilisateur et un mot de passe (crypte sur option) au serveur, qui
compare alors ces donnees a celles qu'il possede dans sa base de donnees secrete. Cette
technique est vulnerable, certains pouvant obtenir le mot de passe en espionnant la
ligne serie, ou en faisant des essais repetitifs.
8.10. Authenti cation sous PPP 125

CHAP n'a pas ces inconvenients. Avec lui, le serveur desirant l'authenti cation envoie
un (( de )) au client, sous forme d'une cha^ne de caracteres generee aleatoirement, en
m^eme temps que son nom de machine. Le client doit alors utiliser le nom pour trouver
le secret correspondant, le combiner avec la cha^ne, et encrypter la cha^ne par une
fonction de hachage. Le resultat est retourne au serveur avec le nom de machine du
client. Celui-ci e ectue alors les m^emes calculs, et autorise l'acces au client s'il obtient
le m^eme resultat.
Un autre avantage de CHAP est qu'il ne demande pas seulement au client de s'iden-
ti er au debut de la connexion, mais il envoie des de s a intervalles reguliers pendant
la communication pour s'assurer que la machine n'a pas ete remplacee discretement
par un intrus, par exemple en commutant la ligne telephonique.
Le programme pppd conserve les cles secretes pour CHAP et PAP dans deux chiers
distincts, nommes respectivement /etc/ppp/chap-secrets et pap-secrets. En ajoutant
un nom de machine dans l'un ou l'autre de ces chiers, vous pouvez facilement choisir
quels systemes authenti er avec quel protocole.
Par defaut, pppd ne demande aucune authenti cation de la machine distante, mais
sera d'accord pour s'identi er lui-m^eme sur demande. Comme CHAP est plus puissant
que PAP, pppd tentera d'utiliser le premier chaque fois que possible. Si l'autre bout ne
le supporte pas, ou que pppd ne trouve pas de secret CHAP pour le systeme distant
dans son chier chap-secrets, il passera a PAP. S'il ne possede pas de secret PAP
pour son correspondant non plus, il refusera toute authenti cation. En consequence,
la connexion se terminera la.
Ce comportement peut ^etre modi e de di erentes facons. Par exemple, avec le mot
cle auth, pppd demandera a son correspondant de s'authenti er. Il acceptera aussi
bien CHAP que PAP, tant qu'il possede des informations concernant la machine
en question dans ses bases CHAP ou PAP. Il y a d'autres options permettant de
supprimer l'un ou l'autre protocole, mais nous ne les decrirons pas ici ; consultez la
page de manuel de pppd(8) si vous en avez besoin.
Si tous les systemes avec lesquels vous faites du PPP sont d'accord pour s'authenti er
aupres de vous, vous devez mettre l'option auth dans le chier global /etc/ppp/options
et de nir des mots de passe pour chaque systeme dans le chier chap-secrets. Si l'un
d'eux ne supporte pas CHAP, ajoutez son entree dans le chier pap-secrets. Ainsi,
vous serez assure qu'aucun systeme inconnu ne pourra realiser de connexion PPP
chez vous.
Les deux sections suivantes vont traiter des deux chiers secrets, pap-secrets et chap-
secrets. Ils resident dans le repertoire /etc/ppp et contiennent des triplets de clients,
serveurs, et mots de passe, suivis facultativement par une liste d'adresses IP. L'inter-
pretation des champs client et serveur est di erente selon qu'il s'agit de CHAP ou de
PAP, et depend egalement de quel c^ote provient la demande d'authenti cation.
126 Chapitre 8. Le protocole Point-a-Point | PPP
8.10.2 Le chier de secrets CHAP
Lorsqu'il doit s'identi er aupres de quelque serveur utilisant CHAP, pppd cherche
dans le chier chap-secrets une entree dont le champ client est identique au nom de
machine local, et dont le champ serveur est identique au nom de l'h^ote distant recu
dans le de CHAP. Lorsque au contraire, il demande au correspondant de s'identi er,
les r^oles sont simplement inverses: pppd recherchera alors une entree dont le champ
client est identique au nom de la machine distante (envoye dans la reponse client
CHAP), et dont le champ serveur est egal au nom local.
Voici ci-dessous un exemple de chier chap-secrets, pour la machine kro 8 .
# Fichier secrets CHAP de kro.bibine.com
#
# client serveur secret adresses
#----------------------------------------------------------------------
kro.bibine.com pabo.moche.com "Un Linux Sinon Rien" kro.bibine.com
pabo.moche.com kro.bibine.com "horreur, Boudinus" pabo.moche.com
* kro.bibine.com "MotDePasseIdiot" pub.bibine.com

Lors de l'etablissement d'une connexion PPP avec la machine pabo, celle-ci demande
a kro de s'authenti er en envoyant un de CHAP. Alors, pppd cherche une entree dont
le champ client est kro.bibine.com et le champ serveur pabo.bibine.com 9, dans le
chier chap-secrets. Il trouve la premiere ligne du chier, comme nous le voyons dans
l'exemple ; il genere alors la reponse CHAP a partir de la cha^ne de de et du secret
correspondant (Un Linux Sinon Rien), et l'envoie a pabo.
Dans le m^eme temps, pppd compose un de CHAP pour pabo contenant une cha^ne
unique et son nom pleinement quali e kro.bibine.com. La machine pabo construit
alors la reponse comme nous venons de l'expliquer, et l'envoie a kro. Alors, pppd en
extrait le nom du client (pabo.moche.com) et cherche dans le chier chap-secrets
une ligne dans laquelle pabo est client et kro est serveur. La second ligne correspond,
aussi pppd combine-t-il le de CHAP et le secret (horreur, Boudinus), encrypte la
chose, et compare le resultat a la reponse CHAP de pabo.
Les 4 champs optionnels listent les adresses IP qui sont acceptables pour les clients
indiques dans le premier champ. Les adresses peuvent ^etre donnees en notation sur 4
octets, ou sous forme de noms qui seront resolus par le resolver. Par exemple, si pabo
demande, pendant la negociation IPCP, une adresse IP qui n'est pas dans cette liste,
la requ^ete sera rejetee. Dans l'exemple ci-dessus, pabo est par consequent limite a
l'emploi de sa propre adresse IP. Si le champ adresse est vide, n'importe laquelle sera
autorisee ; et la valeur (( - )) interdit toute liaison IP avec ce client.
La troisieme ligne de notre exemple de chier chap-secrets autorise n'importe quelle
machine a etablir une liaison PPP avec kro, car un champ client ou serveur conte-
nant * correspond a n'importe quel nom, il s'agit d'un caractere generique. La seule
8 Les double quotes (" ") ne font pas partie du mot de passe ; ces caracteres sont la pour preserver
:
l'espace contenu dans le mot de passe.
9 Ce nom est recupere dans le de CHAP.
:
8.10. Authenti cation sous PPP 127

condition est que le correspondant connaisse le secret, et utilise l'adresse de la ma-


chine pub.bibine.com. Les entrees contenant des caracteres generiques dans le nom
de machine peuvent appara^tre n'importe ou dans le chier, puisque pppd utilisera
toujours la ligne la plus speci que s'appliquant a un couple client/serveur.
Le demon pppd peut avoir besoin d'un peu d'aide pour les noms d'h^otes. Comme nous
l'avons deja explique, le nom de la machine distante est toujours fourni par celle-ci
dans le de CHAP ou le paquet de reponse. Le nom local sera trouve en appelant la
fonction gethostname(2). Si vous avez initialise le nom du systeme sans le domaine,
donc non quali e, il vous faudra indiquer le domaine a pppd par l'option domain :
# pppd : : : domain bibine.com

Cela lui permettra d'ajouter ce domaine au nom kro, pour toutes les operations
d'identi cation. D'autres options permettent de changer l'idee que se fait pppd du
nom local de la machine : usehostname et name. Lorsque vous donnez l'adresse IP
locale sur la ligne de commande par adresse locale:adresse distante, et que
adresse locale est un nom au lieu d'une adresse IP, pppd l'utilisera comme nom
local. Pour plus de details, consultez la page de manuel de pppd(8).

8.10.3 Le chier de secrets PAP


Le chier de secrets PAP est tres semblable a celui utilise pour CHAP. Les deux
premiers champs contiennent toujours un nom d'utilisateur et de serveur ; le troisieme
contient le secret. Lorsque l'autre c^ote envoie une requ^ete d'authenti cation, pppd
utilise l'entree qui a un champ serveur identique au nom de machine local, et un champ
utilisateur identique a celui qui a ete envoye avec la requ^ete. Lorsqu'il s'identi e lui-
m^eme avec le systeme distant, pppd prend le secret a envoyer dans la ligne dont le
champ utilisateur est identique au nom utilisateur local, et dont le champ serveur est
identique au nom de la machine distante.
Voici un exemple :
# /etc/ppp/pap-secrets
#
# utilisateur serveur secret adresses
kro-pap pabo cassoulet kro.bibine.com
pabo kro DonaldGNUth pabo.moche.com

La premiere ligne est utilisee pour nous identi er lorsque nous communiquons avec
pabo. La seconde decrit comment un utilisateur nomme pabo doit s'identi er aupres
de nous.
Le nom kro-pap, dans la premiere colonne, est le nom d'utilisateur que nous envoyons
a pabo. Par defaut, pppd prendra le nom de machine local comme nom d'utilisateur,
mais vous pouvez aussi indiquer un nom di erent en le passant par l'option user.
128 Chapitre 8. Le protocole Point-a-Point | PPP
Lorsqu'il prend une entree dans le chier pap-secrets pour authenti cation avec le
correspondant, pppd a besoin de conna^tre le nom de la machine distante. Comme il
n'a aucun moyen de le deviner, vous devez lui speci er sur la ligne de commandes par
l'option remotename. Par exemple, pour utiliser l'entree ci-dessus pour une authenti-
cation avec pabo, nous devons rajouter l'option suivante lors de l'appel a pppd :
# pppd ... remotename pabo user kro-pap

Dans le quatrieme champ (et tous les suivants), vous pouvez indiquer quelles adresses
IP sont autorisees pour cette machine particuliere, exactement comme dans le chier
de secrets CHAP. Le correspondant ne pourra alors demander que des adresses faisant
partie de cette liste. Dans notre exemple, nous exigeons que pabo utilise sa propre
adresse IP.
Notez que PAP est une methode d'identi cation plut^ot legere, et il est fortement
conseille d'employer CHAP chaque fois que possible. Par consequent, nous n'entrerons
pas plus dans les details de PAP ici ; si vous en avez besoin vous pourrez trouver les
renseignements qui vous manquent dans le manuel de pppd(8).

8.11 Con guration d'un serveur PPP


Employer pppd en tant que serveur PPP consiste juste a lui passer les bonnes options
sur la ligne de commandes. L'ideal est de creer un compte utilisateur special, disons
ppp, et de lui donner comme shell un script ou un programme invoquant le demon
pppd avec les options adequates. Par exemple, vous pourriez avoir dans /etc/passwd
une ligne ressemblant a celle-ci :
ppp:*:500:200:Compte PPP public:/tmp:/etc/ppp/ppplogin

Bien entendu, vous aurez des valeurs UID et GID di erentes de celles montrees ici
(500 et 200), et il vous faudra positionner le mot de passe avec la commande passwd.
Le script ppplogin pourrait ressembler a celui-ci :
#!/bin/sh
# ppplogin - script pour lancer pppd en serveur
mesg n
stty -echo
exec pppd -detach silent modem crtscts

La commande mesg interdit aux autres utilisateurs d'ecrire sur le tty par la com-
mande write, par exemple. La commande stty, elle, supprime l'echo des caracteres,
a n que ce qu'envoie l'appelant ne lui soit pas retourne en echo. L'option la plus im-
portante est -detach, car elle emp^eche pppd de se detacher du terminal de contr^ole.
Si nous ne mettions pas cette option, il se placerait en arriere-plan, et le script se
8.11. Con guration d'un serveur PPP 129

terminerait, ce qui aurait pour consequence de faire raccrocher la ligne. L'option si-
lent indique au programme d'attendre jusqu'a ce qu'il recoive un paquet du systeme
appelant avant d'en envoyer lui-m^eme. Cela permet d'eviter des problemes avec cer-
tains systemes assez lents a lancer leur client PPP. L'option modem indique qu'il faut
prendre en compte les lignes de contr^ole du modem sur le port serie. Il faut toujours
mettre cette option quand on utilise pppd avec un modem. En n, crtscts valide le
contr^ole de ux materiel.
Parallelement a ces options, il est conseille de forcer une authenti cation quelconque,
par exemple en speci ant auth sur la ligne de commandes ou dans le chier global.
La page de manuel indique aussi des options speci ques permettant de valider ou de
supprimer individuellement chaque protocole d'authenti cation.
130 Chapitre 8. Le protocole Point-a-Point | PPP
131

Chapitre 9
Aspects importants du reseau
Apres avoir reussi a con gurer IP et le resolver, vous allez devoir vous occuper des
services que vous desirez o rir sur le reseau. Ce chapitre traite de la con guration
de quelques applications reseau simples, le serveur inetd et les programmes de la
famille rlogin y compris. L'interface RPC (Remote Procedure Call), qui permet des
services comme NFS (Network File System) ou NIS (Network Information System)
sera egalement rapidement presentee. La con guration de ces deux derniers services,
toutefois, prend beaucoup de place et sera donc traitee dans des chapitres separes,
ainsi que le courrier electronique et les News Usenet.
Bien entendu, il est impossible de decrire toutes les applications reseau possibles dans
ce livre. Si vous devez installer un service qui n'est pas decrit dans cet ouvrage, comme
talk, gopher ou Mosaic, consultez ses pages de manuel pour obtenir les informations
necessaires.

9.1 Le super serveur inetd


Tres souvent, les services reseau sont assures par ce que l'on appelle des demons 1 .
Un demon est un programme qui ouvre un certain port et attend des connexions.
Lorsque cela se produit, il cree un processus ls qui accepte la connexion, pendant
que le processus pere continue a ecouter le port en attente d'autres requ^etes. Ce
principe est la base de tous les services o erts ; un demon doit ^etre en attente de
connexions sur un port donne, ce qui signi e generalement un g^achis de ressources
systeme, memoire ou zone de swap.
1: Demon est une francisation familiere du vocable informatique anglais daemon, qui signi e Disk
And Extension MONitor, c'est-a-dire qui n'est pas invoque manuellement mais attend en arriere-plan
que quelque chose se passe, ou que quelque condition soit remplie. Ce terme fut introduit au depart
sous CTSS (Compatible Time Sharing System), un anc^etre du systeme MULTICS, lui-m^eme parent
d'UNIX. Le traducteur remercie Jon Collins et Steve Pate pour l'etymologie de l'acronyme daemon.
132 Chapitre 9. Aspects importants du reseau
Par consequent, pratiquement toutes les installations UNIX emploient un (( super
serveur )) qui cree des sockets pour un certain nombre de services et les ecoute toutes
en m^eme temps par l'appel systeme select(2). Lorsqu'un h^ote distant demande l'un
de ces services, ce super serveur s'en apercoit et execute le demon speci e pour ce
port.
Le super serveur communement utilise s'appelle inetd, Internet Daemon. Il est lance
lors du demarrage du systeme et prend la liste des services qu'il doit gerer dans
un chier nomme /etc/inetd.conf. En plus de ceux-ci, inetd lui-m^eme o re un certain
nombre de services tres simples, ce sont les services internes. Ils comprennent chargen,
qui genere une simple cha^ne de caracteres a des ns de test et daytime, qui retourne
la date systeme sous forme ASCII.
Une entree de ce chier consiste en une simple ligne composee des champs suivants :
service type protocole wait utilisateur serveur ligne-de-commandes

Voici la signi cation de chacun de ces champs :


service Donne le nom du service. Il doit ^etre traduit en numero de port, en
le recherchant dans le chier /etc/services, qui sera decrit dans la
section (( Les chiers services et protocols )).
type Speci e un type de socket, soit stream (pour les protocoles orientes
connexion) ou dgram (pour les protocoles sans connexion). Les ser-
vices bases sur TCP doivent par consequent toujours utiliser le mot
cle stream, alors que ce sera dgram pour ceux bases sur UDP.
protocol Donne le protocole de transport employe par ce service. Ce doit ^etre
un protocole valide, declare dans le chier protocols, decrit un peu
plus loin.
wait Cette option ne s'applique qu'aux sockets dgram. Ce peut ^etre soit
wait, soit nowait. Dans le cas de wait, inetd n'execute qu'un seul
serveur a la fois pour le port en question. Sinon, il continuera imme-
diatement l'ecoute apres avoir lance le service.
Cette possibilite est tres utile pour les serveurs qui lisent tous les
datagrammes qui arrivent, puis se terminent. La plupart des serveurs
RPC sont de ce type et doivent par consequent ^etre utilises avec le
mot cle wait.
Les sockets stream doivent toujours employer nowait.
utilisateur Il s'agit de l'identi cation utilisateur sous lequel le processus doit ^etre
execute. Ce sera souvent root, le superutilisateur, mais quelques ser-
vices peuvent necessiter di erents comptes. Ici, c'est toujours une
bonne idee d'appliquer le principe des privileges mimimaux, qui de-
clare que vous ne devez pas executer une commande sous un compte
9.1. Le super serveur inetd 133

privilegie si ce n'est pas necessaire pour qu'elle fonctionne correcte-


ment. Par exemple, les serveurs NNTP de News Usenet fonctionne-
ront sous l'utilisateur news, et les services pouvant poser des pro-
blemes de securite (comme tftp ou nger) sont souvent sous l'utilisa-
teur nobody.
serveur Donne le chemin d'acces complet au programme serveur qui doit ^etre
execute. Les services internes sont reperes par le mot cle internal.
ligne-de-commandes
Il s'agit de la ligne de commandes a passer au serveur. Elle inclut
l'argument 0, c'est-a-dire le nom de la commande. Generalement, ce
sera le nom du programme, sauf s'il a un comportement di erent
selon le nom sous lequel il est invoque.
Pour les services internes, ce champ est vide.

#
# services inetd
ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l
telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue
#finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless
login stream tcp nowait root /usr/sbin/rlogind in.rlogind
shell stream tcp nowait root /usr/sbin/rshd in.rshd
exec stream tcp nowait root /usr/sbin/rexecd in.rexecd
#
# services internes 
a inetd
#
daytime stream tcp nowait root internal
daytime dgram udp nowait root internal
time stream tcp nowait root internal
time dgram udp nowait root internal
echo stream tcp nowait root internal
echo dgram udp nowait root internal
discard stream tcp nowait root internal
discard dgram udp nowait root internal
chargen stream tcp nowait root internal
chargen dgram udp nowait root internal

Fig. 9.1 - Un exemple de chier /etc/inetd.conf.


Un exemple de chier inetd.conf est donne dans la gure 9.1. Les services nger et
tftp sont commentes de maniere a les rendre indisponibles. On agit souvent ainsi pour
des raisons de securite, nger peut par exemple ^etre utilise pour obtenir les noms des
utilisateurs de votre systeme.
Le programme tftp implemente le Trivial File Transfer Protocol, qui permet a n'im-
porte qui de transferer n'importe quel chier lisible par tous depuis votre systeme,
134 Chapitre 9. Aspects importants du reseau
sans aucun test de mot de passe. C'est particulierement dangereux pour le chier
/etc/passwd, surtout si vous n'utilisez pas le systeme shadow.
TFTP est utilise par les clients diskless et les terminaux X pour telecharger leur code
depuis un serveur. Si vous devez vraiment utiliser tftpd pour cela, assurez-vous de
limiter sa vision de votre systeme aux repertoires dans lesquels se trouvent les chiers
a prendre, en ajoutant leur nom sur la ligne de commandes de tftpd. Vous pouvez voir
un exemple de cette methode dans la seconde ligne tftp de la gure 9.1.

9.2 Contr^ole d'acces par tcpd


Puisque permettre un acces reseau a un ordinateur implique beaucoup de risques
de violation de securite, les applications sont concues pour prevenir plusieurs types
d'attaques. Malgre tout, rien n'est jamais parfait et certaines protections sont vulne-
rables, ou bien ne distinguent pas les machines ables dont les requ^etes pour un service
particulier sont autorisees, d'h^otes incertains dont les m^emes requ^etes devraient ^etre
rejetees. Nous avons deja entr'apercu plus haut le probleme pose par nger et tftp.
Il serait parfois souhaitable de limiter l'acces a ces services, uniquement aux (( h^otes
de con ance )), ce qui est impossible avec la con guration normale, ou inetd ne sait
qu'o rir un service ou le refuser, pour tout le monde.
Il existe un outil tres pratique pour cela : tcpd 2 , un wrapper 3 de demon. Lorsque
vous voulez tracer ou proteger un service TCP, il est appele a la place du programme
original. Il enregistre la requ^ete via le demon syslog, teste si l'appelant est autorise
a utiliser ce service, et si la reponse est positive, il execute alors le vrai programme
serveur. Notez que cela ne fonctionne pas avec les services UDP.
Par exemple, pour proteger le service nger, vous devez modi er la ligne correspon-
dante dans inetd.conf :
# Encapsule le d
emon finger
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd

Si l'on ne rajoute aucun contr^ole d'acces, rien ne para^tra change sur la machine,
tout fonctionnera comme d'habitude, sauf que toutes les requ^etes seront tracees via
la facilite auth de syslog.
Ce contr^ole d'acces est implemente au moyen de deux chiers appeles /etc/hosts.allow
et /etc/hosts.deny. Ils contiennent des entrees autorisant ou refusant l'acces, respecti-
vement, a certains services et h^otes. Lorsque tcpd gere une requ^ete d'un service comme
nger en provenance d'un client nomme, par exemple, geneur.penible.com, il re-
garde dans hosts.allow et hosts.deny (dans cet ordre) si une entree correspond a la fois
a ce nom et au service demande. S'il la trouve dans hosts.deny, la requ^ete est rejetee
et la connexion immediatement fermee. Si rien n'est trouve, la requ^ete est acceptee.
:2 E crit par Wietse Venema, wietse@wzv.win.tue.nl.
3 Le terme semble consacre, inutile donc de fournir un equivalent francais.
:
9.3. Les chiers services et protocols 135

Les entrees dans le chier d'acces ressemblent a ceci :

services: hotes [:commande ]

services est une liste de noms valides dans /etc/services, ou encore le mot cl e ALL
(tout). Pour designer tous les services sauf nger et tftp, vous pouvez mettre (( ALL
EXCEPT nger, tftp )).
hotes est une liste de noms de machines ou d'adresses IP, ou encore les mots-cl es ALL,
LOCAL ou UNKNOWN (inconnu). ALL indique n'importe quelle machine alors que
LOCAL designe uniquement celles dont le nom ne contient pas de point 4 . UNKNOWN
designe tous les h^otes dont la recherche de nom ou d'adresse a echoue. Un nom
commencant par un point correspond a tous les h^otes dont le domaine est identique a
cette cha^ne. Par exemple, .penible.com designera aussi bien geneur.penible.com
que lourd.penible.com. Il est possible aussi de traiter les adresses IP reseau et
sous-reseau; consultez la page de manuel hosts access(5) pour en savoir plus.
Pour interdire l'acces a nger et tftp a tout le monde sauf aux machines locales, mettez
ce qui suit dans /etc/hosts.deny, et laissez vide le chier /etc/hosts.allow :

in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .votre.domaine

Le champ facultatif commande peut contenir une commande shell a appeler lorsque
l'entree correspond. C'est tres utile pour poser des pieges permettant de mettre en
evidence les eventuels intrus :
in.ftpd: ALL EXCEPT LOCAL, .bibine.com : \
echo "Requete de %d@%h" >> /var/log/finger.log; \
if [ %h != "kro.bibine.com" ]; then \
finger -l @%h >> /var/log/finger.log \
fi

Les arguments %h %d sont traduits par tcpd sous forme du nom de machine e ectuant
la requ^ete et de celui du service, respectivement. La encore, consultez la page de
manuel hosts access(5) pour plus de details.

9.3 Les chiers services et protocols


Les numeros de ports par lesquels certains services (( standard )) sont o erts sont
de nis dans le RFC (( Assigned Numbers )), deja signale. Pour que serveurs et clients
puissent convertir ces noms de services en ports, leur liste (ou au moins une partie)
4: Generalement, seules les machines locales, dont le nom est obtenu par une recherche dans
/etc/hosts n'ont pas de domaine ajoute a leur nom, donc pas de point.
136 Chapitre 9. Aspects importants du reseau

# Le fichier /etc/services:
#
# Services bien connus
echo 7/tcp # Echo
echo 7/udp #
discard 9/tcp sink null # Discard
discard 9/udp sink null #
daytime 13/tcp # Date syst
eme
daytime 13/udp #
chargen 19/tcp ttytst source # G
en
erateur de caract
eres
chargen 19/udp ttytst source #
ftp 21/tcp # File Transfer Protocol
telnet 23/tcp # Virtual Terminal Protocol
smtp 25/tcp # Simple Mail Transfer Protocol
nntp 119/tcp readnews # Network News Transfer Protocol
#
# Services UNIX
exec 512/tcp # BSD rexecd
biff 512/udp comsat # notification du courrier
login 513/tcp # login distant
who 513/udp whod # who and uptime distants
shell 514/tcp cmd # commande distante, sans mot de passe
syslog 514/udp # syslog par r
eseau
printer 515/tcp spooler # spouleur d'imprimante
route 520/udp router routed # protocole RIP

Fig. 9.2 - Exemple de chier /etc/services (extrait).

est maintenue sur chaque machine ; elle se trouve dans un chier dont le nom est
/etc/services. Il comporte des entrees composees ainsi :

service port/protocole [alias]

Ici, service et port de nissent respectivement le nom du service et le port correspon-
dant, et protocole indique quel protocole de transport est utilise. En principe, c'est
soit udp, soit tcp. Il est possible qu'un service soit disponible par plus d'un protocole,
ou bien qu'un m^eme port soit utilise pour plusieurs services, tant que ces protocoles
sont di erents. Le champ alias permet de speci er plusieurs noms pour un m^eme
service.
Generalement, il n'est pas necessaire de modi er le chier services fourni avec la
partie reseau de votre systeme Linux. Neanmoins, vous trouverez un petit extrait de
ce chier dans la gure 9.2.
Par exemple, notez que le service echo est o ert sur le port 7 a la fois pour TCP et
UDP, et que le port 512 sert a deux services di erents : execution distante (rexec(1))
utilisant TCP, et le demon COMSAT, qui indique aux utilisateurs que du nouveau
courrier est arrive, par UDP (voir xbi (1x)).
9.4. RPC : appel de procedure distante 137

#
# Protocoles Internet (IP)
#
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group multicast protocol
tcp 6 TCP # transmission control protocol
udp 17 UDP # user datagram protocol
raw 255 RAW # RAW IP interface

Fig. 9.3 - Exemple de chier /etc/protocols.

Comme pour les services, les fonctions reseau ont besoin d'un moyen de traduire
les noms de protocoles | par exemple, ceux indiques dans le chier services | en
numeros de protocoles compris par la couche IP de toute autre machine. Il existe un
chier pour cela, /etc/protocols. Il contient une entree par ligne, composee du nom
du protocole, et de son numero associe. Vous n'aurez probablement jamais a modi er
ce chier, dont un exemple est donne gure 9.3.

9.4 RPC : appel de procedure distante


RPC, l'ensemble (( Remote Procedure Call )) (appel de procedure distante), fournit un
mecanisme tres general pour la realisation d'applications client-serveur. RPC a ete
developpe par Sun Microsystems et consiste en une collection d'outils et de biblio-
theques de fonctions. Parmi les applications les plus importantes reposant sur RPC,
citons NFS et NIS, que nous presenterons dans de prochains chapitres.
Un serveur RPC est fait d'un ensemble de procedures qu'un client appelle en lui
envoyant une requ^ete RPC, ainsi que les parametres de cette procedure. Le serveur
appellera la fonction pour le client, et lui renverra sa valeur de retour, s'il y en a une.
A n d'^etre independant de l'architecture des machines mises en jeu, toutes les donnees
echangees doivent ^etre converties dans un format universel, chaque ordinateur faisant
la conversion inverse pour les adapter a son format interne lorsqu'il les recoit. Ce
format est appele XDR, soit External Data Representation (representation externe de
donnees).
Parfois, certaines ameliorations d'une application RPC introduisent des modi cations
incompatibles dans l'interface d'appel de procedure. Bien s^ur, changer simplement le
serveur emp^echerait tous les programmes attendant encore le comportement original
de fonctionner. Par consequent, les programmes RPC se voient assigner un numero de
version, generalement a partir de 1, qui est incremente a chaque nouvelle version de
l'interface. Souvent, un serveur peut proposer plusieurs versions simultanement ; les
clients indiquent quelle implementation du service ils desirent utiliser par ce numero
de version dans leurs requ^etes.
138 Chapitre 9. Aspects importants du reseau
La communication reseau entre serveurs et clients RPC est un peu particuliere. Un
serveur RPC o re un ou plusieurs ensembles de procedures ; chacun etant appele un
programme et identi e de maniere unique par un numero de programme. Une liste
contenant la correspondance entre les noms de services et les numeros de programmes
est en principe disponible dans le chier /etc/rpc, dont un extrait est reproduit dans
la gure 9.4.

#
# /etc/rpc - divers services RPC
#
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rstat_svc rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
yppasswdd 100009 yppasswd
bootparam 100026
ypupdated 100028 ypupdate

Fig. 9.4 - Un extrait du chier /etc/rpc.

Sur les reseaux TCP/IP, les auteurs de RPC furent confrontes au probleme de faire
correspondre un service reseau generique aux numeros de programmes. Ils deciderent
que chaque serveur proposerait a la fois un port TCP et UDP pour chaque programme
et chaque version. Generalement, les applications RPC utiliseront UDP pour envoyer
des donnees, et ne prendront TCP que si les donnees a transferer ne tiennent pas dans
un seul datagramme UDP.
Bien s^ur, les clients doivent avoir un moyen de trouver a quel port correspond un
numero de programme donne. Un chier de con guration serait inadapte ; comme les
applications RPC n'utilisent pas de ports reserves, il n'y aurait aucune garantie qu'un
port utilise a l'origine pour notre application de base de donnees n'ait pas ete pris par
quelque autre processus. Par consequent, les applications RPC prennent n'importe
quel port possible et l'enregistrent par le biais du demon portmapper. Il agit comme
un concierge pour tous les serveurs RPC en fonctionnement sur sa machine. Un client
desirant contacter un service avec un numero de programme donne demandera d'abord
au portmapper de la machine serveur, qui lui indiquera les ports TCP et UDP par
lesquels le service peut ^etre atteint.
Cette methode a l'inconvenient d'introduire un point faible, un peu comme le fait
le demon inetd pour les services Berkeley standard. Mais ici, c'est encore pire car
lorsque le portmapper s'arr^ete pour une raison quelconque, toutes les informations
sont perdues ; ce qui signi e que vous devez relancer manuellement chaque serveur,
ou reamorcer completement la machine.
9.5. Con guration des commandes en (( r )) 139

Sous Linux, le portmapper s'appelle rpc.portmap et se trouve dans /usr/sbin. Il ne


demande aucune con guration particuliere, il sut de s'assurer qu'il est bien lance
au demarrage du systeme, par exemple depuis le chier rc.inet2.

9.5 Con guration des commandes en (( r ))


Il existe certaines commandes destinees a executer des programmes sur des machines
distantes. Ce sont rlogin, rsh, rcp, et rcmd. Toutes lancent un shell sur l'h^ote distant
et permettent a l'utilisateur d'executer des commandes. Bien entendu, le client doit
posseder un compte sur la machine en question. Par consequent, toutes ces commandes
passent par une procedure d'authenti cation ; en general le client indique le nom
d'utilisateur au serveur, qui a son tour demande un mot de passe valide par la methode
habituelle.
Quelquefois il est malgre tout necessaire d'assouplir cette procedure d'autorisation
pour certains utilisateurs. Par exemple, si vous devez frequemment vous connecter
sur d'autres machines de votre reseau, vous aimeriez ne pas avoir a taper votre mot
de passe a chaque fois.
Invalider l'authenti cation n'est envisageable uniquement que sur un tout petit nombre
d'h^otes dont les chiers de mots de passe sont synchronises, ou pour quelques utili-
sateurs privilegies qui ont besoin d'acceder a beaucoup de machines pour des raisons
administratives. Chaque fois que vous autorisez des gens a entrer sur votre machine
sans avoir besoin de preciser leur identite ou leur mot de passe, assurez-vous bien que
vous n'o rez pas accidentellement l'acces a d'autres.
Il y a deux facons de supprimer les tests d'identi cation pour ces fameuses commandes
en r. L'une permet au superutilisateur d'autoriser certains utilisateurs (ou tous) de
certains h^otes (ou tous, mais c'est vraiment une tres mauvaise idee) a se connecter
sans qu'il leur soit demande de mot de passe. Cet acces est contr^ole par un chier
nomme /etc/hosts.equiv. Il contient une liste des h^otes et utilisateurs qui sont consi-
deres comme equivalents a ceux de la machine locale. L'autre option est destinee aux
utilisateurs. Elle permet a un utilisateur d'autoriser d'autres personnes, sur certaines
machines, a utiliser son propre compte. Ils doivent alors se trouver dans le chier
.rhosts du repertoire personnel de cet utilisateur. Pour des raisons de securite, ce
chier doit absolument appartenir soit a l'utilisateur, soit au superutilisateur, et ne
doit pas ^etre un lien symbolique : sinon, il sera purement et simplement ignore 5.
Lorsqu'un client demande un service r, le nom de sa machine et son nom d'utilisateur
sont recherches dans le chier /etc/hosts.equiv, puis dans le chier .rhosts de l'uti-
lisateur sous lequel il desire se connecter. Prenons un exemple concret. Supposons
que janet travaille sur gauss et tente de se connecter sur le compte de joe, sur la
5 Dans un environnement NFS, vous devrez peut-^etre lui donner les permissions 444 car le su-
:
perutilisateur a souvent des possibilites d'acces aux chiers tres restreintes sur les disques montes
par le reseau.
140 Chapitre 9. Aspects importants du reseau
machine euler. Tout au long de cet exemple, nous considererons Janet comme l'uti-
lisateur client, et Joe comme l'utilisateur local. Janet tape sa commande sur gauss :

$ rlogin -l joe euler

Le serveur commence par tester hosts.equiv 6 pour voir si Janet a droit a un acces
libre, et si la reponse est negative, il essaiera de le trouver dans le chier .rhosts du
repertoire personnel de joe.
Le chier hosts.equiv sur euler contient ceci :
gauss
euler
-public
quark.physique.groucho.edu andres

Une entree consiste en un nom de machine, suivi facultativement par un nom d'utili-
sateur. Si un h^ote appara^t seul, tous ses utilisateurs seront admis sous leurs comptes
locaux sans aucun test d'identi cation. Dans l'exemple ci-dessus, Janet aurait le droit
de se connecter sous son compte janet en arrivant de gauss, et ce serait vrai pour
tout autre utilisateur a l'exception de root. Toutefois, si Janet voulait entrer sous le
nom joe, il lui serait demande le mot de passe correspondant.
Si un nom d'h^ote est suivi par un utilisateur, comme dans la derniere ligne de
l'exemple, ce dernier possede alors un acces libre, sans mot de passe, a tous les comptes
excepte celui de root.
Le nom de machine peut aussi ^etre precede du signe moins, comme dans l'entree -
public. Cela a pour e et de demander l'authenti cation pour tous les comptes de
-public, quels que soient les droits que les utilisateurs pourraient s'octroyer via leur
chier .rhosts.
Le format de .rhosts est identique a celui de hosts.equiv, mais sa signi cation est un
peu di erente. Considerons le chier .rhosts de Joe, sur la machine euler :
chomp.cs.groucho.edu
gauss janet

La premiere entree autorise un acces libre a l'utilisateur joe lorsqu'il arrive de la ma-
chine chomp.cs.groucho.edu, mais ne change rien aux droits de tout autre compte
sur euler ou chomp. La seconde entree est une variante, en ce sens qu'elle donne un
acces libre du compte de Joe a janet, s'il arrive de gauss.
Notez que le nom de machine du client est obtenu par la recherche inverse sur son
adresse IP, et donc que cette possibilite ne fonctionnera pas avec des h^otes inconnus
6 Notez que le chier hosts.equiv n'est pas utilise si quelqu'un tente de se connecter sous root.
:
9.5. Con guration des commandes en (( r )) 141

du resolver. Ce nom d'h^ote est considere correspondre au nom contenu dans le chier
hosts dans l'un des cas suivants :
{ Le nom canonique du client (et non pas un alias) est identique a celui contenu
dans le chier.
{ Si le nom de la machine cliente est un nom pleinement quali e (comme le re-
tournera le resolver si vous utilisez le DNS), et qu'il n'est pas identique a celui
trouve dans le chier, il sera compare a ce dernier, augmente du nom de domaine
local.
142 Chapitre 9. Aspects importants du reseau
143

Chapitre 10
NIS : Network Information
System
Sur un reseau local, le but de votre travail d'administration est en principe d'o rir un
environnement rendant le reseau transparent a vos utilisateurs. Il vous faudra alors un
moyen de conserver les informations vitales comme les comptes utilisateurs, en parfait
synchronisme sur toutes les machines. Nous avons deja vu que pour la resolution des
noms, nous avons un outil puissant et adapte : DNS. Pour d'autres t^aches, il n'y a
pas de service specialise. De plus, si vous ne gerez qu'un petit reseau non connecte a
l'Internet, l'utilisation du DNS est sans grand inter^et.
C'est pourquoi Sun a developpe NIS, le Network Information System (systeme d'in-
formation reseau). NIS o re des facilites d'acces de base de donnees utilisees pour
distribuer des informations, comme celles contenues dans les chiers passwd et groups,
a tous les h^otes de votre reseau. Celui-ci appara^t alors comme un unique systeme,
avec les m^emes comptes sur toutes les machines. De m^eme, vous pouvez utiliser NIS
pour distribuer les renseignements sur les noms contenus dans /etc/hosts a travers le
reseau.
NIS est base sur RPC, et comprend un serveur, une bibliotheque client, et di erents
outils d'administration. A l'origine, le systeme s'appelait les pages jaunes (Yellow
Pages), ou YP ; et ce nom est encore souvent employe. Or, (( Yellow Pages )) est une
marque deposee de British Telecom, qui imposa a Sun l'utilisation d'un autre nom.
C'est pour cette raison que YP reste le pre xe de la plupart des commandes relatives
a NIS comme ypserv, ypbind, etc.
Aujourd'hui, NIS est disponible pour pratiquement tous les systemes Unix, et il en
existe m^eme des implementations gratuites. L'une d'elles provient de la distribution
Net-2 de BSD et est derivee d'une version de reference en domaine public, o erte par
Sun. Le code de la bibliotheque client de cette version fait partie de la bibliotheque
standard GNU libc depuis longtemps, mais les programmes d'administration n'ont ete
144 Chapitre 10. NIS : Network Information System
que tres recemment portes sous Linux, par Swen Thummler 1 . Il manque un serveur
NIS dans l'implementation de reference. Tobias Reber a realise un autre paquetage
NIS comprenant tous les outils et un serveur ; il s'appelle yps 2 .
Actuellement, une reecriture complete du code NIS, appelee NYS est en cours, ce
travail est e ectue par Peter Eriksson ; 3 elle supportera aussi bien le NIS standard que
la nouvelle version tres amelioree de Sun, NIS+. NYS o re non seulement un ensemble
d'outils et un serveur, mais ajoute de toutes nouvelles bibliotheques de fonctions qui
l'ameneront sans doute a faire partie de la libc standard un jour. Cela comprend une
nouvelle methode de con guration pour la resolution de noms qui remplace l'actuelle,
avec host.conf. Nous decrirons les caracteristiques de ces fonctions.
Ce chapitre est oriente sur NYS plut^ot que les deux autres paquetages, que nous
appellerons le code NIS (( traditionnel )). Si vous avez l'intention d'utiliser l'une ou
l'autre implementation, les instructions contenues dans ce guide pourront peut-^etre
ne pas sure. Pour toute information supplementaire, consultez un ouvrage specialise
sur le sujet, comme NFS and NIS, par Hal Stern ([NFS and NIS]).
Pour l'instant, NYS est encore en cours de developpement, et par consequent les uti-
litaires standard de Linux comme les programmes reseau ou login n'ont pas encore
ete adaptes. Toutefois, NYS est integre a la bibliotheque C libc depuis sa version
4.6, vous pouvez par consequent facilement construire votre propre bibliotheque sup-
portant NYS au lieu du code NIS traditionnel 4 . Les responsables du projet GNU
semblent aussi avoir l'intention d'integrer NYS dans leur implementation ocielle de
la bibliotheque GNU libc, dont celle de Linux est derivee.

10.1 Initiation a NIS


NIS tient sa base de donnees a jour dans des cartes contenant des couples de mots-
cles/valeurs. Elles sont stockees sur un h^ote central sur lequel se trouve le serveur
NIS, depuis lequel les clients peuvent extraire les informations par le truchement de
divers appels RPC. Tres souvent, les cartes sont au format DBM 5 .
Les cartes sont generalement realisees a partir de chiers ASCII de reference comme
/etc/hosts ou /etc/passwd. Pour certains chiers, plusieurs cartes sont generees, une
pour chaque type de cle de recherche. Par exemple, vous pouvez e ectuer une re-
1 On peut joindre Swen a l'adresse swen@uni-paderborn.de. Les clients NIS sont disponibles
:
dans l'archive yp-linux.tar.gz, sur sunsite.unc.edu dans le repertoire system/Network, et sur les
principaux sites di usant Linux, bien entendu.
2 La version courante (a l'heure ou nous ecrivons ces lignes) est yps-0.21 et peut ^etre telechargee
:
sur ftp.lysator.liu.se dans le repertoire /pub/NYS.
3 L'adresse de Peter est pen@lysator.liu.se.
:
4 Toutes les instructions necessaires pour creer une bibliotheque C contenant le support de NYS
:
se trouvent dans le chier README.nys, dans le code source de cette bibliotheque.
5 DBM est une librairie de gestion de base de donnees simple qui utilise des techniques de hachage
:
pour accelerer les operations de recherche. Il existe une implementation libre de cette bibliotheque
appelee gdbm, du projet GNU. Elle fait partie de toute distribution serieuse de Linux.
10.1. Initiation a NIS 145

cherche dans le chier hosts pour un nom de machine, ou pour une adresse IP. Par
consequent, on va donc deriver de ce chier deux cartes NIS, nommees hosts.byname
et hosts.byaddr. Le tableau 10.1 enumere les cartes courantes et les chiers a partir
desquels elles sont generees.

Fichier de reference Carte(s) correspondante(s)


/etc/hosts hosts.byname hosts.byaddr
/etc/networks networks.byname networks.byaddr
/etc/passwd passwd.byname passwd.byuid
/etc/group group.byname group.bygid
/etc/services services.byname services.bynumber
/etc/rpc rpc.byname rpc.bynumber
/etc/protocols protocols.byname protocols.bynumber
/usr/lib/aliases mail.aliases

Tab. 10.1 - Quelques cartes NIS standard et les chiers correspondants.


Vous pourrez trouver le support d'autres chiers et cartes dans certains paquetages
NIS. Ils seront souvent relatifs aux informations d'applications que nous ne decrivons
pas dans ce livre, comme la carte bootparams qui est utilisee par le serveur bootparamd
de Sun.
Il est courant d'attribuer des surnoms a certaines cartes, plus courts et plus simples
a taper. Ces surnoms ne sont compris que de ypcat et ypmatch, deux outils destines a
tester la con guration NIS. Pour en obtenir la liste, tapez la commande suivante :
$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byaddr"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.bynumber"
"services" -> "services.byname"
"aliases" -> "mail.aliases"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.bynumber"
"netmasks" -> "netmasks.byaddr"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"

Le programme serveur NIS s'appelle traditionnellement ypserv. Pour un reseau de


moyenne importance, un seul sut ; de plus grands reseaux peuvent avoir plusieurs
de ces serveurs sur di erentes machines et di erents segments du reseau a n de limiter
146 Chapitre 10. NIS : Network Information System
la charge des h^otes serveurs et des routeurs. Ils sont synchronises en rendant un serveur
ma^tre, alors que les autres sont serveurs esclaves. Les cartes sont creees uniquement
sur la machine du serveur ma^tre, et distribuees aux esclaves.
Vous aurez remarque que, jusqu'a present, nous avons toujours parle de (( reseaux )) de
maniere vague. NIS considere comme reseau l'ensemble des h^otes qui partagent une
partie des donnees de leur con guration systeme par son intermediaire ; et comprend
un concept un peu particulier : le domaine NIS. Malheureusement, les domaines NIS
n'ont absolument rien en commun avec les domaines que nous avons rencontres dans
le DNS. Pour eviter toute ambigute, nous devrons donc dans les pages qui suivent
toujours indiquer de quel type de domaine nous parlons.
Les domaines NIS n'ont qu'une fonction purement administrative. Ils sont pratique-
ment invisibles des utilisateurs, sauf pour le partage des mots de passe entre machines
du domaine. Par consequent, le nom donne a un domaine NIS ne concerne que les
administrateurs. Generalement, n'importe quel nom fera l'a aire, tant qu'il est dif-
ferent de tous les autres noms de domaines NIS eventuellement presents sur votre
reseau local. Par exemple les administrateurs de (( La biere virtuelle )) peuvent choisir
de creer deux domaines NIS, un pour eux-m^emes et un autre pour (( Les caves vir-
tuelles )), qu'ils appelleront respectivement canette et bouteille, par exemple. Une
autre methode courante est d'employer tout simplement le nom du domaine DNS
comme domaine NIS. Pour positionner et acher le domaine NIS de votre h^ote, vous
disposez de la commande domainname. Invoquee sans arguments, elle ache le do-
maine NIS courant ; pour le changer, vous devez passer superutilisateur et taper :

# domainname canette

Les domaines NIS determinent quel serveur interroger. Par exemple, le programme
login d'une machine de nos viticulteurs ne doit, bien entendu, employer que le serveur
de leur domaine NIS (ou l'un d'eux s'il y en a plusieurs) pour demander le mot de
passe d'un utilisateur, et il en va de m^eme pour les brasseurs ; a chaque domaine NIS
son serveur.
Il nous reste un mystere a resoudre: comment un client peut-il trouver sur quel serveur
se connecter ? L'approche la plus simpliste serait d'avoir un chier de con guration
indiquant le nom de la machine a contacter. Ce n'est toutefois pas satisfaisant car
il serait impossible de contacter plusieurs serveurs (du m^eme domaine NIS, cela va
sans dire), selon leur disponibilite. Par consequent, les implementations traditionnelles
de NIS emploient un demon special appele ypbind pour detecter un serveur dans
leur domaine NIS. Avant de pouvoir e ectuer des requ^etes NIS, une application doit
trouver, gr^ace a ypbind, le serveur a contacter.
Ce demon ypbind sonde les serveurs en emettant sur le reseau IP local un message
de di usion (broadcast) ; le premier qui repond est considere comme le plus rapide et
sera utilise pour toutes les requ^etes NIS qui suivront. Apres un certain temps, ou si
le serveur devient indisponible, ypbind recherche a nouveau les serveurs actifs.
10.2. NIS contre NIS+ 147

Cette methode est discutable sur un point ; vous n'en avez que rarement besoin, et
elle introduit un probleme de securite : ypbind croit aveuglement la premiere machine
qui repond, qui peut aussi bien ^etre un humble serveur NIS tout a fait correct, qu'un
malicieux intrus. Il n'est pas besoin de dire que c'est particulierement g^enant lorsque
vous gerez vos mots de passe par NIS. Pour se proteger, la bibliotheque NIS de Linux
n'utilise pas ypbind par defaut, mais recupere le nom du serveur depuis un chier de
con guration.

10.2 NIS contre NIS+


NIS et NIS+ n'ont guere en commun que leur nom et leur fonction. NIS+ est organise
d'une maniere tres di erente. Au lieu d'avoir un espace de noms lineaire avec des
domaines NIS disjoints, il utilise un espace de noms hierarchique similaire a celui
du DNS. A la place des cartes, ce sont des tables qui sont utilisees, constituees de
lignes et de colonnes ; chaque ligne represente un objet dans la base de donnees NIS+,
et chaque colonne contient les proprietes de ces objets, que NIS+ conna^t et gere.
Chaque table d'un domaine NIS+ donne comprend celles de ces domaines parents.
De plus, une entree dans une table peut contenir un lien vers une autre table. Ainsi,
il est possible de structurer l'information de nombreuses facons.
Le NIS traditionnel a une version RPC de 2, alors que NIS+ porte le numero 3. Ce
dernier ne semble pas encore largement utilise, et nous devons avouer que nous ne
connaissons pas grand-chose a son sujet, voire rien du tout. Par consequent, nous
n'en parlerons pas davantage ici. Si vous voulez en savoir plus, consultez le manuel
d'administration NIS+ de Sun ([NIS+]).

10.3 Le c^ote client de NIS


Si vous avez l'habitude d'ecrire ou de porter des applications reseau, vous aurez note
que la plupart des cartes NIS citees plus haut correspondent a des fonctions de la
bibliotheque C. Par exemple, pour obtenir des informations concernant le mot de
passe (passwd), vous appelez en general les fonctions getpwnam(3) et getpwuid(3), qui
retournent les donnees associees avec le nom d'utilisateur ou son numero d'identi -
cation, respectivement. En des circonstances normales, ces fonctions e ectueront la
recherche sur les chiers standard, en general /etc/passwd.
Pour supporter NIS, le comportement de ces fonctions sera modi e ; un appel RPC
est e ectue a n de pouvoir interroger le serveur NIS et recuperer les informations
demandees. Cette modi cation est transparente pour l'application. La fonction peut
soit (( ajouter )) la carte NIS au chier original, soit le (( remplacer )) entierement. Bien
s^ur, il ne s'agit pas de reelles modi cations du chier, mais de ce qui appara^t vu du
c^ote de l'application.
148 Chapitre 10. NIS : Network Information System
En ce qui concerne les implementations traditionnelles de NIS, certaines conventions
ont emerge qui permettent de determiner quelles cartes sont ajoutees ou lesquelles
remplacent l'information originale. Quelques-unes, comme les cartes passwd, deman-
dent des modi cations du chier passwd qui, incorrectement e ectuees, creent des
failles dans la securite du systeme. Pour eviter ces pieges, NYS emploie un systeme
de con guration generale qui determine si un ensemble de fonctions particulier doit
utiliser les chiers originaux, NIS ou NIS+, et dans quel ordre. Nous decrirons cela
un peu plus loin.

10.4 Installer un serveur NIS


Apres autant de theorie rebarbative, il est temps de mettre les mains dans le cambouis
en installant reellement la chose. Dans cette section, nous allons donc aborder la
con guration d'un serveur NIS. S'il y en a deja un en fonctionnement sur votre reseau,
vous n'aurez pas besoin d'installer le v^otre ; vous pouvez sans risque ignorer cette
section.

} Si vous comptez juste faire quelques experiences avec le serveur, assurez-


vous de ne pas le con gurer pour un domaine NIS deja existant sur votre
reseau. Cela pourrait interrompre tout le service et vous rendre tres im-
populaire aupres de beaucoup de gens...

Il existe actuellement deux serveurs NIS disponibles sous Linux ; l'un se trouve dans
le paquetage yps de Tobias Reber, et l'autre dans l'ensemble ypserv de Peter Eriksson.
Celui que vous utiliserez n'a aucune importance, que vous preniez NYS ou le code NIS
standard qui est actuellement dans la bibliotheque libc. A l'heure ou nous redigeons ce
chapitre, le code gerant les serveurs esclaves NIS semble plus complet dans yps. D'un
autre c^ote, ypserv corrige un probleme de securite courant sous NIS (qui sera decrit
plus loin), ce que ne fait pas yps. Le choix depend donc entierement de vos besoins.
Apres avoir installe le programme serveur (ypserv) dans /usr/sbin, vous devrez creer
le repertoire destine a recevoir les cartes qui seront distribuees. Pour con gurer le
domaine NIS canette, les cartes devront se trouver dans /var/yp/canette. Le serveur
determine s'il gere un domaine NIS particulier en testant l'existence de ce repertoire.
Si vous supprimez le service d'un domaine NIS, assurez-vous de supprimer egalement
ce repertoire.
A n d'accelerer les recherches, les cartes sont souvent stockees au format DBM. Elles
sont creees a partir des chiers de reference a l'aide d'un programme appele makedbm
(pour le serveur de Tobias) ou dbmload (pour celui de Peter). Attention, ces com-
mandes peuvent ne pas ^etre interchangeables. Transformer un chier en une forme
comprehensible par dbmload necessite generalement un peu de magie awk ou sed, par
consequent le paquetage ypserv de Peter Eriksson contient un Make le (nomme yp-
Make le) qui e ectue tout le travail pour vous. Vous devrez l'installer sous le nom
10.5. Securite du serveur NIS 149

Make le dans le repertoire ou se trouvent vos cartes et l'editer pour qu'il re ete celles
que vous desirez distribuer. Vers le debut de ce chier, vous trouverez la cible all qui
indique les services que ypserv devra o rir. Par defaut, la ligne ressemble a celle-ci :

all: ethers hosts networks protocols rpc services passwd group netid

Si par exemple vous ne voulez pas produire les cartes ethers.byname et ethers.byaddr,
il sut de supprimer le mot ethers de cette ligne. Pour tester votre con guration,
vous pouvez commencer avec juste une ou deux cartes, comme services.*.
Apres avoir edite ce Make le, restez dans le repertoire et tapez make. Les cartes seront
alors automatiquement generees et installees. Il ne faudra pas oublier de mettre a jour
ces cartes chaque fois que vous modi erez les chiers de reference, faute de quoi les
modi cations resteraient invisibles sur le reseau.
La section suivante detaille la con guration de la partie client de NIS. Si rien ne
marche, essayez de voir si les requ^etes arrivent a votre serveur. En indiquant l'option
-debug sur la ligne de commandes de ypserv, vous obtiendrez des messages de d ebo-
guage sur la console, indiquant toutes les requ^etes NIS recues et le resultat qui est
envoye aux clients ; cela devrait vous permettre de localiser le probleme. Le serveur
de Tobias ne possede pas cette option.

10.5 Securite du serveur NIS


NIS avait un important trou de securite : il permettait la lecture de votre chier de
mots de passe par pratiquement n'importe qui sur l'Internet, ce qui represente une
quantite non negligeable d'intrusions possibles. Il susait de conna^tre votre domaine
NIS et l'adresse de votre serveur, et de lui envoyer une requ^ete demandant la carte
passwd.byname, pour recevoir aussit^ot tous les mots de passe de votre site. Avec un
programme rapide comme crack et un bon dictionnaire, il etait en general tres facile
d'en trouver au moins quelques-uns.
C'est pourquoi l'option securenets a ete creee. Elle restreint l'acces de votre serveur
NIS a certains h^otes, en fonction de leur adresse IP ou du reseau. La derniere version de
ypserv implemente cette option de facon assez pratique, par les chiers etc/hosts.allow
et /etc/hosts.deny que nous avons deja rencontres dans le chapitre 9 6 . Par exemple,
pour restreindre l'acces aux machines des brasseurs, leur administrateur reseau ra-
jouterait dans le chier hosts.allow la ligne suivante :

ypserv: 172.16.2.

6 Pour valider cette option, il peut ^etre necessaire de recompiler le serveur. Lisez les instructions
:
contenues dans le chier README fourni dans la distribution.
150 Chapitre 10. NIS : Network Information System
Tous les h^otes du reseau IP 172.16.2.0 auraient acces au serveur NIS. Pour interdire
tous les autres, l'entree correspondante dans hosts.deny serait :
ypserv: ALL

Les numeros IP ne sont pas la seule facon de speci er h^otes ou reseaux dans hosts.allow
et hosts.deny. Consultez la page de manuel hosts access(5) sur votre systeme pour
avoir plus de details. Toutefois, vous devez savoir qu'il est impossible d'utiliser des
noms d'h^otes ou de domaines dans l'entree ypserv : si vous y mettez un nom, le
serveur essaie de le resoudre, mais le resolver appelle a son tour ypserv, et vous entrez
dans une boucle in nie.
Vous pouvez aussi utiliser le portmapper securise a la place de l'option securenets de
ypserv. Cette version (portmap-3.0) 7 emploie aussi la methode par hosts.allow, mais
o re cette securite pour tous les serveurs RPC, et non pas uniquement pour ypserv.
Mais n'essayez pas d'utiliser a la fois securenets et le portmapper securise, ce serait
inutile et la charge serait trop importante.

10.6 Con guration d'un client NIS avec NYS


La n de ce chapitre sera entierement consacree a la con guration d'un client NIS.
La premiere etape consiste a indiquer a NYS quel serveur NIS doit ^etre utilise. Vous
pouvez mettre son nom dans le chier de con guration /etc/yp.conf ; voici un exemple
pour une machine du reseau des viticulteurs :
# yp.conf - Configuration YP pour la biblioth
eque NYS.
#
domainname bouteille
server gamay

La premiere ligne indique a tous les clients NIS que cet h^ote appartient au domaine
NIS bouteille. Si vous omettez cette declaration, NYS utilisera le nom de domaine
que vous avez assigne au systeme par la commande domainname. La seconde ligne
indique le nom du serveur NIS a utiliser. Bien entendu, l'adresse IP correspondant a
gamay doit se trouver dans le chier hosts ; l'alternative etant de mettre directement
cette adresse IP au lieu du nom.
Dans la forme ci-dessus, la commande server indique a NYS d'utiliser le serveur spe-
ci e, quel que soit le domaine NIS courant. Si, toutefois, vous deplacez votre machine
frequemment d'un domaine NIS a un autre, vous pouvez indiquer ces domaines dans
le chier yp.conf : il sut d'indiquer plusieurs serveurs, suivi du domaine NIS corres-
pondant. Par exemple :

7 Disponible par FTP anonyme sur sunsite.unc.edu dans le repertoire Linux/systems/Network.


:
10.7. Choisir les bonnes cartes 151

# yp.conf - YP configuration for NYS library.


#
server gamay bouteille
server gueuze canette

Ce pourrait ^etre la con guration d'une machine portable, appelee a ^etre utilisee tour a
tour dans ces deux domaines NIS. Il sura d'initialiser le domaine desire au moment
du demarrage du systeme, par la commande domainname.
Apres avoir cree ce chier de con guration de base et avoir veri e qu'il est lisible
par tout le monde, vous devez faire votre premier test pour voir si vous pouvez bien
vous connecter a votre serveur. Choisissez une carte que celui-ci distribue, comme
hosts.byname, et essayez de la recuperer avec l'utilitaire ypcat. Ce programme, comme
tous les autres outils d'administration NIS, doit se trouver dans le repertoire /usr/sbin.
# ypcat hosts.byname
172.16.2.2 brouilly.bibine.com brouilly
172.16.2.3 gamay.bibine.com gamay
172.16.1.1 kro.bibine.com kro
172.16.2.1 kro.bibine.com kro
172.16.1.2 gueuze.bibine.com gueuze
172.16.1.3 trappiste.bibine.com trappiste
172.16.2.4 cahors.bibine.com cahors

Vous devriez obtenir une sortie ressemblant a celle ci-dessus. Si vous avez un message
d'erreur disant (( Can't bind to server which serves domain )), c'est que soit le
domaine NIS que vous avez initialise n'a pas de serveur correspondant de ni dans
le chier yp.conf, soit que le serveur est inaccessible pour une raison quelconque.
Dans ce dernier cas, veri ez qu'un ping vers cette machine fonctionne bien, et qu'il y
existe bien un serveur NIS. Vous pouvez veri er si un serveur NIS est present par la
commande rpcinfo, qui devrait vous acher :

# rpcinfo -u nom-de-machine ypserv


program 100004 version 2 ready and waiting

10.7 Choisir les bonnes cartes


Apres avoir veri e que le serveur NIS est accessible, vous devez decider quels chiers
doivent ^etre remplaces ou completes par les cartes NIS. Generalement, ce sont ceux
permettant la recherche de noms et de mots de passe qui sont choisis. Le premier cas
est tres utile si vous n'employez pas BIND ; le second permet a tous les utilisateurs
de se connecter sous leur compte depuis n'importe quel systeme du domaine NIS, et
va generalement de pair avec le partage d'un repertoire /home central monte sur tous
les h^otes par NFS. La carte concernant les mots de passe est expliquee en detail dans
la section suivante.
152 Chapitre 10. NIS : Network Information System
D'autres cartes, comme services.byname, rendent un service moins impressionnant,
mais peuvent neanmoins vous epargner un peu de travail d'edition de chiers de
con guration. La carte services.byname est interessante si vous installez des applica-
tions reseaux qui emploient des services absents du chier services standard (ce qui
est un cas assez courant).
En general, il sera bon de pouvoir choisir quand une fonction de recherche devra utili-
ser les chiers locaux ou le serveur NIS. NYS permet de con gurer l'ordre dans lequel
ces recherches sont faites, par l'intermediaire du chier /etc/nsswitch.conf, (Name
Service Switch). Ce chier contient une ligne pour chacune des fonctions de recherche
supportees par NYS.
L'ordre correct depend du type des donnees. Il y a peu de chances que la carte ser-
vices.byname contienne des entrees di erentes de celles du chier local /etc/services ;
tout au plus pourra-t-elle contenir des entrees supplementaires. Par consequent, il
para^t raisonnable d'e ectuer les recherches d'abord dans le chier local, et ne tester
NIS que si le nom de service recherche ne s'y trouve pas. En revanche, les informa-
tions sur les noms de machines peuvent changer frequemment, donc DNS ou NIS sont
toujours plus a jour que le chier /etc/hosts qui ne contient qu'une sauvegarde en cas
de probleme. Dans ce cas, il ne faudra e ectuer les recherches dans ce chier qu'en
dernier recours.
L'exemple suivant montre comment forcer les fonctions gethostbyname(2), gethost-
byaddr(2) et getservbyname(2) a interroger NIS et DNS avant de scruter le chier
hosts. Elle essaieront chaque service cite dans l'ordre ou ils apparaissent sur la ligne.
Si une recherche aboutit, le resultat est immediatement retourne, sinon le service
suivant est interroge.
# petit exemple de fichier /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis

Voici la liste complete des services susceptibles d'^etre utilises dans une entree de nss-
witch.conf. Les cartes, chiers, serveurs et objets utilises pour les recherches dependent
bien entendu du nom de l'entree.
nisplus ou nis+
Utilise le serveur NIS+ du domaine. Son adresse sera obtenue par le
chier /etc/nis.conf.
nis Interroge le serveur NIS du domaine. La machine a contacter est
con guree dans le chier yp.conf comme decrit dans la section pre-
cedente. Pour les entrees hosts, ce sont les cartes hosts.byname et
hosts.byaddr qui seront demandees.
dns Utilise le serveur de noms DNS. Ce type de service n'est utile qu'avec
10.8. Utilisation des cartes passwd et group 153

l'entree hosts. Les serveurs de noms interroges sont toujours deter-


mines par le chier resolv.conf standard.
les E ectue la recherche dans les chiers locaux, comme par exemple
/etc/hosts dans le cas de l'entree hosts.
dbm Recherche l'information dans les chiers DBM, qui sont situes dans
le repertoire /var/dbm. Le nom du chier est celui de la carte NIS
correspondante.
Pour l'instant, NYS supporte les entrees nsswitch.conf suivantes : hosts, networks,
passwd, group, shadow, gshadow, services, protocols, rpc et ethers. D'autres entrees
seront probablement ajoutees dans les versions ulterieures.
La gure 10.1 montre un exemple plus complet, qui introduit un autre aspect de
nsswitch.conf. Le mot cle [NOTFOUND=return] dans l'entree hosts indique a NYS
d'arr^eter la recherche si les donnees recherchees n'ont pu ^etre trouvees dans les bases
de donnees NIS ou DNS. C'est-a-dire que NYS continuera la recherche dans les chiers
locaux uniquement si les appels aux serveurs NIS et DNS echouent pour une raison
quelconque. Les chiers locaux ne seront alors utilises qu'au moment du demarrage
du systeme et comme sauvegarde lorsque le serveur NIS est inaccessible.

# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files

services: files nis


protocols: files nis
rpc: files nis

Fig. 10.1 - Exemple de chier nsswitch.conf.

10.8 Utilisation des cartes passwd et group


L'une des principales applications de NIS est la synchronisation des informations uti-
lisateur sur tous les h^otes d'un domaine NIS. Pour cela, on ne conserve en general
qu'un petit chier /etc/passwd local, auquel les donnees de tout le reseau en prove-
nance des cartes NIS sont ajoutees. Toutefois, il ne sut pas de valider les recherches
NIS pour ce service dans nsswitch.conf pour que tout fonctionne.
Pour employer les informations utilisateur distribuees par NIS, vous devez d'abord
vous assurer que les valeurs de chaque numero d'utilisateur presentes dans votre chier
passwd local correspondent a celles connues de NIS. Ce sera egalement necessaire pour
154 Chapitre 10. NIS : Network Information System
bien d'autres choses, comme les montages NFS de partitions d'autres machines de
votre reseau sur la v^otre.
Si l'une des valeurs de /etc/passwd ou /etc/group di ere de celle enregistree dans les
cartes, vous devrez ajuster les proprietaires de tous les chiers qui appartiennent a
cet utilisateur. Tout d'abord, il faudra changer tous les numeros d'utilisateurs et de
groupes dans ces deux chiers pour les mettre a jour, puis trouver tous les chiers
appartenant aux utilisateurs concernes, et en n changer leur proprietaire. Supposons
que news avait un numero d'utilisateur de 9, et marcel de 103, et qu'ils ont ete
changes pour de nouvelles valeurs. Il faudra alors executer les commandes suivantes :
# find / -uid 9 -print >/tmp/uid.9
# find / -uid 103 -print >/tmp/uid.103
# cat /tmp/uid.9 | xargs chown news
# cat /tmp/uid.103 | xargs chown marcel

Il est tres important d'executer ces commandes une fois le nouveau chier passwd
installe, et que tous les chiers ont ete trouves. La mise a jour des groupes se fait de
la m^eme maniere.
Apres cela, les numeros d'utilisateurs et de groupes sur votre systeme correspondront
a ceux des autres machines de votre domaine NIS. L'etape suivante sera d'ajouter les
lignes de con guration dans nsswitch.conf qui valideront les recherches NIS pour les
informations utilisateur et groupe :
# /etc/nsswitch.conf - traitement de passw et group
passwd: nis files
group: nis files

Cela changera la maniere dont la commande login et toute sa famille rechercheront


les informations utilisateur. Lorsque quelqu'un tente de se connecter, login demande
d'abord la carte NIS, et si la recherche echoue, il se tournera vers les chiers locaux.
En principe, on supprime pratiquement tous les utilisateurs des chiers locaux, pour
ne laisser que les entrees reellement indispensables comme root, mail ou autres,
car certaines applications ont besoin de trouver la correspondance entre ces noms
d'utilisateurs et leur numero, et vice versa. Par exemple, les travaux administratifs de
cron peuvent executer la commande su pour devenir provisoirement news, ou bien
le systeme UUCP peut avoir a poster un courrier de statistiques. Si news et uucp
n'ont pas d'entrees dans le chier local passwd, ces travaux echoueront lamentablement
pendant les pannes NIS.
Il y a deux gros pieges avec ce systeme. D'une part, la con guration decrite jusqu'ici
ne fonctionne que pour la famille login qui n'utilise pas les mots de passe shadow,
comme ceux inclus dans le paquetage util-linux. Nous verrons le cas des mots de passe
shadow un peu plus loin. D'autre part, il y a d'autres commandes qui ont besoin des
informations contenues dans le chier passwd ; regardons par exemple la commande
ls, que tout le monde utilise presque constamment. Lorsqu'on lui demande une sortie
10.9. NIS et les mots de passe shadow 155

(( longue )), ls ache les noms des groupes et des utilisateurs propri etaires de chaque
chier. Pour chaque numero rencontre, elle devra donc interroger le serveur NIS. Cela
ralentira enormement les choses, surtout si votre reseau local est charge ; ne parlons
m^eme pas de la situation ou le serveur NIS n'est pas sur le m^eme reseau physique et
que les datagrammes doivent traverser un routeur.
Mais ce n'est pas tout ! Imaginez ce qui arrive si un utilisateur desire changer son mot
de passe. Il appellera la commande passwd le plus naturellement du monde, qui mettra
a jour le chier passwd local. Or c'est impossible avec NIS, puisque ce chier n'est
plus disponible localement, et il n'y a aucune option pour que les utilisateurs puissent
se connecter au serveur NIS pour changer leurs mots de passe. Par consequent, NIS
o re une commande de remplacement appelee yppasswd, qui est equivalente a passwd
lorsque NIS est disponible. Elle contacte le serveur NIS par RPC, et lui donne le
nouveau mot de passe. En general, on installe yppasswd a la place de la commande
passwd originale, en faisant quelque chose comme ceci :
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd

Vous devrez en m^eme temps installer rpc.yppasswdd sur le serveur et le lancer depuis
rc.inet2. Ainsi, toutes les complications induites par NIS seront totalement cachees
aux utilisateurs.

10.9 NIS et les mots de passe shadow


Utiliser NIS avec les mots de passe shadow tient malheureusement du bricolage. Le
systeme shadow a ete invente pour emp^echer les utilisateurs ordinaires d'avoir acces
aux mots de passe des autres, fussent-ils cryptes. D'un autre c^ote, NIS necessite que
ces donnees soient disponibles sur tout le reseau, ce qui va completement a l'encontre
du but initial.
Actuellement, il n'y a aucune solution reellement satisfaisante a ce probleme. La
seule facon de distribuer des mots de passe et autres informations utilisateur par NIS
passe par les cartes standard passwd.*. Si vous avez le systeme shadow, la methode
la plus simple de les partager est de generer un chier passwd ordinaire a partir de
/etc/shadow a l'aide d'outils comme pwunconv, et de creer les cartes NIS a partir de
celui-ci.
Bien s^ur, quelques astuces peu pratiques sont necessaires pour utiliser NIS et le sys-
teme shadow en m^eme temps ; par exemple installer un chier /etc/shadow sur chaque
h^ote du reseau, tout en distribuant le reste des informations (groupes, shells, etc.) par
NIS. Inutile de dire que cette solution est plut^ot b^atarde et de e l'orientation de NIS,
qui est de faciliter la t^ache de l'administrateur systeme. A notre avis, une methode
forcant les utilisateurs a choisir de (( bons )) mots de passe est bien meilleure que celle
qui consiste a les cacher dans un chier supplementaire en creant des incompatibilites.
156 Chapitre 10. NIS : Network Information System
10.10 Utilisation du code NIS traditionnel
Si vous utilisez le code client qui est actuellement integre a la bibliotheque standard
libc, la con guration d'un client NIS est un peu di erente. En premier lieu, le code
traditionnel ne supporte que les cartes hosts, passwd et group. De plus, la facon dont
il combine les informations des chiers locaux avec celles de NIS est tres di erente de
ce qui se passe avec NYS.
Par exemple, pour utiliser les cartes NIS des mots de passe, il faut inclure la ligne
suivante quelque part dans le chier /etc/passwd :

+:*:0:0:::

Elle marque l'endroit ou les fonctions de recherche (( inserent )) les cartes NIS. Une
ligne similaire dans le chier /etc/group a le m^eme e et pour les cartes group.*.
Pour utiliser les cartes hosts.* distribuees par votre serveur YP, changez la ligne
order du chier host.conf. Par exemple, pour utiliser NIS, DNS et /etc/hosts (dans
cet ordre), cette ligne doit appara^tre ainsi :

order yp bind hosts

Contrairement a NYS, le code traditionnel necessite un demon ypbind pour trouver les
serveurs actifs, qui doit ^etre invoque au demarrage du systeme apres que le domaine
NIS a ete initialise et que le portmapper RPC a ete lance.
Jusqu'a il y a peu, ypbind cherchait les serveurs par di usion RPC. Comme nous
l'avons dit au debut, c'est une solution peu s^ure. C'est pourquoi la derniere version
des outils YP (de la distribution yp-linux) possede maintenant un demon ypbind qui
supporte le chier de con guration /etc/yp.conf. Si ce chier existe, le programme y
recherchera une ou plusieurs lignes de la forme :
# yp.conf - name YP server for ypbind.
ypserver gamay

Le demon ypbind recherche alors les serveurs actifs parmi ceux indiques 8. S'il ne trouve
pas de chier yp.conf, ou si aucun des serveurs ne repond, il reprendra l'ancienne
methode de di usion RPC, a la recherche d'un serveur qui veuille bien repondre.
Il y a eu recemment de nombreux rapports de bogue signalant que NIS echouait avec
les messages d'erreur :

clntudp create: RPC: portmapper failure - RPC: unable to receive

8 Notez que le mot cle est di erent de celui utilise par NYS pour le nom du serveur.
:
10.10. Utilisation du code NIS traditionnel 157

Ils sont dus a une modi cation malencontreuse de la facon dont ypbind communique
avec les fonctions de la bibliotheque. Pour y remedier, il faut se procurer les dernieres
versions des sources des utilitaires NIS et les recompiler 9.

9: Le code source de yp-linux peut ^etre obtenu sur le site ftp.uni-paderborn.de dans le repertoire
/pub/Linux/LOCAL.
158 Chapitre 10. NIS : Network Information System
159

Chapitre 11
NFS, le systeme de chiers
par reseau
NFS, le systeme de chiers par reseau, est probablement le service le plus repandu
utilisant RPC. Il permet d'acceder aux chiers presents sur des machines distantes
exactement comme s'ils etaient locaux. Il est constitue d'un melange de fonctionnalites
integrees au noyau c^ote client et d'un serveur NFS de l'autre c^ote. Cet acces est
completement transparent pour le client, et fonctionne sur une grande variete de
serveurs et d'architectures.
NFS o re un certain nombre d'avantages :
{ Les donnees auxquelles tous les utilisateurs accedent peuvent resider sur un
h^ote central, chaque client montant ce repertoire au demarrage du systeme.
Par exemple, vous pouvez conserver tous les comptes des utilisateurs sur une
machine et faire que toutes les autres montent le repertoire /home depuis cet
endroit. Si, de plus, NIS est installe, les utilisateurs peuvent se connecter sur
n'importe quel h^ote et travailler toujours sur les m^emes chiers.
{ Les donnees occupant beaucoup de place disque peuvent ^etre stockees sur une
seule machine. Par exemple, tous les chiers et programmes relatifs a LaTEX et
METAFONT peuvent ^etre installes et maintenus en un seul endroit.
{ Les donnees administratives peuvent se trouver sur une unique machine. Il n'y a
pas besoin d'utiliser rcp pour installer le m^eme stupide chier sur 30 ordinateurs
di erents.
Sous Linux, NFS est en grande partie le travail de Rick Sladkey 1 , qui a ecrit le code
NFS du noyau et une bonne partie du serveur. Ce dernier est derive de unfsd (user
1 On peut joindre Rick a l'adresse jrs@world.std.com.
:
160 Chapitre 11. NFS, le systeme de chiers par reseau
space NFS server), realise a l'origine par Mark Shand, et de hnfs (Harris NFS server),
ecrit par Donald Becker.
Voyons le fonctionnement de NFS. Un client essaie de monter un repertoire d'une
machine distante sur un repertoire local, exactement de la m^eme maniere qu'il le fait
pour un peripherique physique. Mais la syntaxe a employer pour designer le repertoire
distant est di erente. Par exemple, pour monter le /home de kro sur le repertoire
users de trappiste, l'administrateur tape la commande suivante sur trappiste 2 :

# mount -t nfs kro:/home /users

La commande mount essaiera de se connecter au demon mountd de kro via RPC. Le


serveur testera si trappiste a l'autorisation de monter le repertoire en question, et si
c'est le cas, retournera un descripteur de chier. Il sera utilise pour toutes les requ^etes
suivantes concernant les chiers de /users.
Lorsque quelqu'un accede a un chier par NFS, le noyau envoie un appel RPC a
nfsd (le demon NFS) sur la machine serveur. Cet appel prend comme parametres
le descripteur de chier, le nom du chier auquel il faut acceder, et l'identi cation
(numero et groupe) de l'utilisateur. Ces derniers sont utilises pour determiner les
droits d'acces au chier en question. A n d'eviter que des utilisateurs non autorises
puissent lire ou modi er des donnees, les numeros d'utilisateurs et de groupes doivent
^etre les m^emes sur les deux machines.
Dans la plupart des implementations d'UNIX, le client comme le serveur NFS sont
implementes comme des demons de niveau noyau qui sont lances depuis l'espace
utilisateur au moment du demarrage du systeme. Ce sont nfsd, le demon NFS sur le
serveur, et biod (Block I/O Daemon) sur la machine cliente. Pour ameliorer la vitesse,
biod e ectue des entrees/sorties asynchrones et plusieurs exemplaires fonctionnent
simultanement.
Sous Linux, l'implementation de NFS est un peu di erente, en ce sens que le code client
est integre a la couche VFS du noyau (Virtual File System, systeme de chiers virtuel)
et ne necessite aucun autre contr^ole additionnel par biod. De l'autre c^ote, le code
serveur fonctionne entierement dans l'espace utilisateur, aussi est-il impossible d'avoir
plusieurs copies de ce serveur fonctionnant simultanement, en raison des problemes
de synchronisation que cela poserait. Il n'y a pas non plus de cache, mais cela fait
partie des projets de Rick Sladkey.
Dans la version 1.0 de Linux, le plus gros probleme avec NFS est que le noyau n'est
pas capable d'allouer de la memoire par blocs de plus de 4 Ko. En consequence, le
code reseau ne peut pas gerer de datagrammes superieurs a environ 3 500 octets apres
soustraction des en-t^etes et autres donnees internes. Cela signi e que les transferts
NFS avec des machines utilisant de grands datagrammes UDP par defaut (8 Ko sur
SunOS par exemple) doivent ^etre arti ciellement reduits. Les performances en sont
2 Vous pouvez omettre l'option -t
: , car mount voit qu'il s'agit d'un volume NFS, gr^ace au
nfs
caractere (( : )).
11.1. Veri cations avant usage 161

sensiblement a ectees en certaines circonstances 3. Cette limite est franchie les versions
Linux-1.1 recentes, et le code client a ete modi e en consequence, bien entendu.

11.1 Veri cations avant usage


Avant que vous ne puissiez utiliser NFS, que ce soit en client ou en serveur, vous
devez veri er que le noyau que vous utilisez a bien ete compile avec le support de
NFS. Pour cela, Les versions recentes de Linux ont une interface dans le systeme de
chiers proc, le chier /proc/ lesystems que vous pouvez acher par la commande
cat :

$ cat /proc/filesystems
minix
ext2
xiafs
msdos
nodev proc
nodev nfs
iso9660

Si vous ne voyez pas nfs dans la liste, vous devez recompiler votre noyau en validant
le support de NFS. Consultez la section (( Con guration du noyau )) du chapitre 3.
Dans le cas d'une ancienne version, anterieure a Linux 1.1, le meilleur moyen de savoir
si NFS est valide est d'essayer de monter un volume NFS. Pour cela, vous pouvez creer
un repertoire de test dans /tmp, et essayer de monter un repertoire local dessus :

# mkdir /tmp/test
# mount localhost:/etc /tmp/test

Si cette operation echoue avec un message d'erreur indiquant (( fs type nfs not
supported by kernel )), vous devrez vous compiler un nouveau noyau en validant
NFS. Tout autre message d'erreur est sans importance, puisque rien n'est encore
con gure.

:3 Comme l'a explique Alan Cox : Les speci cations de NFS necessitent que le serveur termine
toute ecriture disque avant de renvoyer un acquittement. Comme les noyaux BSD ne sont capables
d'ecrire que des pages (4 Ko), ecrire quatre fragments de 1 Ko chacun sur un serveur NFS BSD
resulte en quatre operations d'ecriture de 4 Ko chacune.
162 Chapitre 11. NFS, le systeme de chiers par reseau
11.2 Monter un volume NFS
Les volumes NFS 4 sont montes presque de la m^eme facon que les systemes de chiers
traditionnels. Vous appelez la commande mount avec la syntaxe suivante :
# mount -t nfs volume nfs r
epertoire local options

Avec volume nfs indique comme h^ote distant:repertoire distant. Puisque cette
notation est unique aux systemes de chiers NFS, vous pouvez omettre l'option -t
nfs.
Il y a un certain nombre d'options additionnelles possibles que vous pouvez indiquer
a la commande mount. Elles peuvent ^etre donnees soit apres le commutateur -o sur
la ligne de commandes, soit dans le champ prevu a cet e et dans l'entree du chier
/etc/fstab correspondant a ce volume. Dans les deux cas, ces options sont separees
entre elles par des virgules. Celles speci ees en ligne de commandes ont toujours
priorite sur celles du chier fstab.
Voici un exemple d'entree de /etc/fstab :
# volume point de montage type options
news:/usr/spool/news /usr/spool/news nfs timeo=14,intr

Ce volume peut alors ^etre monte par cette commande :


# mount news:/usr/spool/news

En l'absence d'une entree fstab, la commande a passer est un peu moins lisible. Par
exemple, supposons que vous montiez vos repertoires utilisateurs depuis une machine
appelee labas, qui utilise par defaut des blocs de 4 Ko pour les operations de lec-
ture/ecriture. Vous voulez reduire cette taille a 2 Ko parce que vous avez un ancien
noyau Linux ; la commande est alors :
# mount labas:/home /home -o rsize=2048,wsize=2048

La liste de toutes les options valides est decrite en totalite dans la page de manuel de
nfs(5) fournie avec la version de mount de Rick Sladkey (qui fait partie du paquetage
util-linux). En voici un extrait :
rsize=n et wsize=n
Speci ent la taille du datagramme utilisee par les clients NFS pour
les requ^etes de lecture et d'ecriture, respectivement. Actuellement,
leur valeur par defaut est de 1 024 octets pour les raisons evoquees
plus haut.
4 On ne dit pas systeme de chiers, car ce ne sont pas a proprement parler des systemes de
:
chiers.
11.2. Monter un volume NFS 163

timeo=n Indique le temps (en dixiemes de seconde) pendant lequel le client


NFS attendra qu'une requ^ete aboutisse. La valeur par defaut est 7
(0,7 seconde).
hard Marque explicitement le volume comme monte en dur. C'est l'option
par defaut.
soft Il s'agit de l'option inverse de hard.
intr Autorise les signaux a interrompre un appel NFS. C'est utile lorsque
le serveur ne repond pas.

Sauf pour rsize et wsize, toutes ces options concernent le comportement du client si le
serveur devient momentanement inaccessible. Elles s'organisent de la facon suivante :
Lorsque le client envoie une requ^ete au serveur NFS, il attend pendant un certain
temps (de ni par l'option timeout) que l'operation soit terminee. Si aucune con r-
mation ne lui arrive pendant le temps imparti, un depassement de temps mineur est
compte, et il recommence l'operation en doublant cet intervalle de temps. Lorsque
cette valeur atteint 60 secondes, un depassement de temps majeur se produit.
Par defaut, un depassement de temps majeur provoquera l'achage d'un message sur
la console, et l'operation recommencera, en doublant encore une fois le temps imparti.
Le cycle peut durer eternellement. Les volumes montes ainsi, ou les operations seront
tentees jusqu'a ce que le serveur reponde, sont dits montes en dur. Dans le cas inverse,
le processus appelant recoit une erreur d'entree/sortie lorsqu'un depassement de temps
majeur se produit. En raison du cache, cette condition d'erreur n'est pas propagee
au processus avant son prochain appel a la fonction write(2), aussi dans ce cas de
montage, un programme ne peut jamais ^etre certain qu'une operation d'ecriture a
reussi.
Monter en dur ou non est une question de go^ut, mais depend aussi des donnees aux-
quelles vous comptez acceder par NFS. Par exemple, s'il s'agit de vos programmes X,
vous ne souhaitez sans doute pas que votre session de travail se termine anorma-
lement, uniquement parce que quelqu'un a momentanement surcharge le reseau en
lancant sept copies de xv simultanement, ou parce que la prise s'est debranchee. Avec
un montage en dur, vous serez s^ur que votre machine attendra jusqu'a ce que le contact
soit retabli avec le serveur NFS. D'un autre c^ote, les donnees non critiques, comme les
partitions de News Usenet ou les archives FTP, ne necessitent pas de montage en dur,
de sorte que les sessions ne restent pas en attente inde niment en cas de panne reseau
ou d'arr^et de la machine distante. Si votre reseau est souvent surcharge ou lent pour
des raisons diverses, vous pouvez augmenter le delai d'attente par l'option timeo, ou
monter les volumes en dur, mais autorisez l'interruption des appels NFS (intr) pour
ne pas rester bloque en cas de probleme.
Generalement, le demon mountd conservera d'une maniere ou d'une autre une trace
des repertoires qui ont ete montes, et par quels h^otes. Cette information peut ^etre
achee par la commande showmount, qui fait partie du paquetage serveur NFS. La
164 Chapitre 11. NFS, le systeme de chiers par reseau
version Linux, toutefois, n'implemente pas encore cette possibilite.

11.3 Les demons NFS


Si vous desirez o rir un service NFS a d'autres h^otes, vous devrez lancer les demons
nfsd et mountd sur votre machine. En tant que programmes RPC, ils ne sont pas
geres par inetd, mais sont executes au demarrage du systeme et enregistres par le
portmapper. Par consequent, vous devez vous assurer qu'ils sont bien appeles apres
rpc.portmap. Generalement, on rajoute les lignes suivantes dans le script rc.inet2 :
if [ -x /usr/sbin/rpc.mountd ]; then
/usr/sbin/rpc.mountd; echo -n " mountd"
fi
if [ -x /usr/sbin/rpc.nfsd ]; then
/usr/sbin/rpc.nfsd; echo -n " nfsd"
fi

Les informations sur les proprietaires des chiers qu'un demon NFS fournit a ses
clients ne contiennent en principe que les valeurs numeriques d'utilisateur et de
groupe. Si le client et le serveur associent les m^emes valeurs aux m^emes personnes et
groupes, on dit qu'ils partagent le m^eme espace. C'est par exemple le cas lorsque vous
utilisez NIS pour distribuer les informations passwd a toutes les machines de votre
reseau.
Toutefois en certaines occasions ces valeurs ne correspondent pas. Plut^ot que de mo-
di er la con guration de l'un ou l'autre systeme, vous pouvez employer le demon
ugidd, qui s'occupera de parer au probleme. Gr^ace a l'option map daemon expliquee
plus loin, vous pouvez demander a nfsd de faire correspondre les valeurs utilisateur
et groupe du serveur a celles du client, a condition que ugidd soit en fonctionnement
sur ce dernier.
Il s'agit d'un serveur RPC qui est lance depuis rc.inet2, exactement comme nfsd et
mountd.
if [ -x /usr/sbin/rpc.ugidd ]; then
/usr/sbin/rpc.ugidd; echo -n " ugidd"
fi

11.4 Le chier exports


Pour chaque client, le serveur determine le type d'acces autorise. Cet acces est speci e
dans le chier /etc/exports, qui liste les repertoires partages.
Par defaut, mountd interdira a tout le monde de monter des repertoires de l'h^ote local,
ce qui est une attitude plut^ot sensee. Pour autoriser un ou plusieurs h^otes a monter
11.4. Le chier exports 165

un repertoire par NFS, ce repertoire doit ^etre exporte, c'est-a-dire indique dans le
chier exports. En voici un exemple :
# Fichier exports de kro.bibine.com
/home trappiste(rw) gueuze(rw) leffe(rw)
/usr/X11R6 trappiste(ro) gueuze(ro) leffe(ro)
/usr/TeX trappiste(ro) gueuze(ro) leffe(ro)
/ trappiste(rw,no_root_squash)
/home/ftp (ro)

Chaque ligne de nit un repertoire et les h^otes autorises a le monter. Les noms de
machines sont en general pleinement quali es, mais peuvent egalement contenir les
caracteres generiques * et ?, qui ont la m^eme signi cation que dans le shell Bourne.
Par exemple, lab*.foo.com correspondra aussi bien a lab01.toto.com qu'a la-
beur.toto.com. Si aucun nom de machine n'est precise, comme pour le repertoire
/home/ftp dans l'exemple ci-dessus, n'importe quel h^ote pourra monter ce volume.
Lorsqu'il veri e les permissions pour un client donne, mountd recherchera son nom
par l'appel gethostbyaddr(2). Avec le DNS, cet appel retournera le nom canonique,
aussi vous devez faire attention a ne pas utiliser d'alias dans le chier exports. Sans
DNS, le nom retourne est le premier trouve dans le chier hosts, qui correspond a
l'adresse du client.
Le nom de machine est suivi par une liste facultative de drapeaux, separes par des
virgules, entre parentheses. Ils peuvent prendre les valeurs suivantes :
insecure Autorise des acces non authenti es.
unix-rpc Demande l'authenti cation RPC. Cela necessite simplement que la
requ^ete provienne d'un port reserve (un port dont le numero est
inferieur a 1024). C'est l'option par defaut.
secure-rpc Demande l'authenti cation RPC securisee. Ce n'est pas encore im-
plemente ; consultez la documentation de Sun pour plus de details.
kerberos Demande l'authenti cation Kerberos. Cette option n'est pas encore
implementee ; consultez la documentation du MIT pour plus de de-
tails sur le systeme Kerberos.
root squash Il s'agit d'une securite interdisant aux superutilisateurs des machines
speci ees tout acces special, en transformant les requ^etes de l'utili-
sateur 0 sur le client en utilisateur 65534 (-2) sur le serveur, qui
correspond en principe a l'utilisateur nobody.
no root squash Ne change rien pour les requ^etes de superutilisateurs. C'est l'option
par defaut.
ro Monte la hierarchie de chiers en lecture seule. C'est l'option par
defaut.
166 Chapitre 11. NFS, le systeme de chiers par reseau
rw Monte la hierarchie de chiers en lecture et ecriture.
link relative Convertit les liens symboliques absolus (dont le contenu commence
par un slash) en liens relatifs en ajoutant ../ autant de fois que ne-
cessaire pour aller du repertoire contenant le lien a la racine sur le
serveur. Cette option n'a de sens que lorsque la totalite d'un systeme
de chiers d'un h^ote est monte ; autrement certains liens peuvent
pointer nulle part, ou pis, vers des chiers vers lesquels ils n'auraient
jamais d^u pointer. Cette option est en service par defaut.
link absolute Laisse tous les liens symboliques inchanges (le comportement normal
des serveurs NFS fournis par Sun).
map identity Cette option indique au serveur de considerer que le client utilise
les m^emes identi cateurs d'utilisateurs et de groupes que le serveur.
Cette opion est en service par defaut.
map daemon Indique que les clients et le serveur n'ont pas les m^emes valeurs
d'identi cation utilisateurs et groupes. Le demon nfsd construira
alors une liste de correspondance entre les deux machines en interro-
geant le demon ugidd du client.

Une erreur de syntaxe dans le chier exports sera rapportee via la (( facilite )) daemon
de syslogd, au niveau notice, chaque fois que nfsd ou mountd sont lances.
Notez que les noms de machines correspondant aux adresses IP des clients sont ob-
tenus par recherche inverse, aussi le resolver doit ^etre con gure proprement. Si vous
employez BIND et ^etes tres concernes par la securite, vous devez employer l'option
nospoof dans votre chier host.conf.

11.5 Montage automatique : l'automonteur


Il n'est quelquefois pas raisonnable de monter tous les volumes NFS dont les utili-
sateurs pourraient avoir besoin, soit en raison de leur grand nombre, soit parce que
cela prendrait trop de temps au demarrage du systeme. On peut alors employer un
automonteur. Il s'agit d'un demon qui monte automatiquement, et de facon trans-
parente, tout volume NFS lorsque c'est necessaire, et le demonte lorsqu'il n'a pas
ete utilise pendant un certain temps. L'une des possibilites les plus interessantes d'un
automonteur, c'est de pouvoir monter un certain volume depuis plusieurs endroits dif-
ferents. Par exemple, vous pouvez stocker des copies de vos programmes et chiers de
con guration X11 sur deux ou trois h^otes, et les faire utiliser par les autres machines
via NFS. Avec un automonteur, vous pouvez speci er que les trois sont a monter sur
/usr/X11R6 ; le programme tentera alors de monter n'importe lequel, jusqu'a ce que
l'un des montages reussisse.
11.5. Montage automatique : l'automonteur 167

L'automonteur couramment utilise sous Linux s'appelle amd. Il a ete ecrit par Jan-
Simon Pendry et porte sous Linux par Mitch D'Souza. La version actuelle est amd-5.3.
Le fonctionnement de amd depasse le cadre de ce guide. Pour un bon manuel, consultez
les sources ; elles contiennent un chier Texinfo avec des informations tres detaillees.
168 Chapitre 11. NFS, le systeme de chiers par reseau
169

Chapitre 12
Ma^triser Taylor UUCP
UUCP fut developpe vers la n des annees soixante-dix par Mike Lesk aux labo-
ratoires AT&T Bell pour permettre des transmissions sur les lignes telephoniques
ordinaires. Puisque la plupart des personnes desirant avoir le courrier electronique et
les News Usenet a domicile communiquent par modem, UUCP est reste tres popu-
laire. Bien qu'il en existe de tres nombreuses implementations, sur une grande variete
d'architectures et de systemes d'exploitation, elles sont toutes compatibles entre elles.
Toutefois, comme avec tout logiciel devenu (( standard )) au l des annees, il n'y a
aucun UUCP que l'on pourrait appeler (( Le UUCP )), la reference. Son evolution est
permanente depuis que la premiere version vit le jour en 1976. Actuellement, il y a
deux types qui di erent dans leur support materiel et leur con guration. Plusieurs
implementations existent pour chacun, qui comportent egalement des variantes.
L'un s'appelle UUCP Version 2, et remonte a l'implementation de Mike Lesk, David
A. Novitz et Greg Chesson en 1977. Bien que tres ancienne, cette version est en-
core souvent utilisee. Ses implementations recentes o rent beaucoup du confort des
nouvelles speci cations de UUCP.
Le second fut developpe en 1983 et on le nomme couramment BNU (Basic Networking
Utilities), ou HoneyDanBer UUCP que l'on abrege en HDB. Ce nom est derive de
celui des auteurs, P. Honeyman, D. A. Novitz et B. E. Redman. HDB a ete concu
pour parer a quelques de ciences de UUCP Version 2. Par exemple, de nouveaux
protocoles de transfert ont ete rajoutes, et le repertoire de spoule est divise pour que
chaque site avec lequel il y a du tra c UUCP possede son propre sous-repertoire.
L'implementation de UUCP qui est actuellement distribuee avec Linux est Taylor
UUCP 1.05 1 , c'est celle dont nous allons traiter dans ce chapitre. Taylor UUCP
version 1.05 est apparu en mai 1994. En plus des chiers de con guration traditionnels,
il peut aussi ^etre compile pour utiliser un nouveau style, la (( con guration Taylor )).
1 E crit par Ian Taylor, Copyright
: c 1993-1994
170 Chapitre 12. Ma^triser Taylor UUCP
Si vous ne disposez que de la version precedente (1.04), les di erences etant minimes
vous devriez pouvoir utiliser les renseignements contenus dans ce chapitre pour le
con gurer.
Dans la plupart des distributions de Linux, Taylor UUCP est fourni precompile pour
la compatibilite BNU, ou Taylor, ou les deux. La methode Taylor est bien plus exible
et probablement plus facile a comprendre que les chiers de con guration BNU parfois
assez obscurs, c'est donc celle-ci que nous allons decrire dans ce guide.
Le but de ce chapitre n'est pas de vous donner une description exhaustive de tout ce
que peut faire UUCP, mais plut^ot de vous apporter de bonnes bases pour l'installation
d'un site UUCP qui fonctionne. La premiere section est une petite introduction sur la
maniere dont UUCP implemente le transfert de chiers et l'execution de commandes
a distance. Si tout cela n'est pas nouveau pour vous, vous pouvez aller directement a
la section (( Fichiers de con guration )), qui detaille les di erents chiers utilises pour
la con guration de UUCP.
Nous considererons toutefois que vous connaissez les programmes utilisateurs mis en
jeu dans UUCP. Ce sont principalement uucp et uux ; vous en trouverez la description
dans le manuel en ligne.
A c^ote de ces deux commandes accessibles a tout le monde, UUCP en contient beau-
coup d'autres qui ne sont destinees qu'aux t^aches administratives. Elles servent a
suivre le tra c UUCP, supprimer les vieux chiers de trace, ou calculer des statis-
tiques. Aucun de ces programmes ne sera decrit ici car ils ne concernent pas direc-
tement le fonctionnement de UUCP. De plus, ils sont tres bien documentes et tres
simples a utiliser. Il y a neanmoins une troisieme categorie de programmes, compre-
nant le cur de UUCP : uucico (ou cico signi e copy-in copy-out, le programme de
communications), et uuxqt, qui execute les commandes recues des systemes distants.
Ils feront l'objet de ce chapitre.
Ceux qui ne trouveront pas ici tous les renseignements dont ils ont besoin devront
se reporter a la documentation fournie avec Taylor UUCP. Elle est composee d'un
ensemble de chiers Texinfo qui decrivent la con guration selon le schema Taylor, et
est extr^emement complete.
Si vous voulez utiliser la con guration BNU (ou m^eme la Version 2), il existe un excel-
lent livre sur le sujet : Managing UUCP and Usenet ([ManagUUCP]). Vous trouverez
egalement des informations tres utiles dans le document Linux UUCP-HOWTO de
Vince Skahan, poste regulierement dans comp.os.linux.answers, et disponible en
version francaise sur les sites di usant Linux en France.
Usenet comprend egalement un forum dedie aux discussions sur UUCP, qui s'ap-
pelle comp.mail.uucp. Si vous avez des questions speci ques a Taylor UUCP, c'est
l'endroit ideal pour les poser, plut^ot que dans les groupes dedies a Linux.
12.1. Transferts UUCP et execution a distance 171

12.1 Transferts UUCP et execution a distance


La notion de job 2 est vitale pour la comprehension d'UUCP. Chaque transfert de-
mande par un utilisateur via uucp ou uux s'appelle un job. Il est constitue d'une
commande a executer sur le systeme distant, et un ensemble de chiers a transferer
entre les deux sites. L'une ou l'autre de ces deux parties peut ^etre absente.
Comme exemple, considerons que vous avez tape la commande suivante sur votre
machine, qui demande a UUCP de copier le chier netguide.ps sur la machine pablo,
puis execute la commande lpr a n de l'imprimer :
$ uux -r pablo!lpr !netguide.ps

UUCP n'appelle generalement pas immediatement le systeme distant pour executer


un job (sinon vous pourriez tres bien utiliser kermit). Il stocke la description du travail
a e ectuer, ce qui s'appelle spouler. Le repertoire dans lequel ces jobs sont temporai-
rement stockes s'appelle par consequent le repertoire de spoule, et est generalement
/var/spool/uucp. Dans notre exemple, la description de job contiendrait des infor-
mations concernant la commande a e ectuer (lpr), l'utilisateur ayant demande cette
execution, et quelques autres renseignements. En plus de cela, UUCP doit stocker le
chier d'entree, netguide.ps.
Le nom et l'emplacement exact de ces chiers spoules peuvent varier, en fonction des
options de compilation. En mode compatible HDB, UUCP les met en general dans un
sous-repertoire de /var/spool/uucp du nom du site distant. En mode Taylor, il creera
des sous-repertoires sous le repertoire de spoule speci que au site pour les di erents
types de chiers.
A intervalles reguliers, UUCP appelle le systeme distant. Lorsqu'une connexion est
etablie, il transfere les chiers decrits dans le job, plus tout chier d'entree. Les com-
mandes ne seront pas executees immediatement, mais juste apres que la connexion
est terminee. C'est le r^ole de uuxqt, qui prend egalement soin de renvoyer tout job
destine a un autre site.
Pour distinguer les jobs les plus importants des autres, UUCP associe un grade a
chacun. Il s'agit d'une simple lettre, allant de 0 a 9, de A a Z et de a a z, par ordre
de priorite decroissante. Le courrier est generalement spoule avec le grade B ou C,
alors que les News Usenet le sont avec le grade N. Plus le grade est eleve, plus le job
sera transfere avant les autres. Ces grades peuvent ^etre assignes par l'option -g lors
de l'appel de uucp ou uux.
Vous pouvez aussi interdire le transfert en dessous d'un certain grade a certaines
heures ; c'est le grade maximum de spoule autorise pendant une communication, dont
la valeur par defaut est z. Notez que la terminologie est assez ambigue ici : un chier
ne sera transfere que si le grade est egal ou superieur a cette valeur.
2 Le mot job est mis a toutes les sauces en informatique ; il serait vain de vouloir en imposer un
:
autre, plus francais.
172 Chapitre 12. Ma^triser Taylor UUCP
12.1.1 Fonctionnement interne de uucico
} Pour comprendre pourquoi uucico a besoin de conna^tre certaines choses, une breve
description de la facon dont il se connecte a un systeme distant sera tres utile.
Lorsque vous executez uucico -s systeme depuis la ligne de commandes, le programme
doit d'abord realiser une connexion physique avec le correspondant. La methode de-
pend du type de liaison a employer ; dans le cas d'une ligne telephonique par exemple,
il doit trouver un modem, et le faire numeroter. Sur TCP, il doit appeler gethostby-
name(3) pour convertir le nom en adresse IP, trouver quel port ouvrir, et lier cette
adresse a la socket correspondante.
Une fois la connexion etablie, il faut mettre en uvre une procedure d'autorisation
d'acces. Elle est generalement constituee du classique couple login/mot de passe, et
realisee par les programmes habituels getty/login, ou bien lorsqu'il s'agit de sockets
TCP, par uucico lui-m^eme. Si l'autorisation d'entree est accordee, la machine appelee
lance alors uucico. Sur la machine qui est appelante, le programme uucico est appele
ma^tre, et celui de la machine appelee se nomme esclave.
Ensuite, vient le handshake (poignee de main ; ce qui est assez realiste puisque les
deux programmes se presentent l'un a l'autre) : le ma^tre annonce son nom ainsi que
certaines autres informations, l'esclave veri e les permissions qui lui sont accordees.
Puis, si ce test est valide, prend place la veri cation d'un numero de sequence d'ap-
pel. Cette procedure facultative permet de maintenir sur chaque site, un compte des
connexions reussies, ces comptes sont alors compares. S'ils ne correspondent pas, la
connexion est refusee ; ce qui permet d'eliminer les imposteurs.
En n, les deux uucico tentent de se mettre d'accord sur un protocole de transfert,
parmi ceux qu'ils ont en commun. C'est lui qui va determiner la facon de transferer
les donnees, tester les erreurs, gerer les retransmissions en cas de probleme, etc. Il
est necessaire de disposer de plusieurs protocoles en raison des di erents types de
connexions possibles. Par exemple, les lignes de telephones necessitent un protocole
tres (( s^ur )), car ce sont des liaisons de qualite souvent mediocre ; alors que les trans-
missions par TCP sont par essence ables et peuvent faire appel a un protocole moins
regardant, et plus ecace.
Apres ce premier dialogue, la transmission peut commencer. Chaque c^ote met en
route le pilote du protocole choisi, qui peut eventuellement e ectuer une sequence
d'initialisation speci que supplementaire.
Le ma^tre envoie tous les chiers destines au systeme esclave en attente dans la queue,
et dont le grade est susant. Lorsqu'il a termine, il informe l'esclave qu'il a ni son
travail et que la communication peut ^etre coupee. A ce moment, les r^oles s'inversent : le
ma^tre devient esclave, et reciproquement. Le nouveau ma^tre envoie alors ses chiers,
puis nalement les deux uucico s'echangent des messages indiquant la n des jobs et
ferment la connexion.
Nous n'entrerons pas plus dans le detail dans ce guide : consultez soit les sources,
soit tout bon ouvrage traitant du sujet. Vous trouverez aussi un document poste
12.2. Fichiers de con guration 173

regulierement dans comp.mail.uucp sous le nom de uucp internals, decrivant chaque


protocole supporte par Taylor UUCP.

12.1.2 La ligne de commandes de uucico


Cette section decrit les options les plus importantes supportees par le programme
uucico. Sa page de manuel contient la liste complete, consultez-la si besoin est.

-s syst
eme Appelle systeme, sauf en cas de restriction horaire.
-S syst
eme Appel force de systeme, quelles que soient les conditions.
-r1 Lance uucico en mode ma^tre. C'est le mode par defaut avec les
options -s et -S. Utilisee seule, cette option provoque l'appel tour a
tour de tous les systemes connus, sauf en cas de restriction.
-r0 Lance uucico en mode esclave. C'est le mode par defaut lorsque au-
cune option -s ou -S n'est donnee. Dans ce mode, soit l'entree et la
sortie standard sont considerees comme etant connectees a un port
serie, soit le port TCP doit ^etre precise par l'option -p.
-x type, -X type
Met en route les traces de deboguage du type speci e. Plusieurs types
peuvent ^etre donnes sous forme de liste separee par des virgules.
Les types suivants sont valides : abnormal, chat, handshake, uucp-
proto, proto, port, con g, spooldir, execute, incoming et outgoing. Le
mot cle all les valide tous. Pour rester compatible avec les autres
implementations de UUCP, on peut aussi speci er un nombre, ce qui
valide alors le deboguage pour les n premiers items de cette liste.
Ces traces sont enregistrees dans le chier Debug, situe dans le re-
pertoire /var/spool/uucp.

12.2 Fichiers de con guration


A la di erence des protocoles de transfert ordinaires, UUCP est destine a fonction-
ner entierement automatiquement. Une fois qu'il est con gure, il ne necessite pas
d'intervention quotidienne de l'administrateur systeme. Les informations necessaires
pour ces transferts automatiques tiennent dans deux ou trois chiers de con guration
residant dans le repertoire /usr/lib/uucp, utilises surtout lors d'appels sortants.
174 Chapitre 12. Ma^triser Taylor UUCP
12.2.1 Petite introduction a Taylor UUCP
Dire que la con guration de UUCP est dicile est un euphemisme. C'est reellement
un sujet tou u, et le format souvent complexe et peu lisible des chiers de con gura-
tion ne facilite pas les choses (bien que le format Taylor soit presque facile a lire en
comparaison de ceux de HDB et Version 2).
Pour vous donner une idee de la maniere dont tous ces chiers interagissent, nous vous
presenterons les plus importants et donnerons des exemples pratiques. Nous n'allons
pas entrer dans le detail tout de suite ; ce sera le r^ole de chaque section de ce chapitre.
Si vous desirez con gurer UUCP sur votre machine, la meilleure solution sera de partir
des exemples et de les adapter graduellement. Vous pouvez choisir soit ceux qui vont
suivre, soit ceux fournis avec votre distribution de Linux.
Tous les chiers decrits ici resident dans /usr/lib/uucp ou un sous-repertoire. Quelques
distributions contiennent des binaires supportant a la fois les con gurations HDB et
Taylor, et utilisent di erents sous-repertoires pour chacune ; il y aura en principe un
chier README dans /usr/lib/uucp.
Pour que UUCP fonctionne correctement, ces chiers doivent appartenir a l'utilisateur
uucp. Certains contenant des mots de passe et des numeros de telephone, ils doivent
avoir une permission d'acces de 600 3.
Le chier de con guration central s'appelle /usr/lib/uucp/con g, et determine les
parametres generaux. Le plus important d'entre eux (et pour l'instant, le seul) est le
nom de votre site UUCP. A (( La biere virtuelle )), leur passerelle UUCP est la machine
gueuze :
# /usr/lib/uucp/config - Fichier principal de configuration UUCP
hostname gueuze

Le suivant est le chier sys. Il contient toutes les informations speci ques aux sites
auxquels vous ^etes relies par UUCP. Cela comprend le nom des machines et des infor-
mations sur le lien lui-m^eme, comme le numero de telephone, par exemple. Une entree
typique pour un site connecte par modem que nous appellerons pablo ressemblerait
a ceci :
# /usr/lib/uucp/sys - liste des voisins UUCP
# systeme: pablo
system pablo
time Any
phone 123-456
port serial1
speed 38400
chat ogin: gueuze ssword: lorca

3 Bien que la plupart des commandes UUCP doivent ^etre setuid uucp, vous devez faire tres
:
attention a ce que le programme uuchk ne le soit pas. Sinon, tous les utilisateurs auraient acces aux
mots de passe m^eme si les chiers ont un mode de 600.
12.2. Fichiers de con guration 175

Le mot cle port designe le port a utiliser, et time les heures auxquelles il peut ^etre
appele. La ligne chat decrit le script de dialogue necessaire pour permettre a uucico
d'entrer dans le systeme pablo ; nous reviendrons sur ces scripts un peu plus loin. La
ligne port indique simplement le nom d'une entree dans le chier port. Vous pouvez y
mettre le nom qui vous pla^t, tant que cette entree existe.
Ce chier port contient les informations speci ques a la liaison. Pour les modems, il
decrit le chier de peripherique a utiliser, la gamme des vitesses supportees, et le type
de numeroteur connecte. L'entree ci-dessous decrit /dev/cua1 (COM 2), sur lequel est
connecte un modem NakWell capable de supporter la vitesse de 38 400 bps. Le nom
du port est choisi de maniere a correspondre a celui indique dans le chier sys.
# /usr/lib/uucp/port - ports UUCP
# /dev/cua1 (COM2)
port serial1
type modem
device /dev/cua1
speed 38400
dialer nakwell

Les informations relatives au systeme numeroteur se trouvent dans un troisieme -


chier, dial. Pour chaque type, il contient la sequence de commandes necessaires pour
appeler un site, avec un numero de telephone donne. La encore, il s'agit d'un script
de dialogue. Par exemple, l'entree pour le numeroteur NakWell pourrait ^etre celle-ci :
# /usr/lib/uucp/dial - numeroteurs
# Modems NakWell
dialer nakwell
chat "" ATZ OK ATDT\T CONNECT

La ligne commencant par chat indique la sequence de commandes a envoyer au modem,


avec les reponses a attendre, pour l'initialiser et le faire telephoner. Le programme
uucico remplacera la sequence \T par le numero de telephone.
Pour vous donner une idee de la maniere dont uucico traite ces chiers de con gura-
tion, considerons que vous avez tape la commande :
$ uucico -s pablo

La premiere chose que fait uucico est de chercher pablo dans le chier sys. Il voit
alors dans l'entree correspondante qu'il doit utiliser le port serial1 pour etablir la
connexion. Le chier port lui indique qu'il s'agit d'un port sur lequel est connecte un
modem NakWell.
Alors, uucico cherche dans le chier dial une entree decrivant ce modem NakWell, et
lorsqu'il l'a trouvee, ouvre le port serie /dev/cua1 et execute le dialogue de numero-
tation : ici, il envoie ATZ, attend la reponse OK, etc. Lorsqu'il rencontre la cha^ne \T,
il lui substitue le numero de telephone (123{456) extrait du chier sys.
176 Chapitre 12. Ma^triser Taylor UUCP

Le chier sys
Le chier port
system pablo

port serial1
port serial1
speed 38400
type modem
...
speed 38400
device /dev/cua1
dialer nakwell
...

dialer nakwell
chat "" ATZ ..
chat-fail BUSY
...

Le chier dial

Fig. 12.1 - Interaction des chiers de con guration de Taylor UUCP.


12.2. Fichiers de con guration 177

Apres que le modem a retourne CONNECT, la connexion est etablie et le dialogue modem
est termine ; uucico retourne alors au chier sys et execute le dialogue d'entree dans
le systeme. Dans notre exemple, il attendra l'invite login: puis enverra son nom
d'utilisateur (neruda), attendra password: et repondra par le mot de passe, lorca.
Ensuite, la machine appelee lancera son propre uucico. Les deux programmes entreront
dans la phase de handshake decrite dans la section precedente.
La gure 12.1 symbolise les dependances entre les divers chiers de con guration.

12.2.2 Informations a posseder au prealable


Avant de commencer a rediger votre con guration, vous devez rassembler certaines
informations qui vont ^etre necessaires a UUCP.
Tout d'abord, vous devrez determiner sur quel port serie votre modem est connecte.
Generalement, les ports que MS-DOS nomme COM1 a COM4 correspondent sous
Linux aux peripheriques /dev/cua0 a /dev/cua3. Beaucoup de distributions creent
un lien nomme /dev/modem vers le peripherique approprie, et con gurent certains
programmes de communication (kermit, minicom, seyon, etc.) pour qu'ils utilisent ce
port. Dans ce cas, vous devrez aussi utiliser /dev/modem pour UUCP.
La raison de ce lien, outre la facilite de memorisation du nom, est que les programmes
e ectuant des appels sortants utilisent parfois des chiers de verrouillage pour signa-
ler l'occupation d'un port serie. Les noms de ces chiers sont la concatenation de la
cha^ne LCK.. et du nom du peripherique, par exemple LCK..cua1. Si les programmes
utilisaient des noms di erents pour acceder aux m^emes peripheriques, ils ne reconna^-
traient pas les chiers de verrouillage des autres applications et le resultat serait tres
hasardeux. Lorsque l'on programme les appels UUCP par une entree crontab, il faut
absolument que cette convention soit respectee.
Pour plus de details sur la con guration des ports serie, consultez le chapitre 4.
Ensuite, vous devrez determiner a quelle vitesse votre modem et Linux communi-
queront. Il faudra utiliser la vitesse de transfert e ective maximale que vous esperez
atteindre. Cette vitesse peut ^etre largement superieure a celle a laquelle la connexion
se fait : par exemple, beaucoup de modems envoient et recoivent des donnees a 2 400
bps, mais avec les protocoles de compression comme V.42bis, la vitesse de transfert
peut atteindre 9 600 bps. La documentation fournie avec votre appareil vous rensei-
gnera mieux sur ce sujet.
Bien entendu, il vous faudra vous procurer les numeros de telephone des systemes
a appeler. Vous aurez egalement besoin de l'identite et de l'eventuel mot de passe a
utiliser pour entrer dans ces machines 4 .
4 Si vous comptez juste essayer UUCP a titre experimental, procurez-vous le numero de telephone
:
d'un site archive pres de chez vous. Notez le login et le mot de passe ; ils sont publics pour que tout
le monde puisse faire des telechargements anonymement. Dans la plupart des cas, ce sont des noms
du genre uucp/uucp ou nuucp/uucp.
178 Chapitre 12. Ma^triser Taylor UUCP
Il vous faudra aussi savoir exactement comment entrer sur le systeme convoite. Devez-
vous presser la touche BREAK avant que l'invite n'apparaisse ? Est-ce qu'il ache
login: ou bien user: ? Ces renseignements sont indispensables pour r ediger le script
de dialogue. Si vous ne savez pas, ou si le script que vous utilisez habituellement
ailleurs ne marche pas, appelez le site avec un programme de terminal ordinaire comme
kermit ou minicom et notez exactement ce que vous devez taper.

12.2.3 Le nom du site


Tout comme avec le reseau TCP/IP, votre machine doit avoir un nom pour UUCP.
Tant que vous ne faites que des transferts avec des sites que vous appelez directe-
ment, ou sur un reseau local, ce nom n'a pas besoin de correspondre a un quelconque
standard 5 .
Toutefois, si vous devez utiliser UUCP pour du courrier electronique ou les News Use-
net, vous devez absolument utiliser un nom valide, par exemple en vous enregistrant
dans les cartes UUCP. Le projet de cartes UUCP est decrit dans le chapitre 13.
Beaucoup choisissent de prendre la premiere composante de leur nom pleinement
quali e comme nom UUCP. Supposons que l'adresse de votre machine soit mai-
son.ici.com ; votre nom UUCP serait alors maison. C'est un peu comme si les sites
UUCP se connaissaient entre eux par leur prenom. Bien s^ur, vous pouvez choisir un
nom totalement di erent de votre nom pleinement quali e, c'est un choix.
Neanmoins, assurez-vous de ne jamais utiliser ce nom qui n'est pas quali e dans les
adresses de courrier electronique, sauf s'il est enregistre dans les cartes UUCP comme
nom ociel 6 . Au mieux, un courrier expedie a un site UUCP non enregistre partira
aux oubliettes. Si vous utilisez un nom deja existant, le courrier sera route a ce site
et causera des maux de t^ete sans n a son administrateur.
Par defaut, UUCP utilise le nom positionne par hostname comme nom de site UUCP.
Il est en general initialise dans le script /etc/rc.local. Si le nom choisi doit ^etre di erent,
vous devrez utiliser l'option hostname du chier de con guration pour indiquer ce cas
a uucico ; nous allons voir ca bient^ot.

5 La seule limitation est qu'il ne doit pas depasser sept caracteres, a n de ne pas g^ener certaines
:
implementations fonctionnant sur des systemes d'exploitation imposant de telles limites. Les noms
plus longs sont souvent tronques par UUCP. Quelques versions les limitent m^eme a six caracteres !
6 Le projet de cartes UUCP enregistre tous les noms d'h^otes UUCP du monde entier et s'assure
:
qu'ils sont bien tous uniques. En ce qui concerne la France, ce projet est abandonne depuis 1994
et il en va de m^eme dans de plus en plus de pays ; le seul moyen d'obtenir une adresse valide est
maintenant de passer par un domaine gere par le DNS.
12.2. Fichiers de con guration 179

12.2.4 Fichiers de con guration Taylor


Revenons a notre con guration. Taylor UUCP obtient ses informations depuis les
chiers suivants :

con g Il s'agit du chier de con guration principal. Vous pouvez y de nir
votre nom de site UUCP.
sys Ce chier decrit tous les sites connus de vous. Pour chacun, il speci e
son nom, a quelles heures il est possible de l'appeler, quel numero
de telephone composer (si necessaire), quel peripherique utiliser, et
comment se connecter.
port Contient les entrees decrivant chaque port disponible, avec la vitesse
supportee et le numeroteur a utiliser.
dial Decrit les numeroteurs employes pour etablir une communication
telephonique.
dialcode Contient les expansions pour les codes de numerotation symboliques.
call Contient le nom d'utilisateur et le mot de passe a employer pour se
connecter a un systeme. Rarement utilise.
passwd Contient les noms et mots de passe que les systemes doivent prendre
pour se connecter chez vous. Ce chier n'est utilise que lorsque uucico
s'occupe lui-m^eme de cette operation.

Ces chiers de con guration sont principalement composes de lignes contenant des
paires de mots cles/valeurs. Un signe diese introduit un commentaire qui s'etend
jusqu'a la n de la ligne. Pour utiliser ce caractere autrement que comme commentaire,
il faut l'echapper par un backslash, c'est-a-dire le coder comme ceci : \#
Vous pouvez encore ajuster un bon nombre d'options gr^ace a ces chiers. Nous ne
detaillerons pas tous les parametres possibles, mais uniquement les plus importants ;
vous devriez ensuite ^etre capable de faire fonctionner une liaison UUCP par modem.
Quelques sections supplementaires decriront les modi cations a e ectuer pour utiliser
UUCP sur reseau TCP/IP ou par une ligne serie directe. Les documents Texinfo qui
accompagnent le code source de Taylor UUCP decrivent tout cela en detail.
Votre con guration terminee, vous pouvez la tester a l'aide de l'utilitaire uuchk (situe
dans /usr/lib/uucp). Il lit les chiers que vous avez redige avec soin et ache un
rapport detaille des valeurs qui seront utilisees pour chaque systeme.
180 Chapitre 12. Ma^triser Taylor UUCP
12.2.5 Options de con guration generale | le chier con g
Vous n'aurez en principe jamais besoin de ce chier pour autre chose que votre nom
UUCP. Par defaut, UUCP prend le nom que vous positionnez par la commande host-
name, mais il est possible de le preciser ici (s'il doit ^etre di erent, par exemple). Voici
un exemple de chier con g :
# /usr/lib/uucp/config - Fichier de configuration principal
hostname gueuze

Il est possible de positionner un certain nombre de parametres divers dans ce chier,


comme le nom du repertoire de spoule, ou les droits d'acces pour l'entree UUCP
anonyme. Ce dernier cas sera traite dans une section ulterieure.

12.2.6 Informations sur les sites UUCP voisins | le chier


sys
Le chier sys decrit les machines qui sont connues de vous. Une entree est introduite
par le mot cle system ; les lignes suivantes, jusqu'a la prochaine directive system,
detaillent les parametres speci ques a ce site. En general, une telle entree de nit le
numero de telephone et le script de dialogue.
Les parametres precedant la toute premiere ligne system initialisent des valeurs par
defaut utilisees pour tous les sites. Vous y mettrez en general les parametres par
defaut des protocoles, s'il y a lieu.
Nous allons maintenant voir en detail les champs les plus importants de ce chier sys.

Systeme distant
Le mot cle system designe le systeme distant. Vous devez speci er le nom correct, et
non pas un alias de votre imagination, car uucico le veri era par rapport a ce que
cette machine lui indiquera lorsque vous serez connecte 7.
Chaque nom de systeme ne doit appara^tre qu'une fois. Si vous desirez plusieurs con -
gurations pour une m^eme machine (plusieurs numeros de telephone, par exemple),
vous pouvez employer le mot cle alternate, decrit plus loin.

Numero de telephone
Si le systeme distant doit ^etre atteint par une ligne telephonique, le champ phone
indique le numero que le modem doit appeler. Il peut contenir plusieurs codes sym-
boliques qui seront interpretes par la procedure de numerotation de uucico ; un signe
7 Les anciennes versions de UUCP Version 2 n'annoncent pas leur nom lorsqu'elles sont appelees ;
:
neanmoins les implementations recentes le font, ainsi que Taylor UUCP.
12.2. Fichiers de con guration 181

d'egalite (=) signi e d'attendre une seconde tonalite, et un tiret (-) genere une pause
d'une seconde. Par exemple, certaines installations telephoniques necessitent une at-
tente entre certains pre xes de numerotation speciaux et le numero a appeler 8 .
Toute cha^ne alphabetique peut ^etre utilisee pour cacher des informations dependantes
du site, comme des pre xes d'appel. Ces cha^nes seront remplacees par le numero
indique dans le chier dialcode. Supposons que vous avez un chier dialcode comme
celui-ci :
# /usr/lib/uucp/dialcode - dialcode translation
Sirius 024881
Pluton 035119

Avec ces translations, vous pouvez utiliser un numero de telephone comme Pluton4722
dans le chier sys, ce qui rend les choses un peu plus lisibles.

Port et vitesse
Les options port et speed servent respectivement a selectionner le peripherique a utiliser
pour l'appel et la vitesse maximale a laquelle il doit ^etre initialise. Une entree system
peut utiliser soit l'une, soit l'autre, ou les deux options ensemble. Lors de la recherche
d'un peripherique dans le chier port, seuls ceux qui ont un nom correspondant et/ou
une vitesse sont selectionnes.
Generalement, l'option speed est susante. Si vous n'avez qu'un port serie de ni
dans port, uucico prendra toujours celui-la de toute facon ; il sut donc d'indiquer a
quelle vitesse l'utiliser. Si vous avez plusieurs modems, il n'est pas non plus necessaire
d'indiquer un port particulier : si uucico trouve plusieurs possibilites, il essaiera tour
a tour chaque peripherique jusqu'a ce qu'il en trouve un qui soit libre.

Le script de dialogue
Nous avons deja rencontre ce script de dialogue, qui indique a uucico comment entrer
sur le systeme distant. Il consiste en une liste de cha^nes de caracteres attendues
et envoyees par le processus uucico local. Les cha^nes a attendre et a envoyer sont
inserees alternativement, et uucico rajoute automatiquement un retour-chariot (\r) a
la n de chaque envoi. Ainsi, un script de dialogue simple pourrait ressembler a ceci :
ogin: gueuze ssword: grqt22

Vous noterez que les cha^nes a attendre ne sont pas indiquees entierement. Cela permet
de s'assurer que, par exemple, Login: sera equivalent a login:, au cas ou.
8 La plupart des installations telephoniques privees necessitent que vous composiez le numero
:
0 ou 9 pour obtenir l'exterieur. On nous a indique que cela s'appelait un code d'acces secret. Sans
rire...
182 Chapitre 12. Ma^triser Taylor UUCP
Il est aussi possible d'obtenir une sorte d'execution conditionnelle avec uucico, dans le
cas ou le getty de la machine distante a besoin d'^etre recycle ou reinitialise avant qu'il
n'ache une invite. Pour cela, vous pouvez attacher un script secondaire a une cha^ne
d'attente, constitue de tirets. Ce script secondaire n'est execute que si l'attente echoue.
Une utilisation possible consiste a envoyer un BREAK si le site distant n'ache aucune
invite de login. L'exemple qui suit propose un script de dialogue general, qui devrait
aussi fonctionner s'il faut envoyer un retour-chariot pour reveiller un peu la machine
appelee. Le premier argument vide "" indique qu'il ne faut rien attendre et envoyer
directement la prochaine cha^ne de caracteres.
"" \n\r\d\r\n\c ogin:-BREAK-ogin: gueuze ssword: grqt22

Certaines sequences speciales peuvent appara^tre dans le script de dialogue. La liste


qui suit est un extrait des caracteres valides dans les cha^nes d'attente :
"" La cha^ne vide. Elle indique a uucico de ne rien attendre, et de conti-
nuer avec la prochaine cha^ne a envoyer.
\t Le caractere de tabulation.
\r Le caractere retour-chariot.
\s Le caractere espace. Vous en aurez besoin pour inserer des espaces
dans une cha^ne de dialogue.
\n Le caractere de saut de ligne.
\\ Le caractere backslash (\).

Sur les cha^nes a envoyer, les sequences d'echappement suivantes sont valides, en plus
des precedentes:
EOT Caractere de n de transmission (^D).
BREAK (( Caract ere )) Break.
\c Suppression du rajout automatique du retour-chariot en n de cha^ne.
\d Pause d'une seconde.
\E Valide le test d'echo. Dans ce mode, uucico attend que l'echo de tout
ce qu'il ecrit lui revienne avant de continuer le dialogue. C'est surtout
utile pour les dialogues avec les modems (que nous rencontrerons plus
loin). Par defaut, ce mode est hors service.
\e Supprime le test d'echo.
12.2. Fichiers de con guration 183

\K Identique a BREAK.
\p Pause d'une fraction de seconde.

Entrees alternatives
Il est parfois necessaire d'avoir plusieurs entrees pour un m^eme systeme, par exemple
s'il peut ^etre joint par plusieurs lignes. Avec Taylor UUCP, vous pouvez realiser cela
en de nissant des entrees alternatives, par le mot cle alternate.
Une entree alternative conserve tous les parametres de l'entree systeme principale et
ne modi e que ceux qui y sont expressement indiques. Elles sont placees a l'interieur
d'une entree systeme et reperees par le mot alternate.
Pour utiliser deux numeros de telephone pour la machine pablo, il sut de modi er
son entree dans le chier sys de la maniere suivante :
system pablo
phone 123-456
... entr
ees comme prec
edemment ...
alternate
phone 123-455

En appelant pablo, uucico telephonera d'abord au 123-456, et si l'appel echoue, il


essaiera l'alternative. Ici, cette entree alternative ne modi e que le numero de tele-
phone.

Restriction des horaires d'appel


Taylor UUCP o re plusieurs facons de restreindre les horaires d'appel d'un systeme
distant. Ces restrictions peuvent correspondre a l'ouverture d'un service, ou aux tarifs
telephoniques. Notez qu'il est toujours possible de passer outre en utilisant l'option
-S ou -f de uucico.
Par defaut, Taylor UUCP interdira les connexions quelle que soit l'heure, il faut donc
absolument indiquer les horaires autorises d'une maniere ou d'une autre dans le chier
sys. Si vous ne desirez aucune restriction, vous pouvez mettre la valeur Any dans la
ligne time.
La facon la plus simple de limiter les horaires d'appel est d'employer l'entree time,
suivie d'une cha^ne constituee d'un jour et d'une heure. Le jour peut combiner les
valeurs Mo, Tu, We, Th, Fr, Sa, Su (lundi, mardi... dimanche) ou bien Any (tous les
jours), Never (jamais), ou Wk (tous les jours de la semaine). L'heure consiste en deux
valeurs sur 24 heures, separees par un tiret. La combinaison resultante est ecrite sans
aucune espace de separation. Plusieurs jours ou horaires peuvent ^etre indiques en les
separant par des virgules.
184 Chapitre 12. Ma^triser Taylor UUCP
time MoWe0300-0730,Fr1805-2000

Cet exemple autorise les appels les lundis et mercredis de 3 heures a 7 heures 30, et
les vendredis entre 18 heures 05 et 20 heures. Lorsqu'un champ horaire s'etend apres
minuit, par exemple Mo1830-0600, cela signi e lundi, entre minuit et 6 heures du
matin et entre 18 heures 30 et minuit.
Les mots cles speciaux Any et Never signi ent respectivement que les appels pourront
avoir lieu a toute heure, ou jamais.
La commande time prend un second argument facultatif qui indique un delai entre
plusieurs tentatives, en minutes. Lorsqu'un appel echoue, uucico n'autorisera aucun
autre appel de cette machine pendant un certain temps. Par exemple, si vous speci ez
un intervalle de 5 minutes, il refusera d'appeler le systeme distant pendant 5 minutes
apres le dernier appel infructueux. Par defaut, ce temps est incremente chaque fois
qu'un appel echoue.
Le mot timegrade permet d'attacher un grade maximal a un horaire. Par exemple,
supposons que vous avez une entree comme ceci dans l'entree system :
timegrade N Wk1900-0700,SaSu
timegrade C Any

Elle autorise les jobs ayant un grade de C ou plus (generalement le courrier est spoule
avec le grade B ou C) a ^etre transferes chaque fois qu'une connexion est etablie, alors
que les News (qui ont usuellement le grade N) ne seront echangees que pendant la
nuit et les ns de semaine.
Tout comme time, la commande timegrade peut prendre un intervalle entre les tenta-
tives d'appel comme troisieme argument optionnel.
Il y a toutefois un piege ici : tout d'abord, l'option timegrade ne s'applique qu'a ce
que votre systeme envoie ; la machine distante peut toujours transferer ce qu'elle veut.
Vous pouvez employer l'option call-timegrade pour lui demander de n'envoyer que les
jobs dont le grade est d'un certain niveau ; mais il n'y a aucune garantie qu'elle obeisse
a cette requ^ete 9.
Il faut savoir aussi que le champ timegrade n'est pas teste lorsque c'est le systeme
distant qui vous appelle, et les jobs en attente seront tous transferes. Mais il peut,
bien s^ur, demander a votre uucico de se limiter a un certain grade, s'il sait le faire.

12.2.7 Peripheriques disponibles | le chier port


Le chier port renseigne uucico sur les peripheriques disponibles. Ce peut ^etre des
ports modem, aussi bien que d'autres types comme des lignes serie directes ou des
sockets TCP.
9 Si le systeme distant utilise Taylor UUCP, il obeira.
:
12.2. Fichiers de con guration 185

Il est constitue d'entrees separees commencant par le mot cle port suivi du nom qui
le designe. Ce nom peut ^etre utilise dans le chier sys, pour la declaration port. Il
n'a pas besoin d'^etre unique ; s'il y en a plusieurs, uucico les essaiera tous un par un
jusqu'a trouver le premier qui est disponible.
La commande port doit ^etre immediatement suivie par la declaration type, qui in-
dique de quel genre de port il s'agit. Les valeurs valides sont modem, direct pour les
connexions directes et tcp pour les sockets TCP. Si la commande port est absente,
c'est un modem qui sera considere par defaut.
Ici, nous ne decrirons que les ports modem ; les deux autres types feront l'objet de
sections separees un peu plus loin.
Pour les types modem et directs, vous devez speci er le peripherique a utiliser par la
directive device. C'est generalement le nom d'un chier de peripherique du repertoire
/dev, comme /dev/cua1 10 .
Dans le cas d'un modem, l'entree determine aussi le type d'appareil connecte. Di e-
rents types ou marques de modems peuvent demander une con guration particuliere;
m^eme ceux declares compatibles Hayes ne le sont pas toujours vraiment. Par conse-
quent, vous devez indiquer a uucico comment initialiser le modem et appeler le numero
de telephone desire. Taylor UUCP stocke les descriptions de tous les numeroteurs dans
le chier dial. Pour utiliser l'un deux, il faut speci er son nom par la commande dialer.
Quelquefois, vous aurez besoin d'utiliser un modem de di erentes facons, selon le ser-
vice que vous appelez. Par exemple, certains modems archaques ne comprennent rien
lorsqu'un appareil recent tente de se connecter a 14 400 bps ou plus ; ils raccrochent
la ligne au lieu d'etablir la connexion a 9 600 bps, ou moins. Lorsque vous appelez
de tels sites, vous devez con gurer votre modem di eremment pour que la commu-
nication aboutisse. Pour cela, vous aurez besoin d'une entree additionnelle dans le
chier port qui designera un numeroteur di erent. Vous pouvez donner a ce port un
nom di erent, comme par exemple serial1-lent, et la directive port dans l'entree du
systeme vieuxsite dans le chier sys.
Une meilleure methode consiste a faire la distinction des ports en fonction des vitesses
supportees. Par exemple, les deux entrees de la situation que nous venons d'evoquer
pourraient ^etre indiquees comme ceci :
# Modem NakWell; connexions hautes vitesses
port serial1 # nom du port
type modem # port modem
device /dev/cua1 # il s'agit de COM2
speed 38400 # vitesse support
ee
dialer nakwell # num
eroteur normal

# Modem NakWell; connexions basses vitesses


port serial1 # nom du name

10 Certains utilisent les peripheriques ttyS* a la place, qui sont concus specialement pour les appels
:
uniquement entrants, ce qui n'est pas une bonne idee en raison des con its possibles et de la gestion
fort di erente de ces peripheriques.
186 Chapitre 12. Ma^triser Taylor UUCP
type modem # port modem
device /dev/cua1 # il s'agit de COM2
speed 9600 # vitesse support
ee
dialer nakwell-lent # ne tente pas de connexion haute vitesse

L'entree systeme pour ce site vieuxsite indiquerait maintenant serial1 comme nom de
port, mais demanderait de ne l'utiliser qu'a 9 600 bps. Le programme uucico utilisera
alors la seconde entree automatiquement. Tous les sites restants qui ont une vitesse
de 38 400 bps dans l'entree systeme seront appeles par la premiere entree port.

12.2.8 Appeler un numero | le chier dial


Le chier dial decrit comment les di erents numeroteurs doivent ^etre utilises. Tra-
ditionnellement, UUCP ne parle pas a des modems mais a des numeroteurs pour
composer un numero de telephone, car en des temps recules la pratique courante etait
d'avoir un appareil (tres co^uteux) destine a la composition d'appels telephoniques,
servant une banque de plusieurs modems. Aujourd'hui, la plupart des modems savent
numeroter eux-m^emes, aussi cette distinction devient assez obscure.
Neanmoins, di erents numeroteurs ou modems necessitent chacun une con guration
particuliere. Vous pouvez decrire chaque type dans le chier dial, dont les entrees
commencent par la commande dialer suivie du nom du numeroteur.
L'entree la plus importante est le script de dialogue, speci e par la commande chat. Il
est similaire au script de connexion, et consiste en une sequence de cha^nes que uucico
envoie a l'appareil et les reponses qu'il doit en attendre. On s'en sert le plus souvent
pour remettre le modem a zero ou dans un etat connu avant de composer le numero ;
l'exemple qui suit montre une entree typique pour un appareil compatible Hayes :
# Modem NakWell modem; connexions hautes vitesses
dialer nakwell # nom du num
eroteur
chat "" ATZ OK\r ATH1E0Q0 OK\r ATDT\T CONNECT
chat-fail BUSY
chat-fail ERROR
chat-fail NO\sCARRIER
dtr-toggle true

Le script de dialogue commence par "", la cha^ne d'attente vide. Par consequent,
uucico enverra directement la commande ATZ, qui est la commande Hayes de remise
a zero. Il attend ensuite la reponse OK et envoie la commande suivante, qui sup-
prime l'echo local et initialise certains registres. Apres que le modem a encore une
fois repondu OK, uucico lui envoie la commande de numerotation ATDT. La sequence
d'echappement \T sera remplacee par le numero de telephone pris dans le chier sys.
Ensuite, uucico attend que le modem lui ait annonce que la connexion est etablie par
la cha^ne CONNECT.
Souvent, la communication ne peut pas s'etablir, si par exemple la ligne de l'autre
systeme est occupee. Dans ce cas, le modem renvoie un message d'erreur indiquant la
12.2. Fichiers de con guration 187

situation. Les scripts de dialogue ne sont pas capables de detecter de tels messages ;
uucico continuera l'attente jusqu'a ce que le temps imparti soit ecoule. Le chier de
trace de UUCP indiquera alors le message (( timed out in chat script )) au lieu de
la raison reelle de l'echec.
Toutefois, Taylor UUCP vous permet d'informer uucico de ces messages d'erreur par la
commande chat-fail que nous avons vue plus haut. Lorsqu'il detecte une telle situation,
il arr^ete aussit^ot l'appel, et enregistre le message dans le chier de trace de UUCP.
La derniere commande de l'exemple ci-dessus indique a UUCP de basculer l'etat de
la ligne DTR avant de commencer le dialogue. Normalement, le pilote des ports serie
monte le signal DTR (Data Terminal Ready) lorsqu'un processus ouvre le port, pour
indiquer au modem qui y est connecte que quelqu'un veut lui parler. Avec le mot
cle dtr-toggle, la DTR sera baissee, puis remontee apres un petit delai. Beaucoup de
modems modernes peuvent ^etre con gures pour reconna^tre cette manipulation et
e ectuer di erentes actions, comme raccrocher la ligne, passer en mode commandes
ou se remettre a zero 11.

12.2.9 UUCP sur TCP


Aussi absurde que cela puisse para^tre, utiliser UUCP pour transferer des donnees par
un reseau TCP/IP n'est pas une mauvaise idee du tout, particulierement lors de gros
transferts comme les News Usenet. Sur les liens TCP, les News sont generalement
echangees par le protocole NNTP, dans lequel les articles sont envoyes un par un,
sans aucune compression ou autre optimisation. Bien que parfaitement adaptes aux
grands sites possedant plusieurs sources concurrentes et connectes par des lignes tres
rapides, cette technique est tres peu ecace pour les petits sites qui recoivent leurs
donnees par des connexions tres lentes comme ISDN (NUME RIS en France). Ces sites
prefereront alors allier les avantages du reseau TCP/IP avec ceux des echanges de gros
chiers compresses comme c'est le cas par les liaisons telephoniques et UUCP.
Dans le chier sys, on indique qu'un systeme doit ^etre appele par TCP de la maniere
suivante :
system gmu
address news.groucho.edu
time Any
port tcp-conn
chat ogin: gueuze word: clouseau

La commande address donne l'adresse IP de l'h^ote ou bien son nom pleinement qua-
li e. L'entree correspondante dans le chier port sera alors :
port tcp-conn
type tcp
service 540

11 Certains modems bon marche n'apprecient pas du tout, en revanche.


:
188 Chapitre 12. Ma^triser Taylor UUCP
Cette entree indique qu'il faudra utiliser une connexion TCP lorsqu'une entree du
chier sys reference tcp-conn, et que uucico devra demander le port 540 sur le systeme
distant. Il s'agit du numero de port par defaut pour le service UUCP. Au lieu de ce
numero, vous pouvez aussi donner le nom symbolique qui lui est associe dans le chier
/etc/services, c'est en general uucpd.

12.2.10 Utiliser une connexion directe


Supposons que vous possedez une liaison specialisee reliant directement votre systeme
gueuze a la machine minus. Comme dans le cas d'un modem, vous devez rediger une
entree dans le chier sys. La commande port identi e le port serie sur lequel minus
est connectee.
system minus
time Any
port direct1
speed 38400
chat ogin: cathcart word: catch22

Dans le chier port, vous devez decrire le port serie, mais une entree dialer n'est pas
necessaire puisqu'il n'y a aucun numero de telephone a composer.
port direct1
type direct
speed 38400
device /dev/ttyS1

12.3 Les erreurs a eviter | securite sous UUCP


12.3.1 Execution de commandes
UUCP est destine a copier des chiers d'un systeme a un autre, et a demander l'exe-
cution de certaines commandes sur des machines distantes. Bien s^ur, en tant qu'ad-
ministrateur systeme vous voudrez avoir le contr^ole des droits accordes aux autres
machines : les autoriser a executer des commandes chez vous est une tres mauvaise
idee.
Par defaut, les seules commandes que Taylor UUCP autorise aux autres machines sont
rmail et rnews, qui servent a l'echange du courrier electronique et des News Usenet
par UUCP. Le chemin de recherche par defaut utilise par uuxqt est determine lors de la
compilation du programme, et contient generalement /bin, /usr/bin et /usr/local/bin.
Pour changer l'ensemble des commandes attribuees a un systeme donne, vous pouvez
utiliser le mot cle commands dans le chier sys. De m^eme, le chemin de recherche peut
12.3. Les erreurs a eviter | securite sous UUCP 189

^etre modi e par la declaration command-path. Vous pouvez par exemple autoriser la
machine pablo a executer la commande rsmtp en plus de rmail et rnews 12 :
system pablo
...
commands rmail rnews rsmtp

12.3.2 Transferts de chiers


Taylor UUCP permet aussi de ma^triser les chiers transferes. Au pis, vous pouvez
carrement les interdire, en mettant request a la valeur no ; aucun systeme ne pourra
alors demander un transfert de chiers, quelle que soit la direction. De m^eme, vous
pouvez interdire aux utilisateurs de transferer des chiers avec un systeme donne en
mettant transfer a no. Par defaut, les utilisateurs de la machine locale comme du
systeme distant sont autorises a transferer des chiers.
De plus, il est possible de con gurer les repertoires mis en jeu. Generalement, vous
restreindrez l'acces a une seule hierarchie pour les systemes distants, mais autoriserez
vos utilisateurs a envoyer des chiers depuis leur repertoire personnel. La plupart du
temps, les utilisateurs distants ne seront autorises a recevoir des donnees que dans le
repertoire public destine a UUCP, /var/spool/uucppublic. Il s'agit traditionnellement
de l'endroit ou les chiers publics sont mis a disposition, un peu comme les serveurs
FTP sur l'Internet. On l'indique souvent par le caractere tilde.
Taylor UUCP o re di erentes commandes pour con gurer les repertoires d'envoi et
de reception. Ce sont : local-send, qui spe cie la liste des repertoires depuis lesquels un
utilisateur peut envoyer des chiers ; local-receive, qui indique la liste de repertoires
dans lesquels un utilisateur peut demander a recevoir les chiers ; puis remote-send
et remote-receive, qui ont le m^eme r^ole pour un systeme distant. Voyons l'exemple
suivant :
system pablo
...
local-send /home ~
local-receive /home ~/receive
remote-send ~ !~/incoming !~/receive
remote-receive ~/incoming

La commande local-send autorise les utilisateurs de votre machine a envoyer n'importe


quel chier a partir du repertoire /home et du repertoire UUCP public de pablo. La
commande local-receive leur permet de recevoir des donnees soit dans le repertoire
receive de uucppublic, soit dans n'importe quel repertoire a partir de /home. La direc-
tive remote-send autorise pablo a demander des chiers depuis /var/spool/uucppublic,
sauf a partir de incoming et receive. C'est le point d'exclamation qui indique cette
12 Le programme rsmtp sert a delivrer le courrier electronique par lots SMTP. Nous decrirons
:
cette technique dans les chapitres consacres au courrier.
190 Chapitre 12. Ma^triser Taylor UUCP
negation a uucico. En n, la derniere ligne autorise pablo a envoyer n'importe quel
chier dans le repertoire incoming.
Le plus gros probleme des transferts UUCP est que les chiers ne peuvent ^etre recus
que si les repertoires de destination sont accessibles en ecriture par tout le monde.
Cela peut inciter certains utilisateurs a tendre des pieges a d'autres, mais il n'y a
aucun moyen d'eviter cela, a moins d'interdire purement et simplement tout transfert
de chier par UUCP.

12.3.3 Relais
UUCP o re un mecanisme permettant de demander a d'autres machines de transferer
des chiers pour vous. Cela permet par exemple de demander a la machine truc de
recuperer un chier sur bidule pour vous et de vous l'envoyer. Voici la commande
correspondante :
$ uucp -r truc!bidule!~/find-ls.gz ~/bidule.liste.gz

Cette technique faisant passer des jobs a travers plusieurs systemes s'appelle le relais,
ou encore le forwarding. Dans l'exemple ci-dessus, elle est employee car truc a un acces
UUCP sur machin, mais votre systeme n'en a pas. Mais en tant qu'administrateur,
vous devrez limiter cette possibilite sur votre systeme a quelques sites dans lesquels
vous avez une pleine con ance, pour eviter que certains ne passent par vous pour
telecharger la derniere version de X11R6 et vous ruiner en notes de telephone.
Par defaut, Taylor UUCP interdit tout relais. Pour l'autoriser a un systeme donne,
vous disposez de la commande forward ; qui speci e une liste de sites qui auront le droit
de vous demander de ramener des chiers pour eux. Par exemple, l'administrateur
du systeme truc devra ajouter la ligne suivante dans son chier sys pour autoriser
pablo a demander des chiers sur la machine bidule :
####################
# pablo
system pablo
...
forward bidule
####################
# bidule
system bidule
...
forward-to pablo

L'entree forward-to pour bidule est necessaire de sorte que tout chier qu'il retourne
soit passe a pablo, sinon UUCP le rejetterait. Cette entree utilise une variante de la
commande forward qui permet a bidule d'envoyer des chiers a pablo par l'interme-
diaire de truc, et uniquement dans ce sens.
Pour autoriser le relais vers n'importe quel systeme, il faut utiliser le mot cle special
ANY (les majuscules sont obligatoires).
12.4. Con gurer votre systeme en serveur UUCP 191

12.4 Con gurer votre systeme en serveur UUCP


Si vous desirez que votre site puisse ^etre appele, vous devez en autoriser l'acces par
les ports serie et con gurer quelques chiers systeme pour o rir des comptes UUCP.
Nous allons decrire la marche a suivre.

12.4.1 Con guration de getty


Si vous voulez utiliser une ligne serie pour recevoir des appels entrants, vous devrez
mettre en service un processus getty sur ce port. Toutefois, certaines implementations
du programme getty ne sont pas tres adaptees a cet usage, car vous voudrez sans doute
pouvoir egalement e ectuer des appels sortants par le m^eme port serie lorsque la ligne
est libre ; il faudra par consequent que ce peripherique puisse ^etre partage aussi bien
par getty que par des programmes de communication comme uucico ou minicom. Le
systeme Linux, a l'image de bien d'autres implementations Unix modernes, sait gerer
cette situation, neanmoins beaucoup utilisent encore, m^eme sous Linux, des arti ces
a l'ancienne mode.
Nous n'entrerons pas plus dans le detail, qui depasserait vite le cadre de ce chapitre ;
pour plus d'informations sur ce sujet, consultez par exemple le document Linux SE-
RIAL HOWTO par Grag Hankins, et les di erentes pages de manuel des di erentes
implementations de getty.
Nous considererons donc a partir de maintenant que votre systeme et le modem sont
correctement con gures pour que la machine soit accessible.

12.4.2 O rir des comptes UUCP


Vous allez donc avoir a creer des comptes utilisateur qui permettent aux sites distants
d'entrer dans votre systeme et d'etablir une connexion UUCP. Generalement, on ouvre
un compte par systeme appelant, avec un nom permettant de mettre en evidence qu'il
ne s'agit pas d'un utilisateur ordinaire. Par exemple, la machine pablo se connectera
sous le nom d'utilisateur Upablo ou uupablo.
Dans le cas des machines se connectant par le port serie, il faut ajouter ces comptes au
chier des mots de passe /etc/passwd. Une bonne pratique consiste a mettre tous les
comptes UUCP dans un groupe special comme, par exemple, uuguest. Le repertoire
personnel doit ^etre le repertoire public /var/spool/uucppublic ; et le shell doit ^etre le
programme uucico.
Si vous utilisez les mots de passe shadow, vous pourrez sans doute ouvrir ces comptes
par la commande useradd :

# useradd -d /var/spool/uucppublic -G uuguest -s /usr/lib/uucp/uucico uupablo


192 Chapitre 12. Ma^triser Taylor UUCP
Sinon, il vous faudra probablement le faire manuellement, en editant /etc/passwd pour
y rajouter une ligne comme dans l'exemple suivant, ou 5000 et 150 sont les numeros
identi cateurs de l'utilisateur uupablo et du groupe uuguest, respectivement.
uupablo:x:5000:150:Compte UUCP:/var/spool/uucppublic:/usr/lib/uucp/uucico

Ensuite, vous devrez assigner un mot de passe a ce compte par la commande passwd.
Dans le cas des machines se connectant par TCP, vous devrez con gurer inetd pour
qu'il gere les connexions sur le port uucp. Pour cela, il faudra rajouter la ligne suivante
dans le chier /etc/inetd.conf 13 :
uucp stream tcp nowait root /usr/sbin/tcpd /usr/lib/uucp/uucico -l

L'option -l demande a uucico de realiser sa propre sequence d'acces login/passwd. Il


n'utilisera pas le chier /etc/passwd standard du systeme, mais une base de donnees
de mots de passe qui lui est propre (/usr/lib/uucp/passwd) constituee de paires de
noms d'utilisateurs et des mots de passe associes:
uupablo IslaNegra
uulorca co'rdoba

Bien entendu, ce chier doit appartenir a l'utilisateur uucp et avoir le mode 600 pour
que personne ne puisse en prendre connaissance.
Si cette methode vous pla^t tellement que vous voudriez pouvoir l'utiliser aussi pour les
acces ordinaires par port serie, vous devez savoir que c'est impossible actuellement, du
moins sans un certain bricolage. Tout d'abord, vous devez passer l'option -u a uucico,
suivi du nom d'utilisateur. Pour cela, vous devrez posseder ou (probablement) bricoler
un programme getty capable de passer ce nom d'utilisateur, et qui appelle uucico a la
place de la commande standard /bin/login.
Pour proteger vos utilisateurs UUCP des intrus donnant un faux nom de systeme et
piratant tout leur courrier, vous devrez ajouter la commande called-login dans chaque
entree du chier sys. Cette operation est decrite dans la section suivante.

12.4.3 Protection contre les escrocs


Le gros probleme d'UUCP est que le systeme appelant peut tricher sur son nom ; il
s'annonce apres avoir passe la premiere authenti cation par mot de passe, mais la
machine appelee n'a aucun moyen de veri er ce nom. Par consequent, un petit malin
pourrait se connecter sur son propre compte UUCP, et pretendre ensuite qu'il est
13 Notez que generalement, tcpd a le mode 700, vous devrez donc l'invoquer sous root et non pas
:
sous uucp.
12.4. Con gurer votre systeme en serveur UUCP 193

quelqu'un d'autre pour telecharger le courrier destine a cet autre site. C'est parti-
culierement dangereux dans le cas ou vous o rez des acces UUCP anonymes, pour
lesquels le mot de passe est public, ou absent.
A moins que vous ne soyez absolument s^ur de l'honn^etete de tous les sites qui vous
appellent, vous devez vous proteger de ce type d'imposture. Le remede consiste a
demander a chaque systeme d'utiliser un nom particulier pour la connexion, que vous
speci ez par called-login dans le chier sys. Voici un exemple :
system pablo
... options habituelles ...
called-login uupablo

Le resultat est que chaque fois qu'un systeme arrive et pretend ^etre pablo, uucico
veri era s'il est bien entre sous le compte uupablo. Si ce n'est pas le cas, la connexion
sera immediatement coupee. Vous devez prendre l'habitude de con gurer cette veri -
cation chaque fois que vous ouvrez un nouveau compte UUCP ; il est tres important
de le faire pour tous les systemes, qu'ils appellent votre site ou non. Pour ceux qui
ne vous appellent jamais, vous pourrez initialiser called-login a n'importe quoi, par
exemple yapadappel.

12.4.4 Soyez parano | le test de sequence d'appels


Le test de sequence d'appels est une autre methode d'elimination des imposteurs.
M^eme ceux qui trouvent noms et mots de passe a employer ne pourront que dicile-
ment franchir cette barriere.
Avec ce systeme, chaque machine conserve une trace du nombre de connexions etablies
depuis le debut. Il est incremente a chaque connexion reussie. Au debut de chaque
communication, ces nombres sont echanges entre les deux systemes pour ^etre com-
pares : s'ils ne correspondent pas, de quelque c^ote que ce soit, la communication sera
immediatement coupee. Si, de plus, le nombre initial est tire au hasard, les pirates
auront beaucoup de mal a deviner la bonne sequence.
Mais ce test de sequence d'appels peut faire encore mieux : m^eme si quelqu'un, par
un miraculeux hasard, pirate votre compte UUCP en trouvant la bonne sequence
et votre mot de passe, vous vous en rendrez compte immediatement. Car lorsqu'il
se connectera a votre place, cela incrementera le compte des appels. La prochaine
connexion que vous tenterez vous sera alors refusee, puisque vous ne serez plus en
possession de la sequence correcte !
Par consequent, si vous avez valide ce test, vous devez regulierement jeter un il
aux chiers de trace pour detecter les attaques possibles. Si votre systeme rejette une
connexion en raison d'une mauvaise sequence, uucico enregistre un message disant
quelque chose comme (( Out of sequence call rejected )). Si c'est votre machine
qui est refusee lorsque c'est vous qui appelez, le message sera (( Handshake failed
(RBADSEQ) )).
194 Chapitre 12. Ma^triser Taylor UUCP
Pour mettre ce test en service, vous devez rajouter la commande suivante dans l'entree
du systeme en question :
# Valide le test de s
equence d'appels
sequence true

Vous devez aussi creer le chier contenant le numero initial. Taylor UUCP le place
dans un chier nomme .Sequence dans le repertoire de spoule du site distant. Il doit
appartenir a l'utilisateur uucp et avoir le mode 600 (lecture et ecriture uniquement au
proprietaire). Il vaut mieux initialiser ce nombre en se mettant d'accord avec l'autre
site sur une valeur arbitraire ; sinon quelqu'un pourrait arriver a le deviner en essayant
di erentes valeurs plausibles.
# cd /var/spool/uucp/pablo
# echo 94316 > .Sequence
# chmod 600 .Sequence
# chown uucp.uucp .Sequence

Bien s^ur, le site distant doit egalement valider ce test et commencer avec le m^eme
nombre que vous.

12.4.5 UUCP anonyme


Pour proposer un acces UUCP anonyme, vous devez con gurer un compte special
comme nous l'avons decrit ci-dessus. La tradition veut que ce compte s'appelle uucp
ou nuucp, et que son mot de passe soit uucp, si toutefois vous decidez d'en mettre
un.
De plus, vous devrez con gurer quelques options de securite pour les systemes incon-
nus. Par exemple, vous leur interdirez d'executer des commandes, y compris eventuel-
lement rmail et rnews pour ne pas avoir d'ennuis. Mais vous ne pouvez pas indiquer
ce fait dans une entree du chier sys puisque la commande system requiert le nom
du systeme, que vous ne connaissez pas. Taylor UUCP resout ce probleme par la
commande unknown, qui peut ^etre utilisee dans le chier con g pour designer toute
commande qui appara^t d'ordinaire dans l'entree d'un systeme :
unknown remote-receive ~/incoming
unknown remote-send ~/pub
unknown max-remote-debug none
unknown command-path /usr/lib/uucp/anon-bin
unknown commands rmail

L'exemple ci-dessus restreint les systemes inconnus au telechargement depuis le re-


pertoire pub, et a l'envoi de chiers dans le sous-repertoire incoming de l'espace public
/var/spool/uucppublic. La troisieme ligne indique a uucico d'ignorer les requ^etes de
mise en route du deboguage local (sinon un malin pourrait remplir votre disque dur
12.5. Protocoles UUCP de bas niveau 195

de chiers de trace). Les deux dernieres lignes autorisent les systemes inconnus a
executer la commande rmail ; mais le chemin de recherche est limite a un repertoire
prive nomme anon-bin. Cela permet d'y installer une commande rmail speciale qui,
par exemple, dirige tout courrier des sites anonymes vers la bo^te aux lettres du
superutilisateur. Cela autorise les utilisateurs anonymes a laisser un message a l'ad-
ministrateur (qui ne pourra pas leur repondre par ce m^eme chemin, bien s^ur), tout en
interdisant aux personnes malintentionnees de passer par la pour distiller du courrier
dans le monde entier.
Pour valider l'UUCP anonyme, vous devez au moins avoir une directive unknown dans
votre chier con g, sinon uucico rejettera tous les systemes inconnus.

12.5 Protocoles UUCP de bas niveau


Pour negocier l'etablissement de la session et des transferts de chiers avec son corres-
pondant, uucico utilise un ensemble de messages standardises; c'est ce que l'on appelle
couramment le protocole de haut niveau. Pendant la phase d'initialisation et de de-
connexion, ils sont simplement echanges sous forme de cha^nes de caracteres ASCII.
Toutefois, pendant le transfert des donnees, un protocole additionnel, de bas niveau,
est employe a n d'assurer l'integrite des donnees. Il est pratiquement transparent
pour le protocole de haut niveau.

12.5.1 Presentation des protocoles


Comme UUCP est employe sur di erents types de connexions, comme les lignes series,
TCP ou m^eme X.25, il est necessaire d'avoir des protocoles adaptes a chaque cas. De
plus, di erentes implementations de UUCP ont introduit divers protocoles qui font
grosso modo la m^eme chose.
On peut classer ces protocoles en deux categories: ceux qui sont orientes ux et ceux
qui sont orientes paquets. Les premiers transferent un chier dans son integralite,
en calculant eventuellement un checksum dessus. C'est extr^emement ecace mais
necessite une connexion tres able, car a la moindre erreur il faut retransmettre tout
le chier. Ce type de protocole est essentiellement utilise sur des connexions TCP
mais est totalement inadapte pour des liaisons par lignes telephoniques. Bien que les
modems modernes disposent de correction d'erreurs, ce n'est pas parfait, et il n'y en
a pas entre l'appareil et l'ordinateur.
Les protocoles de la seconde categorie divisent le chier en plusieurs morceaux. Chaque
paquet est envoye et recu separement, un checksum est calcule, et un acquittement de
bonne reception est retourne a l'expediteur, qui peut alors envoyer la partie suivante.
Pour ameliorer l'ecacite de cette methode, on a invente des protocoles a fen^etres
variables, qui permettent l'envoi d'un petit nombre de paquets (une fen^etre) sans
attendre d'acquittement. Cela reduit notablement les temps d'attente de uucico pen-
196 Chapitre 12. Ma^triser Taylor UUCP
dant la transmission, mais les performances sont malgre tout trop reduites comparees
a celles de la premiere categorie de protocoles, ce qui les rend peu adaptes a une
utilisation sur TCP.
Les caracteristiques de la liaison ont aussi une importance : quelquefois, il est impos-
sible d'envoyer des caracteres sur 8 bits par une liaison serie car un stupide serveur de
terminaux supprime le huitieme bit. Dans ce cas, il faut encoder tous ces caracteres,
ce qui double presque la taille des donnees a transmettre, bien que l'eventuelle com-
pression realisee par le materiel de transmission puisse aider un peu. Parmi les lignes
correctes, capables de passer des caracteres sur 8 bits, on compte les liaisons TCP et
la plupart des connexions par modem.
Taylor UUCP dispose au moins des protocoles suivants :
g C'est le protocole le plus courant et qui doit ^etre compris par tous
les programmes uucico. Il e ectue une correction d'erreurs et il est
par consequent adapte aux lignes telephoniques de mauvaise qualite.
Ce protocole necessite une transmission sur 8 bits, c'est un protocole
oriente paquets avec une technique de fen^etrage.
i C'est un protocole bidirectionnel, qui peut envoyer et recevoir des
chiers en m^eme temps. Il necessite une liaison bidirectionnelle sur
8 bits, il n'est compris pour l'instant que par Taylor UUCP. Il est
extr^emement ecace.
t Destine a l'usage sur les connexions TCP ou les liaisons sans au-
cune erreur. Il utilise des paquets de 1 024 octets et necessite une
transmission 8 bits.
e Semblable au protocole t, mais oriente ux.
f Destine aux connexions X.25. C'est un protocole oriente ux, mais
qui peut fonctionner sur une transmission 7 bits. Tous les caracteres
ayant le huitieme bit positionne sont encodes, ce qui le rend particu-
lierement inecace.
G Il s'agit de la version System V Release 4 du protocole g. Il est aussi
compris par quelques autres implementations de UUCP.
a Ce protocole ressemble a ZMODEM. Il necessite une transmission
sur 8 bits, mais encode certains caracteres de contr^ole comme XON
et XOFF.

12.5.2 Optimisation du protocole de transmission


Tous ces protocoles permettent d'ajuster certains de leurs parametres comme les delais
d'attente, la taille des paquets, etc. Generalement, les valeurs par defaut fonctionnent
12.5. Protocoles UUCP de bas niveau 197

correctement en des circonstances normales, mais il est des cas ou ils peuvent ^etre
inadaptes. Le protocole g, par exemple, emploie des fen^etres de 1 a 7, et des tailles
de paquet allant de 64 a 4 096 par puissances de 2 14 . Si votre ligne telephonique
est si mauvaise que vous perdez plus de 5% des paquets, vous devrez probablement
reduire leur taille ainsi que celle de la fen^etre. Toutefois, si votre liaison est excellente,
augmenter la taille de ces paquets a 512 voire 1 024 octets ameliorera l'ecacite du
protocole dans de grandes proportions.
Taylor UUCP o re la commande protocol-parameter du chier sys, qui permet d'ajus-
ter ces parametres selon vos besoins. Par exemple, pour passer la taille des paquets
du prococole g a 512 lors de communications avec pablo, vous rajouterez :
system pablo
...
protocol-parameter g packet-size 512

Les di erents parametres accessibles varient d'un protocole a l'autre. Pour en avoir la
liste complete, consultez la documentation fournie avec les sources de Taylor UUCP.

12.5.3 Selection des protocoles


Les diverses implementations de uucico ne connaissent pas toutes l'ensemble des pro-
tocoles possibles, aussi, pendant la phase d'initialisation de la session, les deux c^otes
doivent se mettre d'accord sur un protocole commun. Le ma^tre propose a l'esclave
une liste des protocoles dont il dispose en lui envoyant la sequence Pprotlist, et
l'esclave fait son choix.
En fonction du type de port utilise (modem, TCP, direct), uucico composera une liste
par defaut des protocoles souhaitables. Pour les liaisons modem et directes, cette liste
comprendra generalement i, a, g, G et j. Dans le cas de liaison TCP, ce sera t, e, i, a,
g, G, j et f. Vous pouvez modi er cette liste par defaut par la commande protocols,
qui peut ^etre speci ee dans une entree de systeme aussi bien que dans une entree de
port. Par exemple, vous pouvez editer l'entree modem de votre chier port comme
ceci :
port serial1
...
protocols igG

Cela aura pour e et de forcer l'utilisation des protocoles i, g ou G pour toute connexion
e ectuee par ce port. Si le systeme distant ne conna^t aucun de ces protocoles, la
communication echouera.
14 Beaucoup de binaires fournis avec les distributions Linux ont une fen^etre par defaut de 7 et des
:
paquets de 128 octets.
198 Chapitre 12. Ma^triser Taylor UUCP
12.6 En cas de probleme...
Cette section tente de faire le tour des erreurs que vous pourrez rencontrer, et de
suggerer ou regarder pour trouver la solution au probleme. Malgre tout, nous avons
rassemble tout cela de t^ete et il y a sans doute beaucoup d'autres choses susceptibles
de ne pas marcher correctement.
Dans tous les cas, validez le deboguage par l'option -xall, et regardez attentivement
la sortie obtenue dans le chier Debug cree dans le repertoire de spoule. Vous devriez
rapidement trouver la cause du probleme. De plus, mettez toujours le haut-parleur
de votre modem en service, cela permet de se rendre compte si la communication
s'etablit. Avec un modem compatible Hayes, il vous sura de rajouter (( ATL1M1 OK ))
dans le script de dialogue du chier dial.
La premiere veri cation a e ectuer doit toujours concerner les permissions des chiers
relatifs a UUCP. Le programme uucico doit ^etre setuid uucp, et tous les chiers conte-
nus dans /usr/lib/uucp, /var/spool/uucp et /var/spool/uucppublic doivent appartenir
a cet utilisateur uucp. Il existe egalement des chiers caches 15 dans le repertoire de
spoule qui doivent appartenir a uucp.
uucico persiste a acher (( Wrong time to call )) : ce n'est pas l'heure d'appeler le
site en question. Cela signi e probablement que vous n'avez pas speci e de commande
time dans le chier sys, detaillant quand le site peut ^etre joint, ou qu'e ectivement il
n'est pas l'heure d'appeler. Si time n'est pas la, uucico considere que ce systeme ne
pourra jamais ^etre appele.
uucico se plaint que le site est deja verrouille (site already locked) : cela signi e
qu'il detecte un chier de verrouillage pour le systeme en question dans /var/spool/uucp.
Il peut provenir d'un appel precedent qui ne s'est pas termine correctement. Toutefois,
il s'agit le plus souvent d'un autre processus uucico qui est en train d'essayer d'appeler
le site et qui est coince dans un script de dialogue, ou ailleurs. Si cet uucico n'arrive
pas a etablir la liaison, tuez-le avec un signal HUP et supprimez tous les chiers de
verrouillage qu'il pourrait oublier de nettoyer.
J'arrive a me connecter au site distant, mais le script de dialogue echoue :
regardez le texte que vous recevez de ce site. S'il est plein de parasites, ce peut ^etre
un probleme de vitesse inadaptee. Sinon, veri ez qu'il correspond bien a ce qu'attend
votre script de dialogue. Souvenez-vous que ce script commence sur une attente. Si
vous attendez l'invite de login et que vous envoyez votre nom, mais que jamais l'autre
c^ote ne vous demande le mot de passe, inserez quelques delais d'attente avant votre
envoi, ou m^eme entre chaque lettre ; il se peut que l'envoi se fasse trop rapidement.
Mon modem ne compose pas le numero : s'il n'indique pas que la ligne DTR
a ete montee lorsque uucico appelle, il se peut que vous n'avez pas indique le bon
peripherique. Sinon, veri ez avec un emulateur de terminal que vous pouvez bien
ecrire dessus. Si ca marche, mettez l'echo en service par \E au debut du script de
15: C'est-a-dire dont le nom commence par un point, et qui ne sont pas aches par la commande
ls si on ne lui precise pas.
12.7. Les chiers de trace 199

dialogue modem. S'il ne fait pas l'echo de vos commandes pendant ce dialogue, veri ez
si la vitesse de votre ligne ne serait pas trop rapide ou trop lente pour ce modem. Si
vous voyez l'echo, veri ez la validation des reponses du modem ou passez-les en mode
numerique. Veri ez que le script de dialogue, lui-m^eme, est correct. Souvenez-vous
qu'il faut ecrire deux caracteres backslash pour en envoyer un au modem.
Mon modem essaie de numeroter mais cela n'aboutit pas : inserez une pause
dans le numero de telephone, particulierement si vous appelez d'un central prive.
Essayez les deux types de numerotation : vocale, puis decimale. Et veri ez le numero
de telephone...
Mon chier de trace indique que je perds beaucoup de paquets : ce peut ^etre
un probleme de vitesse. Si la liaison entre votre ordinateur et votre modem est plus
lente que celle a laquelle la communication s'est etablie, remediez a cette situation.
Il se peut que votre equipement soit trop lent pour suivre le nombre d'interruptions
generees par les hautes vitesses. Dans ce cas, il faut employer un circuit NSC 16550A
sur votre port serie. Vous devez egalement veri er que le contr^ole de ux materiel est
en service, tant du c^ote du systeme que sur le modem.
Taylor UUCP n'a rien de prevu pour valider ce contr^ole de ux, vous devez donc
le faire explicitement depuis le chier rc.serial (par exemple) en utilisant cette com-
mande :
$ stty crtscts < /dev/cua3

J'entre dans le systeme mais le handshake echoue : les causes peuvent ^etre
nombreuses. Le chier de trace vous sera d'un precieux secours. Regardez quels pro-
tocoles o re le site distant (il doit envoyer la cha^ne Pprotlist ). Il se peut que vous
n'en ayez aucun en commun (avez-vous selectionne des protocoles speciaux dans les
chiers sys ou port ?).
Si le systeme distant envoie RLCK, c'est qu'il y a la-bas un chier de verrouillage vous
concernant. Si ce n'est pas parce que vous y ^etes deja connecte par une autre ligne,
demandez a son administrateur qu'il corrige cette erreur.
S'il envoie RBADSEQ, c'est que l'autre c^ote a valide le test de sequence d'appels pour
votre site, mais que les valeurs ne correspondent pas. S'il envoie RLOGIN, c'est que
vous n'^etes pas autorise a vous connecter sous ce nom d'utilisateur.

12.7 Les chiers de trace


Lorsque l'on compile Taylor UUCP en choisissant les traces de style Taylor, cela ne
donne que trois chiers globaux, chacun residant dans le repertoire spoule. Le chier
principal s'appelle Log et contient toutes les informations concernant les connexions
etablies et les chiers transferes. Voici un extrait de ce que cela peut donner (apres
reformatage pour que les lignes ne debordent pas de la page...) :
200 Chapitre 12. Ma^triser Taylor UUCP
uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3)
uucico pablo - (1994-05-28 17:15:39.25 539) Login successful
uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful
(protocol 'g' packet size 1024 window 7)
uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj
uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai
uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at
uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as
uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2
uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1
uucico pablo - (1994-05-28 17:15:59.05 539) Protocol 'g' packets: sent 15,
resent 0, received 32
uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26 seconds)
uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai
(rmail okir)
uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as
(rmail okir)
uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1
(rmail okir)

Le chier suivant, par ordre d'importance, s'appelle Stats et indique les statistiques
des transferts de donnees. La section de Stats correspondant au chier de trace ci-
dessus ressemble a celle-ci (la encore, les lignes ont ete reformatees):

postmaster pablo (1994-05-28 17:15:44.78)


received 1714 bytes in 1.802 seconds (951 bytes/sec)
postmaster pablo (1994-05-28 17:15:46.66)
received 57 bytes in 0.634 seconds (89 bytes/sec)
postmaster pablo (1994-05-28 17:15:49.91)
received 1898 bytes in 1.599 seconds (1186 bytes/sec)
postmaster pablo (1994-05-28 17:15:51.67)
received 65 bytes in 0.555 seconds (117 bytes/sec)
postmaster pablo (1994-05-28 17:15:55.71)
received 3217 bytes in 2.254 seconds (1427 bytes/sec)
postmaster pablo (1994-05-28 17:15:57.31)
received 65 bytes in 0.590 seconds (110 bytes/sec)

Le troisieme chier s'appelle Debug. C'est la que sont enregistrees les informations
de deboguage lorsqu'il est mis en service. Vous devez vous assurer que ce chier a le
mode 600, car en fonction du niveau de deboguage choisi, il peut contenir les mots de
passe utilises pour toutes les connexions.
Certains binaires fournis avec des distributions de Linux sont compiles avec le style
de trace HDB. Ce mode utilise une grande quantite de chiers de trace stockes dans
/var/spool/uucp/.Log. Ce repertoire contient trois autres sous-repertoires, nommes
uucico, uuxqt et uux. Ils contiennent la trace generee par chacun des programmes
correspondants, tries dans di erents chiers pour chaque site. Ainsi, la sortie de uucico
lors de l'appel du site pablo se trouvera dans .Log/uucico/pablo, et les invocations
de uuxqt qui resulteront de cet appel seront enregistrees dans .Log/uuxqt/pablo. Les
lignes ont, en revanche, le m^eme format que celles des traces du style Taylor.
12.7. Les chiers de trace 201

Lorsque vous validez le deboguage avec un style de trace HDB, l'enregistrement se


fera dans .Admin/audit.local, alors que la sortie de uucico, lorsque c'est un site qui
appelle, sera dans .Admin/audit.
202 Chapitre 12. Ma^triser Taylor UUCP
203

Chapitre 13
Le courrier electronique
Depuis que les premiers reseaux furent imagines, le courrier electronique en fait un
usage chaque jour plus important. Cela a commence par un simple service qui copiait
un chier d'une machine a une autre en le mettant dans le chier bo^te aux lettres du
correspondant. C'est d'ailleurs toujours le cas ; bien que par-dessus se soient gre ees
beaucoup de choses rendues necessaires par la complexite du reseau et l'augmentation
constante du ux de messages.
Divers standards d'echange de courrier ont ete imagines. Les sites connectes a l'In-
ternet adherent a celui de ni par le RFC 822, associe a d'autres documents RFC qui
decrivent une methode de transmission de caracteres speciaux ou autres informations,
independante des machines mises en jeu. On fait beaucoup de bruit depuis quelque
temps autour du courrier (( multimedia )), qui permet de transferer egalement des
images et du son avec le courrier. Il existe un autre standard, X.400, qui est de ni
par le CCITT.
Vous trouverez beaucoup de programmes destines au transport du courrier pour les
systemes UNIX. L'un des plus connus et des plus utilises, toutes plates-formes confon-
dues, s'appelle sendmail ; c'est l'implementation de l'universite de Berkeley, l'auteur
est Eric Allman. Il y a actuellement deux portages de sendmail-5.56c sous Linux,
dont l'un sera decrit dans le chapitre 15. La version de developpement actuelle porte
le numero 8.6.9.
L'agent de transport de courrier le plus employe sous Linux est smail-3.1.28, realise
par Curt Landon Noll and Ronald S. Karr. Il est fourni dans la plupart des distribu-
tions binaires de Linux.
Compare a sendmail, smail est plus recent et plus simple. Pour gerer le courrier d'un
petit site sans routages tres compliques, ils sont quasi equivalents. Pour les grands
sites, sendmail gagne a tous les coups, en raison de ses possibilites et de sa souplesse
de con guration.
204 Chapitre 13. Le courrier electronique
Tous deux supportent un ensemble de chiers de con guration qui doivent ^etre adaptes
a chaque cas. En dehors des informations necessaires pour que le sous-systeme de
courrier fonctionne (comme le nom de la machine), il y a beaucoup d'autres parametres
con gurables. Le chier de con guration principal de sendmail est tres dicile a
comprendre au premier abord ; ceux de smail sont plus structures et beaucoup plus
clairs, mais n'o rent pas autant de possibilites pour ajuster le comportement du
programme. Quoi qu'il en soit, pour les petits sites UUCP ou Internet, le travail
demande par la con guration est sensiblement le m^eme pour tous les deux.
Ce chapitre va presenter le courrier electronique et les t^aches qui vous attendent en
tant qu'administrateur. Les chapitres 14 et 15 vous permettront ensuite d'e ectuer
votre premiere con guration de l'un de ces agents de transfert de courrier. Vous
devriez trouver toutes les informations necessaires pour le fonctionnement d'un petit
site, mais il y a beaucoup plus d'options possibles, et vous pourrez plus tard occuper
de longues soirees en essayant passionnement de mettre au point une con guration
bien plus personnelle.
Vers la n du chapitre, nous presenterons rapidement la con guration de elm, une
interface utilisateur destinee au courrier electronique, tres courante sur de nombreux
systemes UNIX, y compris Linux.
Pour plus d'informations sur le courrier electronique sous Linux, consultez le docu-
ment de Vince Skahan, (( Electronic Mail HOWTO )), poste regulierement sur Usenet.
Les distributions originales de elm, smail et sendmail contiennent egalement beaucoup
de documentations tres detaillees ou vous devriez trouver la reponse a la plupart de
vos questions concernant leur con guration. Si vous voulez vous informer sur le cour-
rier electronique d'une maniere plus generale, un certain nombre de RFC traitent de
ce sujet, ils sont indiques dans la bibliographie fournie a la n de ce guide.

13.1 Qu'est-ce qu'un message ?


Un message de courrier electronique est constitue d'un corps, qui est le texte du
message, et de donnees speciales indiquant les destinataires, les moyens de transport,
etc., un peu comme ce que vous voyez en regardant de pres l'enveloppe d'un courrier
postal.
Ces donnees administratives se divisent en deux categories. Dans la premiere, se trou-
vent toutes les informations speci ques aux moyens de transport, comme l'adresse
de l'expediteur et du destinataire. Elle est par consequent appelee l'enveloppe. Elle
peut ^etre modi ee par les di erents logiciels d'acheminement qui feront transiter le
message.
La seconde categorie contient toutes les donnees necessaires a la manipulation du
message, et qui n'est pas speci que d'un mecanisme de transport ; on y trouve le
sujet, une liste de destinataires, et la date d'expedition. Sur de nombreux reseaux, il
est devenu standard de placer ces donnees au debut du message, qui forment alors ce
13.1. Qu'est-ce qu'un message? 205

qui est appele l'en-t^ete. Il est separe du corps du message par une ligne vide 1 .
La plupart des logiciels de transport de courrier du monde UNIX utilisent le format
d'en-t^etes de ni dans le RFC 822. Son but etait a l'origine de de nir un standard
sur le reseau ARPANET, mais puisqu'il est prevu pour ^etre independant de tout
environnement, il a ete tres vite adapte a d'autres reseaux, y compris ceux bases sur
UUCP.
RFC 822 n'est toutefois que le plus petit denominateur commun ; d'autres formats
ont recemment ete concus pour faire face aux besoins grandissants d'encryptage de
donnees, de caracteres internationaux, et d'extensions multimedia (MIME).
Dans tous ces standards, l'en-t^ete est constitue de plusieurs lignes, separees par des
caracteres de saut de ligne. Chaque ligne est constituee d'un nom de champ, com-
mencant sur la premiere colonne, et de la valeur de ce champ, separee par le caractere
(( : )) suivi d'une espace. Le format et la s emantique de chaque champ varient selon
leur nom. Un champ peut s'etendre sur plusieurs lignes, si la suivante commence par
le caractere de tabulation. Les champs peuvent appara^tre dans n'importe quel ordre.
Voici un exemple d'en-t^ete de courrier :
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path: <brewhq.swb.de!ora.com!andyo>
Received: from brewhq.swb.de by monad.swb.de with uucp
(Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST
Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
(Smail3.1.28.1 #28.6) id <m0pqoQr-0008qhC>; Tue, 12 Apr 94 21:47 MEST
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 -0400
Date: Tue, 12 Apr 1994 15:56:49 -0400
Message-Id: <199404121956.PAA07787@ruby>
From: andyo@ora.com (Andy Oram)
To: okir@monad.swb.de
Subject: Re: Your RPC section

Generalement, tous les champs necessaires sont generes par l'interface de courrier
que vous utilisez, comme par exemple elm, pine, mush ou mailx. Toutefois, certains
sont facultatifs et peuvent ^etre rajoutes par l'utilisateur. L'interface elm, par exemple,
permet d'editer une partie de l'en-t^ete du message. D'autres sont places par l'agent de
transport de courrier. Voici une liste des champs les plus courants et leur signi cation :
From: Contient l'adresse electronique de l'expediteur, ainsi que son (( vrai
nom )) (facultatif). Il existe beaucoup de formats standards pour ce
champ.
To: Il s'agit de l'adresse du destinataire.
Subject: Le sujet, qui decrit le contenu du courrier en quelques mots. Du
moins, c'est ce qu'il devrait faire.
1 Il est courant de rajouter une signature ou .sig aux courriers, contenant des informations sur
:
l'auteur, souvent suivies d'un dicton ou d'une plaisanterie. Elle est separee du corps du message par
une ligne contenant (( -- )) suivi d'une espace.
206 Chapitre 13. Le courrier electronique
Date: La date a laquelle le courrier a ete expedie.
Reply-To: Speci e l'adresse a laquelle l'expediteur veut que les reponses even-
tuelles lui soient envoyees. Ce peut ^etre tres utile si vous possedez
plusieurs adresses, mais que vous ne voulez recevoir le courrier qu'a
celle que vous utilisez le plus souvent. Ce champ est optionnel.
Organization:
Decrit l'organisme, societe, universite, ou autres, qui est proprietaire
de la machine d'ou provient le courrier. Ce champ est facultatif ; s'il
s'agit de votre ordinateur personnel, omettez-le ou mettez ce que
vous voulez.
Message-ID: Il s'agit d'une cha^ne generee par l'agent de transport de courrier du
systeme ou le message a ete genere ; cet identi cateur est propre au
message, unique dans le monde entier.
Received: Chaque site traitant votre courrier (y compris ceux d'origine et de
destination) insere ce champ dans l'en-t^ete, indiquant son nom, un
identi cateur, la date et l'heure de reception, de quel site le message
est arrive, et quel logiciel de transport a ete utilise. Ainsi, vous pouvez
suivre facilement la route parcourue par le message et vous plaindre
a la personne responsable si quelque chose ne s'est pas bien passe.
X-nom-quelconque:
Aucun programme relatif au courrier ne doit se plaindre d'en-t^etes
commencant par X-. Ce champ sert a ajouter des informations supple-
mentaires concernant toute possibilite nouvelle qui n'est pas encore
de nie dans un document RFC, ou ne le sera jamais. Les listes de
di usion (( Linux Activists )) utilisent par exemple cette possibilite
pour la selection du canal approprie, repere par X-Mn-Key: canal.
La seule exception a cette structure concerne la toute premiere ligne. Celle-ci com-
mence par le motcle From suivi d'une espace au lieu du caractere (( deux-points )). A n
de la distinguer du champ ordinaire From:, on la reference souvent par From . Elle
contient le chemin que le message a emprunte selon la syntaxe UUCP (expliquee plus
loin), la date et l'heure a laquelle il a ete recu par la derniere machine qui l'a traite,
et une partie optionnelle speci ant de quel h^ote il est arrive. Puisque ce champ est
reecrit par chaque systeme voyant passer le message, il est parfois considere comme
faisant partie de l'enveloppe.
Le champ From est necessaire pour des raisons de compatibilite avec d'anciens agents
de transport ; il n'est pratiquement plus utilise, sauf par certaines interfaces qui s'en
servent pour marquer le debut d'un message dans la boite aux lettres de l'utilisateur.
Pour eviter des ennuis potentiels dus a la confusion possible avec les lignes du corps
du message pouvant aussi commencer par (( From )), il est de coutume de modi er
chaque occurrence de ces lignes en la faisant preceder du caractere . >
13.2. Comment le courrier est-il delivre ? 207

13.2 Comment le courrier est-il delivre ?


En general, le courrier est saisi par l'intermediaire d'une interface comme mail ou
mailx, ou encore d'un programme plus sophistique comme elm, mush ou pine. On
les appelle des MUA, Mail User Agents. Si vous expediez un message, l'interface
le passera dans la plupart des cas a un autre logiciel pour qu'il soit distribue, que
l'on appelle le MTA (Mail Transport Agent, agent de transport du courrier). Sur
certains systemes, vous rencontrerez plusieurs MTA, specialises dans le courrier local
et distant ; sur d'autres il s'agit du m^eme programme. La commande permettant
de delivrer un courrier distant s'appelle generalement rmail, et s'il en existe une
particuliere pour les messages locaux, ce sera sans doute un nom comme lmail.
Delivrer un courrier local ne consiste pas, bien s^ur, qu'a rajouter le message dans la
bo^te aux lettres du destinataire. Generalement, le MTA local sait reconna^tre des alias
(adresses pointant vers d'autres adresses) et la reexpedition (rediriger tout le courrier
de quelqu'un vers d'autres adresses). De plus, les messages qui ne peuvent pas ^etre
distribues doivent revenir a leur expediteur, accompagnes d'un message d'erreur.
Pour la distribution de courrier non local, le logiciel de transport depend de la nature
de la liaison. Si la destination se trouve sur un reseau utilisant TCP/IP, c'est ge-
neralement le protocole SMTP qui est employe. SMTP signi e Simple Mail Transfer
Protocol, c'est un protocole de transfert de courrier par TCP/IP qui est de ni dans les
documents RFC 788 et RFC 821. Il se connecte en general directement a la machine
du destinataire, et negocie le transfert du message avec son demon SMTP.
Dans les reseaux UUCP, le courrier est rarement distribue directement, mais transite
par di erents systemes intermediaires faisant le relais vers la machine destinataire.
Pour envoyer un message sur une liaison UUCP, le MTA emetteur executera la com-
mande rmail sur le systeme distant gr^ace a uux, en envoyant le message sur l'entree
standard.
Puisque cette operation doit ^etre realisee pour chaque message, cela pourrait pro-
duire une surcharge de travail considerable sur une machine jouant le r^ole de nud
important pour le courrier, et remplir le spoule UUCP de centaines de petits chiers
occupant beaucoup trop de place sur le disque dur 2 . Par consequent, certains MTA
permettent de rassembler plusieurs messages pour un systeme distant dans un seul
lot. Ce chier contient les commandes SMTP que la machine locale devrait normale-
ment executer si une telle connexion directe etait employee. C'est ce que l'on appelle
BSMTP, ou SMTP par lots ((( batched SMTP ))). Le lot est alors envoye au programme
rsmtp ou bsmtp du systeme distant, qui traitera les commandes contenues comme s'il
s'agissait d'une connexion SMTP normale.

2 L'espace disque est generalement alloue par blocs de 1 024 octets. Aussi, m^eme un message de
:
400 octets utilisera 1 Ko d'espace disque
208 Chapitre 13. Le courrier electronique
13.3 Adresses electroniques
Pour le courrier electronique, une adresse est constituee au minimum du nom d'une
machine gerant le courrier du destinataire, et de l'identi cation de ce dernier, reconnue
par son systeme. Ce peut ^etre son nom d'utilisateur, aussi bien que tout autre chose.
D'autres methodes d'adressage, comme X.400, emploient un ensemble plus general
d'(( attributs )) pour retrouver la machine du destinataire dans le repertoire d'un
serveur X.500.
La maniere dont le nom de machine est interprete, c'est-a-dire sur quel site votre
message nira par arriver, et la facon de combiner ce nom avec celui du destinataire
dependent etroitement du reseau sur lequel vous ^etes connecte.
Les sites Internet respectent le standard RFC 822, qui necessite une notation de type
utilisateur@h^ote.domaine, ou h^ote.domaine est le nom pleinement quali e de la
machine. Le signe du milieu, le (( A commercial )), se prononce (( at )) dans ce cas 3.
Puisque cette notation ne met en jeu aucune route vers l'adresse de destination, et
ne donne que le nom (unique) de la machine, on la designe par adresse absolue.
Dans l'environnement UUCP original, la forme dominante des adresses etait che-
min!h^ote!utilisateur, chemin decrivait une sequence de machines par lesquels le
message devait passer avant d'atteindre sa destination. Cette construction s'appelle
la notation bang, tout simplement parce qu'un point d'exclamation est familierement
appele un (( bang )), chez les informaticiens anglophones. Aujourd'hui, la plupart des
reseaux bases sur UUCP ont adopte le standard RFC 822 ou comprennent au moins
ce type d'adressage.
Maintenant, il faut savoir que ces deux types d'adresses n'aiment pas trop ^etre melan-
ges. Considerons par exemple l'adresse machineA!utilisateur@machineB. Il n'est
pas du tout evident de savoir si le signe @ a priorite sur le bang, ou vice versa : devons-
nous envoyer le message a machineB, qui le transmettra a machineA!utilisateur ou
bien alors faut-il le passer a machineA, qui l'expediera a utilisateur@machineB ?
Les adresses comme celle-ci, qui melangent les deux types de notations, sont appelees
adresses hybrides. Notre exemple est un cas d'ecole, il est generalement resolu en
donnant la priorite au signe @, ce qui signi era ici que le message sera transmis
d'abord a machineB.
Toutefois, il existe un moyen de speci er des routes en restant conforme au RFC 822 :
< @machineA,@machineB:utilisateur@machineC denote l'adresse de utilisa-
>

teur sur l'h^ote machineC, machine qui peut ^etre jointe en passant par machineA
et machineB, dans l'ordre. Ce type d'adresse est une adresse de routage, nommee
souvent route-addr.
En n, il y a l'operateur % (le signe pour cent) : user%machineB@machineA sera
d'abord envoye a machineA, qui changera le signe pour cent le plus a droite (ici, c'est
3 Traduisez (( at )) par (( chez )) et vous constaterez que cette notation n'est pas si compliquee a
:
comprendre, cela donne utilisateur chez h^ote.domaine.
13.4. Le routage du courrier 209

le seul) en un signe @. L'adresse devient alors pour ce site utilisateur@machineB,


et le MTA passera le message le plus naturellement du monde a machineB qui le
delivrera a utilisateur. Ce type d'adressage est souvent appele (( La vieille rustine
de l'ARPANET )), et n'est pas encourage. Neanmoins, beaucoup de MTA savent gerer
et parfois generent ce genre de chose.
D'autres reseaux utilisent des methodes d'adressages encore di erentes. Les reseaux
DECnet, par exemple, utilisent les deux caracteres (( :: )) comme separateur, ce qui
donne le format h^ote::utilisateur 4. En n, le standard X.400 emploie une notation
completement di erente, decrivant un destinataire par un ensemble de paires attribut-
valeur.
Sur FidoNet, chaque utilisateur est identi e par un code du type 2:320/204.9, consis-
tant en quatre nombres indiquant la zone (2 pour l'Europe), le reseau (320 pour Paris
et sa banlieue), le nud et le point (la machine personnelle de l'utilisateur). Les
adresses Fidonet peuvent facilement ^etre transformees au format RFC 822, celle de
notre exemple peut s'ecrire Thomas.Quinot@p9.f204.n320.z2. donet.org.
N'avions-nous pas dit que les noms de domaines sont faciles a retenir ?
Nous verrons ce qu'implique l'utilisation de ces di erents types d'adresses dans les sec-
tions suivantes. Dans un environnement RFC 822, vous n'aurez toutefois que rarement
besoin d'autre chose que des adresses absolues comme utilisateur.h^ote.domaine.

13.4 Le routage du courrier


L'action de diriger un message vers la machine du destinataire s'appelle le routage.
En plus de trouver un chemin du site expediteur vers la destination, le routage met
en jeu des tests d'erreurs et une optimisation en fonction de la vitesse et du co^ut.
Il y a une grande di erence entre la facon dont un site UUCP gere le routage, et celle
employee par un site Internet. Sur l'Internet, toute la t^ache d'acheminer les donnees,
une fois que la machine de destination est connue par son adresse IP, est faite par la
couche IP du reseau ; dans une zone UUCP, la route doit ^etre indiquee par l'utilisateur
ou generee par le MTA.

13.4.1 Routage du courrier sur l'Internet


Sur l'Internet, le routage depend entierement de l'h^ote destinataire, ou tout traitement
eventuel du courrier sera e ectue. Par defaut, le message est delivre a cette machine
en recherchant son adresse IP et en laissant ensuite le reseau faire son travail.
La plupart des sites feront en general arriver le courrier sur un serveur toujours dispo-
nible, capable de gerer tout le tra c et qui s'occupera de la distribution locale. Pour
4 Pour joindre une adresse DECnet depuis un environnement RFC 822, vous pouvez utiliser
:
"h^ote::utilisateur"@relais, ou relais est le nom d'une passerelle Internet-DECnet connue.
210 Chapitre 13. Le courrier electronique
faire conna^tre ce service, le site publie dans le DNS un enregistrement de type MX
pour leur domaine local. MX signi e mail exchanger (echangeur de courrier), et sert
a annoncer que l'h^ote indique s'occupera de repartir le courrier pour toutes les ma-
chines de son domaine. Les enregistrements MX peuvent aussi ^etre utilises pour gerer
le courrier de machines qui ne sont pas connectees directement a l'Internet, comme
certains sites UUCP ou des reseaux transportant des informations con dentielles.
Ces MX se voient aussi associer une preference, sous la forme d'un nombre entier. S'il
existe plusieurs echangeurs de courrier pour un h^ote, l'agent de transport essaiera de
passer le message a l'echangeur qui a la plus faible valeur de preference, et il n'essaiera
les autres que si le premier est inaccessible. Si l'h^ote local est lui-m^eme un echangeur
pour l'adresse de destination, il ne doit pas renvoyer de messages a des h^otes MX
ayant une preference superieure a la sienne ; cela permet d'eviter des bouclages.
Supposons qu'une organisation, que nous appellerons toto, veuille que tout leur cour-
rier soit gere par leur machine qui s'appelle laposte.toto.com. Ils auront alors dans
la base de donnees du DNS, des enregistrements MX comme celui-ci :
jaune.toto.com. IN MX 5 laposte.toto.com.

Il annonce laposte.toto.com comme un echangeur de courrier pour delivrer un mes-


sage a destination de, par exemple, marcel@jaune.toto.com, avec une preference
de valeur 5. Un h^ote desirant delivrer un message a cette adresse interrogera le DNS,
trouvera le MX pointant sur laposte. S'il n'y a pas d'autre MX ayant une preference
inferieure a 5, le message sera envoye a laposte, qui saura alors le diriger sur la
machine jaune.
Bien s^ur, cet exemple n'est qu'une ebauche du fonctionnement des enregistrements
MX. Consultez le document RFC 974 pour obtenir plus d'informations sur le routage
du courrier sur l'Internet.

13.4.2 Routage du courrier dans le monde UUCP


La distribution du courrier sur les reseaux UUCP est beaucoup plus compliquee que
sur l'Internet, car le logiciel de transport n'e ectue aucun routage lui-m^eme. Autre-
fois, tous les messages devaient ^etre adresses par la methode des bangs, qui consiste a
speci er une liste d'h^otes par lesquels faire passer le message, separes par des points
d'exclamation (les (( bangs ))), terminee par le nom de l'utilisateur. Pour envoyer
une lettre a l'utilisateur alfred sur une machine nommee hopla, il fallait ecrire
eek!swim!hopla!alfred. Le courrier aurait ete envoye de votre machine vers eek,
puis de la sur swim, et en n sur hopla.
L'inconvenient de cette technique c'est qu'il faut se souvenir de toute la topologie
du reseau, des liaisons les plus rapides, etc. Pis, le moindre changement dans l'orga-
nisation (machines supprimees, liaisons modi ees) peut emp^echer la distribution du
courrier si vous n'^etes pas mis au courant de ce changement. En n, si vous demenagez,
vous devrez probablement mettre a jour toutes ces routes.
13.4. Le routage du courrier 211

Ce routage a la source etait necessaire en raison de la presence de noms d'h^otes


ambigus. Par exemple, supposons qu'il existe deux sites appeles hopla ; l'un aux
E tats-Unis, l'autre en France. Lorsque l'on ecrit hopla!alfred, de quel site s'agit-il ?
Pour le preciser, il faut speci er quel est le chemin a utiliser pour joindre hopla.
A n de parer aux noms ambigus, la premiere etape fut la fondation du UUCP Map-
ping Project, a Rutgers University. Son but est d'enregistrer tous les noms ociels
de machines UUCP, avec des informations concernant leurs voisins et leur position
geographique; et de s'assurer que chaque nom est unique au monde. Toutes les infor-
mations collectees sont publiees sous la forme de cartes UUCP, distribuees reguliere-
ment via Usenet 5 . Apres suppression des commentaires, l'entree d'un systeme dans
une carte ressemble a ceci :
renux
frmug(DAILY/2),
keltia(WEEKLY)

Cette entree indique que la machine renux se connecte deux fois par jour a frmug,
et sur keltia une fois par semaine. Nous reviendrons en detail sur ce format un peu
plus loin.
Gr^ace aux informations sur la connectivite contenues dans ces cartes, vous pouvez
generer automatiquement le chemin d'acces complet depuis votre machine vers n'im-
porte quel site. Ces informations sont generalement stockees dans le chier paths,
appele aussi la base de donnees pathalias. Supposons que les cartes indiquent que
vous pouvez joindre keltia via imladris ; une entree pathalias pour renux creee a
partir de l'extrait de carte montre plus haut pourrait ressembler a ceci :
renux imladris!keltia!renux!%s

Si maintenant, vous donnez l'adresse de destination sous la forme rene@renux.uucp,


votre MTA utilisera la route ci-dessus et enverra le message a imladris, avec une
adresse d'enveloppe de keltia!renux!rene.
Creer un chier paths a partir de la totalite des cartes UUCP n'est toutefois pas une
tres bonne idee. Les informations sont generalement distordues et parfois obsoletes.
Par consequent, seul un petit nombre de sites importants utilise la totalite des cartes
UUCP du monde entier pour construire leurs chiers paths. La plupart des autres se
contentent de posseder les informations de routage concernant leurs voisins les plus
proches, et d'envoyer tout le courrier pour les sites absents de leur base de donnees
vers une machine mieux informee, qui s'appelle alors le smart-host. Les machines ne
possedant qu'un seul lien UUCP ne font jamais aucun routage, et envoient tout leur
courrier a leur smart-host qui s'en occupera a leur place.
5 Les cartes des sites enregistres dans ce projet sont distribuees dans le groupe comp.mail.maps ;
:
d'autres organisations peuvent di user des cartes separees pour leurs reseaux.
212 Chapitre 13. Le courrier electronique
13.4.3 Melanger UUCP et RFC 822
La meilleure solution aux problemes de routage du courrier dans les reseaux UUCP
est l'adoption du DNS. Bien s^ur, il est impossible d'interroger un serveur de noms par
UUCP. Neanmoins, beaucoup de sites UUCP se sont organises en petits domaines qui
coordonnent leurs routages entre eux. Dans les cartes, ces domaines annoncent une
ou deux machines comme leurs passerelles pour le courrier, ainsi il n'y a plus besoin
d'entrees speci ques pour chaque h^ote de ce domaine. Les passerelles gerent tout le
courrier entrant et sortant pour le domaine en question ; le routage e ectue entre les
machines composant ce domaine est completement invisible au reste du monde.
Cela fonctionne tres bien avec la methode de routage par les smart-hosts que nous ve-
nons de decrire. L'information necessaire a l'integralite du routage n'est maintenue que
sur les passerelles ; les petits sites d'un domaine n'auront que quelques paths rediges a
la main indiquant comment diriger le courrier vers le smart-hosts et eventuellement a
l'interieur de leur domaine. Les passerelles n'ont plus besoin de conna^tre tous les sites
UUCP du monde entier ; en dehors du domaine qu'elles gerent, il leur sut d'avoir
des routes vers d'autres domaines dans leur base de donnees. Par exemple, l'entree pa-
thalias ci-dessous dirigera tout le courrier a destination des sites du domaine sub.org
vers schtroumpf :
.sub.org swim!schtroumpf!%s

Un message adresse a claire@jones.sub.org sera envoye a swim avec une adresse


d'enveloppe de schtroumpf!jones!claire.
L'organisation hierarchisee de l'espace de noms permet aux serveurs de courrier de
melanger des routes bien speci ques avec d'autres plus generales. Par exemple, un sys-
teme situe en France peut avoir des routes particulieres pour certains sous-domaines
de fr, mais router tout courrier a destination des machines du domaine us vers un
systeme situe aux U.S.A. Ainsi, le routage par domaine reduit considerablement la
taille des bases de donnees necessaires, aussi bien que les t^aches administratives.
Toutefois, le plus gros bene ce apporte par l'emploi de noms de domaines dans un
environnement UUCP, c'est que la conformite au standard RFC 822 permet une
interconnexion facile entre les reseaux UUCP et l'Internet. Beaucoup de domaines
UUCP possedent de nos jours un lien avec une passerelle Internet qui joue le r^ole
de smart host. L'envoi de messages par l'Internet est beaucoup plus rapide, et les
informations de routage sont beaucoup plus ables puisque c'est le DNS qui entre en
jeu, au lieu des cartes UUCP.
Pour ^etre joignables depuis l'Internet, les domaines UUCP possedent generalement un
enregistrement MX dans le DNS. Par exemple, supposons que moria appartient au
domaine orcnet.org. La machine gcc2.groucho.edu joue le r^ole de leur passerelle
Internet. Par consequent, moria utiliserait gcc2 comme son smart host de sorte
que tout le courrier a destination d'autres domaines soit delivre par l'Internet. D'un
autre c^ote, gcc2 annoncerait un MX pour *.orcnet.org et enverrait tout message
13.5. Format des cartes et du chier pathalias 213

arrivant pour les machines de orcnet a moria. L'asterisque dans *.orcnet.org est
un caractere generique qui correspondra a tous les h^otes de ce domaine qui ne sont
associes a aucun autre enregistrement ; c'est generalement ce qui doit ^etre fait pour
les domaines uniquement UUCP.
Il reste un probleme : les programmes de transport par UUCP ne savent pas gerer les
noms pleinement quali es. La plupart des programmes furent prevus pour traiter des
noms ne depassant pas huit caracteres, parfois moins, et l'utilisation de caracteres
non alphanumeriques comme de simples points est hors de question avec la plupart
d'entre eux.
Par consequent, il est necessaire de pouvoir e ectuer la correspondance entre les noms
RFC 822 et UUCP. La facon dont cela est realise depend entierement de l'implemen-
tation. Une methode courante consiste a utiliser le chier pathalias :
moria.orcnet.org ernie!bert!moria!%s

Cette entree produira un chemin purement UUCP avec la notation par bangs a partir
d'une adresse speci ant un nom pleinement quali e. Certains MTA proposent un
chier special destine a ces operations; sendmail, par exemple, utilise un chier appele
uucpxtable.
La transformation inverse (qu'il est courant d'appeler (( domainisation ))), est parfois
necessaire lors de l'envoi d'un courrier depuis un reseau UUCP vers l'Internet. Tant
que l'expediteur utilise un nom pleinement quali e pour l'adresse de destination, ce
probleme peut ^etre evite en ne supprimant pas le nom du domaine de l'adresse d'en-
veloppe lors de l'envoi du message au smart host. Toutefois, il reste encore quelques
sites UUCP qui ne font partie d'aucun domaine. Ils sont alors domainises en leur
rajoutant le pseudo-domaine uucp.

13.5 Format des cartes et du chier pathalias


La base de donnees pathalias contient les principales informations de routage dans les
reseaux UUCP. Une entree typique ressemble a la suivante (sites et chemins doivent
^etre separes par des tabulations, et non par des espaces) :
moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s

Cette entree fera que tout message pour moria sera delivre en passant par ernie et
bert. Il faut indiquer a la fois le nom pleinement quali e et le nom UUCP de moria
si le MTA ne sait pas faire la correspondance de l'un a l'autre.
Si vous voulez diriger tous les messages pour les h^otes d'un domaine particulier vers
son relais de courrier, vous pouvez aussi speci er un chemin dans la base de donnees
pathalias, indiquant le domaine comme une cible, precede d'un point. Par exemple,
214 Chapitre 13. Le courrier electronique
si toutes les machines de sub.org peuvent ^etre atteintes par swim!smurf, l'entree
pathalias s'ecrira comme ceci :
.sub.org swim!smurf!%s

La realisation manuelle d'un chier pathalias n'est acceptable que si votre site n'a pas
trop de routages a e ectuer. Sinon, il vaut mieux utiliser la commande pathalias qui
creera le chier a partir des cartes UUCP. Ces cartes peuvent ^etre maintenues bien
plus facilement, car il vous sut de rajouter ou de supprimer l'entree d'un systeme
dans la carte et de relancer la commande pour recreer le nouveau chier. Bien que
les cartes publiees sur Usenet ne soient pratiquement plus utilisees pour le routage,
certains reseaux plus petits peuvent proposer leur propre jeu de cartes a cette n.
Un chier de cartes consiste principalement en une liste de sites, contenant les ma-
chines avec lesquelles le systeme est regulierement connecte par UUCP, soit comme
appelant, soit comme appele. Le nom du systeme commence en premiere colonne, et
est suivi par une liste de liens, separes par des virgules. Cette liste peut s'etendre sur
plusieurs lignes a condition que la suivante commence par une tabulation. Chaque
lien est constitue du nom du site suivi du co^ut imaginaire de la connexion, indique
entre parentheses. Il s'agit d'une expression arithmetique, faite de valeurs et de prix
symboliques. Les lignes commencant par un diese sont ignorees.
Par exemple, considerons moria, qui appelle swim.twobirds.com deux fois par jour
et bert.sesame.com une fois par semaine. De plus, la liaison avec bert ne se fait
qu'avec un vieux modem 2 400 bps, tres lent. La carte publiee par moria serait alors
la suivante :
moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW)

moria.orcnet.org = moria

La derniere ligne la ferait conna^tre aussi sous son nom UUCP. Notez que DAILY/2
correspond a deux appels par jour, alors que DAILY*2 signi erait un appel tous les
deux jours.
Avec ces informations, la commande pathalias est capable de determiner les routes
optimales a destination de tout site cite dans le chier paths, et de produire une base
de donnees pathalias qui pourra alors ^etre utilisee pour le routage vers ces sites.
Le programme pathalias o re plusieurs autres possibilites, consultez sa page de ma-
nuel, ainsi qu'une liste complete des prix symboliques.
Dans la carte, les commentaires contiennent generalement des informations supple-
mentaires sur les sites decrits. Il existe un format tres strict pour la speci cation de
ces renseignements, de maniere a pouvoir les recuperer par programme. Par exemple,
la commande uuwho utilise une base de donnees realisee a partir de ces cartes pour
acher toutes les informations selon un format agreable a lire.
13.6. Con guration de elm 215

Lorsque vous enregistrez votre site aupres d'un organisme qui distribue des cartes a
ses membres, vous devrez en principe remplir une telle entree.
Voici un exemple d'entree dans les cartes UUCP (en fait, il s'agit de celle du site de
l'auteur) :
#N monad, monad.swb.de, monad.swb.sub.org
#S AT 486DX50; Linux 0.99
#O private
#C Olaf Kirch
#E okir@monad.swb.de
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U brewhq
#W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad brewhq(DAILY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org

Le blanc suivant les deux premiers caracteres doit ^etre une tabulation. La signi cation
des champs est evidente ; vous recevrez tout le detail lorsque vous vous enregistrerez.
Le champ L est le plus dicile a remplir : il donne votre position geographique en
latitude/longitude, et n'est plus utilise que pour dessiner la carte au format PostScript
qui montre tous les sites de chaque pays 6.

13.6 Con guration de elm


Le programme elm est l'un des outils UNIX les mieux nommes : (( elm )) signi e (( elec-
tronic mail )), soit courrier electronique. Il o re une interface plein ecran tres puissante
et une aide ecace. Nous ne parlerons pas de son utilisation ici, mais seulement de
certaines de ses options de con guration.
En theorie, vous pouvez lancer elm sans l'avoir con gure, et avec un peu de chance,
tout devrait fonctionner quand m^eme. Mais il y a malgre tout certaines options a
initialiser, bien qu'elles ne soient necessaires qu'en quelques occasions.
Au demarrage, elm lit un ensemble de variables indiquees dans le chier elm.rc se
trouvant dans le repertoire /usr/lib/elm. Ensuite, il tente de lire le chier .elm/elmrc
de votre repertoire personnel. Ce chier n'est generalement pas redige a la main, mais
cree automatiquement lorsque vous selectionnez (( save options )) depuis le menu du
programme.
L'ensemble des options de votre chier elmrc est aussi disponible dans le chier global
elm.rc ; le v^otre ne servira qu'a modi er certaines valeurs par defaut positionnees dans
la con guration globale.
6 Ces cartes geographiques sont postees regulierement dans news.lists.ps-maps. Attention, c'est
:
tres gros !
216 Chapitre 13. Le courrier electronique
13.6.1 Con guration generale par elm.rc
Dans le chier global elm.rc, vous devez positionner les options relatives au nom de
votre systeme. Par exemple, a (( La biere virtuelle )), le chier de la machine kro
contiendrait :
#
# Le nom local
hostname = kro
#
# Le domaine
hostdomain = .bibine.com
#
# Le nom pleinement qualifi
e
hostfullname = kro.bibine.com

Ces options determinent la notion qu'aura elm de votre systeme. Bien que ces in-
formations ne soient que rarement utilisees, vous devez les indiquer par precaution.
Notez qu'elles n'ont d'e et que lorsqu'elles se trouvent dans ce chier de con guration
global. Il est impossible de modi er ces valeurs depuis le chier personnel, pour des
raisons de securite evidentes.

13.6.2 Jeux de caracteres nationaux


Il y a eu recemment des propositions pour apporter au standard RFC 822 le support
de divers types de messages, comme le texte pur, des donnees binaires, des chiers
PostScript, etc. L'ensemble de documents RFC traitant de ces possibilites a ete baptise
MIME, ou Multipurpose Internet Mail Extensions (extensions multi-usages au courrier
Internet). Entre autres choses, elles permettent au destinataire de savoir si un jeu de
caracteres di erent de l'ASCII a ete employe pour rediger le message, par exemple
pour obtenir des accents francais. Ce standard est en grande partie supporte par elm.
Le jeu de caracteres utilise en interne par Linux est conforme au standard ISO-8859-
1, egalement connu sous le nom de Latin-1. Tout message utilisant cet ensemble de
caracteres doit (ou devrait) comporter la ligne suivante dans son en-t^ete :

Content-Type: text/plain; charset=iso-8859-1

Le systeme recepteur doit reconna^tre ce champ et prendre les mesures appropriees


lors de l'achage du message. Le defaut pour les messages text/plain est une valeur
charset de us-ascii.
A n de pouvoir acher des messages avec d'autres caracteres que l'ASCII, elm doit
savoir comment le faire. Par defaut, lorsqu'il recoit un courrier dont le champ charset
est di erent de us-ascii (ou un champ Content-Type di erent de text/plain), il essaie
de l'acher en appelant une commande nommee metamail. Les messages necessitant
13.6. Con guration de elm 217

metamail sont indiques par un M dans la toute premiere colonne de la liste du courrier
proposee par elm.
Comme le jeu de caracteres natif de Linux est l'ISO-8859-1, il n'est pas necessaire
d'appeler metamail pour acher des messages utilisant ces caracteres. Si l'on indique
a elm que l'achage conna^t l'ISO-8859-1, il l'achera instantanement, sans appeler
de programme externe. Il sut pour cela de positionner l'option suivante dans le
chier global elm.rc :
displaycharset = iso-8859-1

Notez que vous devez indiquer cette option m^eme si vous n'allez jamais recevoir ou
emettre de messages comportant ces caracteres: les personnes qui postent de tels
courriers con gurent leurs programmes pour qu'ils mettent le champ Content-Type
par defaut, qu'ils utilisent ces caracteres ou ne postent que de l'ASCII.
Toutefois, cette option n'est pas susante. Le probleme est que lorsqu'il ache le
message avec son visionneur interne, elm appelle une fonction de bibliotheque pour
chaque caractere, pour determiner s'il est achable ou pas. Par defaut, cette fonction
ne reconna^t que les caracteres purement ASCII, et ache un point d'interrogation
pour tous les autres. Vous pouvez modi er ce comportement en positionnant la va-
riable d'environnement LC CTYPE a la valeur ISO-8859-1, ce qui indiquera a la
bibliotheque que ces caracteres sont achables. Sous Linux, le support pour l'inter-
nationalisation est present depuis la bibliotheque libc-4.5.8.
Lorsque vous postez des messages contenant des caracteres speciaux du jeu ISO, vous
devez vous assurer de positionner deux autres variables dans le chier global elm.rc :
charset = iso-8859-1
textencoding = 8bit

Ainsi, elm indiquera correctement dans les en-t^etes de tous les courriers di uses que
le jeu de caracteres est ISO-8859-1, et les enverra sur 8 bits (par defaut, le huitieme
bit est mis a zero pour tout transformer en 7 bits).
Bien s^ur, toutes ces options peuvent aussi ^etre positionnees dans le chier de con -
guration personnel elmrc de chaque utilisateur.
218 Chapitre 13. Le courrier electronique
219

Chapitre 14
Mise en route de smail
Ce chapitre sera une rapide initiation a la con guration de smail et vous donnera un
apercu des fonctionnalites o ertes. Bien que ce programme soit largement compatible
avec sendmail dans son comportement, ses chiers de con guration sont completement
di erents.
Le chier de con guration principal s'appelle /usr/lib/smail/con g. Vous devrez obli-
gatoirement editer ce chier pour y placer les valeurs speci ques a votre site. Si vous
n'^etes qu'un petit systeme UUCP, vous n'aurez pratiquement jamais rien d'autre
a faire. D'autres chiers permettant la mise au point des options de routage et de
transport peuvent aussi ^etre utilises, nous en parlerons brievement.
Par defaut, smail traite et delivre immediatement tout le courrier. Si vous avez beau-
coup de tra c, vous prefererez sans doute lui indiquer de rassembler tous les messages
dans ce que l'on appelle une queue, et de ne les traiter qu'a intervalles reguliers.
Lorsque le courrier passe par un reseau TCP/IP, smail est tres souvent utilise en mode
demon : au demarrage du systeme, il est invoque depuis rc.inet2 et se place en t^ache
de fond, ou il attend des connexions TCP sur le port SMTP (le port 25, en principe).
Cette methode est a preferer chaque fois que vous attendez un tra c important, car le
programme n'a pas a ^etre lance separement a chaque connexion. L'alternative serait
de laisser inetd gerer le port SMTP, il appellerait alors smail chaque fois qu'une
connexion sur se port se presenterait.
Smail possede plusieurs options contr^olant son comportement ; les decrire en detail ici
ne vous serait pas tres utile. Heureusement, il supporte un certain nombre de modes
de fonctionnements standards, qui sont valides lorsque vous l'invoquez sous des noms
particuliers, comme par exemple rmail ou smtpd. Generalement, ces alias sont des
liens symboliques vers l'unique binaire smail. Nous rencontrerons la plupart d'entre
eux lorsque nous aborderons les di erentes possibilites o ertes par ce programme.
220 Chapitre 14. Mise en route de smail
En toute circonstance, vous devrez avoir au moins deux liens pointant sur le pro-
gramme smail : /usr/bin/rmail et /usr/sbin/sendmail 1 . Lorsque vous redigez puis
expediez un courrier avec une interface comme elm, le message sera passe a rmail
pour ^etre delivre, avec la liste des destinataires sur la ligne de commandes. La m^eme
chose se passe avec le courrier arrivant par UUCP. Quelques versions de elm invoquent
toutefois /usr/sbin/sendmail, au lieu de rmail, aussi est-il plus prudent de disposer des
deux commandes. Par exemple, si votre binaire de smail se trouve dans /usr/local/bin,
tapez ce qui suit pour creer les liens corrects :

# ln -s /usr/local/bin/smail /usr/bin/rmail
# ln -s /usr/local/bin/smail /usr/sbin/sendmail

Si vous voulez entrer dans le detail de la con guration de smail, referez-vous aux
pages de manuel smail(1) et smail(5). Si vous ne les possedez pas, vous les trouverez
dans les sources du programme.

14.1 Con guration UUCP


Pour utiliser smail dans un environnement uniquement UUCP, l'installation de base
est tres simple. Tout d'abord, veri ez que vous avez bien les deux liens symboliques
vers rmail et sendmail mentionnes plus haut. Si vous comptez recevoir des lots SMTP
en provenance d'autres sites, vous devez aussi creer un lien nomme rsmtp sur smail.
La distribution smail de Vince Skahan fournit un exemple de chier de con guration,
dont le nom est con g.sample ; il se trouve dans /usr/lib/smail. Copiez-le sous le nom
de con g et editez-le pour y placer les valeurs speci ques a votre site.
Considerons que votre machine s'appelle swim.twobirds.com et est enregistree dans
les cartes UUCP en tant que swim. Votre smart host s'appelle ulysses. Votre chier
con g sera alors celui-ci :
#
# Nos noms de domaine
visible_domain=two.birds:uucp
#
# Notre nom pour les courriers 
emis
visible_name=swim.twobirds.com
#
# Ce sera le m^
eme pour UUCP
uucp_name=swim.twobirds.com
#
# Notre smart-host
smart_host=ulysses

1 Il s'agit de l'emplacement standard de sendmail sous Linux, si l'on suit les recommandations
:
du projet du (( Linux File System Standard )). Sur beaucoup d'autres systemes, sendmail se trouve
traditionnellement dans /usr/lib.
14.2. Con guration reseau 221

La premiere instruction renseigne smail sur les domaines auxquels votre site appar-
tient. Mettez leurs noms, separes par le caractere (( : )). Si le nom de votre site est
enregistre dans les cartes UUCP, vous devez egalement ajouter le pseudo-domaine
uucp. Lorsqu'il traite un message, smail determine le nom de votre machine par l'ap-
pel systeme hostname(2), et teste l'adresse du destinataire pour la comparer a ce
nom, en y rajoutant tour a tour tous ces domaines. Si l'adresse correspond a l'un des
cas (ou au nom non quali e), le courrier est considere comme local et sera delivre a
l'utilisateur ou l'alias correspondant sur votre machine. Sinon, il est considere comme
etant distant, et smail tentera de l'expedier a la machine de destination.
La ligne visible name doit contenir un unique nom pleinement quali e, c'est celui que
vous voulez voir appara^tre dans tout le courrier emis. Vous devez ^etre certain que
le nom utilise est reconnu par smail comme celui de l'h^ote local (par exemple, l'une
des combinaisons donnees avec l'attribut visible domain). Sinon, les reponses a vos
messages ne vous arriveraient jamais...
La derniere ligne indique le chemin a utiliser pour atteindre le smart host (decrit dans
le chapitre precedent). Avec cet exemple, smail enverra tout le courrier non local au
smart host. Le nom de cette machine doit ^etre connu par UUCP, puisque c'est le
protocole utilise pour la liaison. Pour cela, consultez le chapitre 12.
Il reste une option dont nous n'avons pas encore parle : uucp name. Par defaut, smail
prend la valeur retournee par hostname(2) pour indiquer les informations speci ques
a UUCP, comme le chemin de retour donne dans la ligne From de l'en-t^ete. Si votre
nom de machine n'est pas enregistre dans les cartes UUCP, vous devez dire a smail
d'y mettre votre nom pleinement quali e a la place 2 . Il sut pour cela de l'ajouter
gr^ace a l'option uucp name du chier con g.
Vous trouverez aussi dans /usr/lib/smail un autre chier, paths.sample. Il s'agit d'un
exemple de chier paths ; mais vous n'en aurez pas besoin, a moins que vous n'ayez
des liaisons avec plusieurs sites pour la distribution du courrier. Si vous devez utiliser
ce chier, il faudra de toute facon le rediger vous-m^eme, ou le creer a partir des cartes
UUCP. Ce chier paths sera decrit plus loin.

14.2 Con guration reseau


Si votre site contient deux h^otes (ou plus) connectes en reseau, vous devrez designer
l'un deux pour la gestion de vos connexions UUCP vers le monde exterieur. Entre les
machines du reseau, vous ferez passer le courrier par SMTP sur TCP/IP. Revenons
dans notre entreprise (( La biere virtuelle )), ou gueuze est con guree en passerelle
UUCP.
2 Voila pourquoi : supposons que votre systeme s'appelle nomade, mais qu'il ne soit pas enregistre
:
dans les cartes. Supposons aussi qu'il existe dans ces cartes un site nomme nomade, quelque part
dans le monde. Tout le courrier adresse a nomade!root, m^eme poste depuis un de vos voisins UUCP,
arrivera sur l'autre machine et non chez vous.
222 Chapitre 14. Mise en route de smail
Dans un environnement reseau, il vaut mieux placer toutes les bo^tes aux lettres
des utilisateurs sur un unique systeme de chiers qui est monte par NFS sur toutes
les autres machines. Cela permet d'utiliser n'importe quel h^ote sans avoir a depla-
cer son courrier (ou pis, tester cinq ou six bo^tes aux lettres di erentes chaque ma-
tin). Par consequent, il vous faudra aussi faire en sorte que les adresses des expe-
diteurs soient independantes de la machine sur laquelle les messages sont rediges.
La pratique courante est de ne mettre que le nom de domaine seul, sans faire ap-
para^tre d'h^ote particulier. Par exemple, ce sera marcel@bibine.com au lieu de
marcel@trappiste.bibine.com. Nous verrons comment faire pour que le nom de
domaine soit reconnu par le serveur comme un nom valide pour votre site.
Une autre methode permettant de conserver toutes les bo^tes aux lettres sur un h^ote
central consiste a utiliser POP ou IMAP. POP signi e (( Post Oce Protocol )) et
permet aux utilisateurs d'acceder a leur courrier par une simple connexion TCP/IP.
IMAP est un protocole interactif d'acces au courrier ((( Interactive Mail Access Pro-
tocol ))) similaire a POP, mais plus general. Clients et serveurs POP et IMAP ont ete
portes sous Linux et sont disponibles sur les sites di usant ce systeme.

14.2.1 Redaction des chiers de con guration


La con guration necessaire pour nos brasseurs fonctionne de la maniere suivante :
Toutes les machines, excepte le serveur de courrier gueuze, routent tous les messages
sortants vers ce serveur par la methode du smart host. Le serveur gueuze envoie
tout ce courrier vers le vrai smart host qui gere la totalite du courrier, cette machine
s'appelle moria.
Le chier con g de tous les h^otes, autres que gueuze est le suivant :
#
# Notre domaine:
visible_domain=bibine.com
#
# Comment nous desirons nous appeler
visible_name=bibine.com
#
# Routage SMTP vers le smart host gueuze:
smart_path=gueuze
smart_transport=smtp

Il est tres semblable a ce que nous avons utilise pour un site uniquement UUCP. La
plus grosse di erence, c'est le transport utilise pour envoyer les messages vers le smart
host, qui est ici SMTP. L'attribut visible domain indique a smail d'ecrire le nom de
domaine speci e dans tout le courrier emis, au lieu du nom local de la machine depuis
laquelle le message est poste.
Sur la passerelle UUCP geuze, le chier con g est un petit peu di erent :
#
14.2. Con guration reseau 223

# Nos noms de machines


hostnames=bibine.com:gueuze.bibine.com:gueuze
#
# Comment nous desirons nous appeler
visible_name=bibine.com
#
# Dans le monde uucp, nous sommes connus sous le nom bibine.com
uucp_name=bibine.com
#
# Smart transport: par uucp vers moria
smart_path=moria
smart_transport=uux
#
# Nous avons autorite pour notre domaine
auth_domains=bibine.com

Ici, la methode pour indiquer a smail quel est notre nom local est di erente. Au lieu
de lui donner une liste de domaines et de le laisser trouver le nom de machine par un
appel systeme, nous lui indiquons explicitement ce qu'il en est. La liste contient a la
fois le nom pleinement quali e et celui non quali e, et le nom du domaine lui-m^eme.
Ainsi, smail reconna^tra marcel@bibine.com comme une adresse locale et delivrera
le message a l'utilisateur marcel.
La variable auth domains indique les domaines pour lesquels gueuze est considere
comme ayant autorite. C'est-a-dire que si smail recoit un courrier adresse a ma-
chine.bibine.com, ou machine ne correspond a aucun h^ote local, il refusera le
message et le renverra a son expediteur. Si cette entree n'est pas presente, tout mes-
sage de ce type serait envoye au smart host, qui le renverrait a son tour a gueuze,
cette partie de ping-pong pouvant durer inde niment. (Heureusement, il est possible
de xer une limite maximale a ce genre de boucle et le message sera nalement perdu.)

14.2.2 Mise en route de smail


Tout d'abord, vous devez decider si vous utiliserez smail en tant que demon separe,
ou si vous preferez que ce soit inetd qui gere le port SMTP et qui l'appelle le moment
venu. Generalement, la solution du demon autonome est preferable sur le serveur de
courrier, car cela charge beaucoup moins la machine que de multiples invocations de
smail chaque fois qu'une connexion se produit. Comme le serveur delivre egalement le
courrier aux utilisateurs, vous prendrez la solution par inetd sur la plupart des autres
machines.
Quel que soit le mode choisi, vous devez veri er que le chier /etc/services de chaque
h^ote contient bien l'entree suivante :
smtp 25/tcp # Simple Mail Transfer Protocol

Elle de nit le port TCP que smail devra utiliser pour les conversations SMTP. Le
port 25 est le standard de ni par le RFC (( Assigned Numbers )).
224 Chapitre 14. Mise en route de smail
En mode demon, smail se place en t^ache de fond et attend les connexions sur le port
SMTP. Pour chacune, il cree un nouveau processus par l'appel systeme fork() pour
le temps de la conversation. Le demon smail est generalement lance au demarrage du
systeme depuis le script rc.inet2 a l'aide de la commande suivante :
/usr/local/bin/smail -bd -q15m

L'option -bd indique le mode demon, et -q15m lui demande de traiter tous les messages
eventuellement accumules dans la queue de courrier toutes les 15 minutes.
Si vous preferez qu'il soit gere par inetd, votre chier /etc/inetd.conf devra contenir
une ligne comme celle-ci :
smtp stream tcp nowait root /usr/sbin/smtpd smtpd

Le programme smtpd devra ^etre un lien symbolique vers le binaire de smail. Souvenez-
vous que pour toute modi cation de ce chier, vous devez demander a inetd de le relire
en lui envoyant un signal HUP, pour que les modi cations soient prises en compte.
Le mode demon et le mode inetd sont mutuellement exclusifs. Si vous utilisez smail en
demon, vous devez vous assurer de bien mettre en commentaire toute ligne relative au
service smtp dans le chier inetd.conf. Inversement, si vous l'utilisez par inetd, veri ez
que rc.inet2 ne lance pas le demon smail.

14.3 Si le courrier ne passe pas


En cas de probleme, vous disposez de plusieurs possibilites d'investigation. La pre-
miere chose a regarder, ce sont les chiers de trace de smail. Ils se trouvent dans
/var/spool/smail/log et se nomment log le et paniclog. Le premier contient toutes les
transactions, alors que le second n'est destine qu'aux messages d'erreur relatifs a la
con guration.
Voici une entree du chier log le :
04/24/94 07:12:04: [m0puwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] delivered
| via: gueuze.bibine.com
| to: root@gueuze.bibine.com
| orig-to: root@gueuze.bibine.com
| router: smart_host
| transport: smtp

Nous y voyons qu'un message de l'utilisateur root ayant pour adresse de destination
root@gueuze.bibine.com a ete correctement delivre a la machine gueuze par le
protocole SMTP.
14.3. Si le courrier ne passe pas 225

Les courriers que smail ne peut pas delivrer generent une entree similaire, mais avec
un message d'erreur a la place de la partie delivered :
04/24/94 07:12:04: [m0puwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] root@gueuze.bibine.com ... deferred
(ERR_148) transport smtp: connect: Connection refused

L'erreur ci-dessus est typique lorsque smail reconna^t correctement que le message
doit ^etre delivre a gueuze, mais qu'il n'arrive pas a se connecter sur le service SMTP
de cette machine. Si cela se produit, vous devez avoir un probleme de con guration,
ou le support de TCP est absent dans votre binaire de smail.
Ce cas n'est pas si rare. Il a circule des versions precompilees de smail, y compris dans
certaines distributions de Linux, sans support pour le reseau TCP/IP. Si vous ^etes en
possession de l'une d'elles, vous devrez recompiler correctement le programme. Pour
veri er, vous pouvez tester si smail supporte TCP en connectant par telnet le port
SMTP de votre machine. Voici a quoi ressemble une connection reussie :

$ telnet localhost smtp


Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 renux.frmug.fr.net Smail3.1.28.1 #3 ready at Sun, 25 Dec 94 14:59 MET
QUIT
221 renux.frmug.fr.net closing connection

Si ce test n'ache pas la banniere SMTP (la ligne commencant par le code 220),
veri ez d'abord que votre con guration est vraiment correcte avant de vous lancer
dans la compilation de smail, que nous allons maintenant decrire.
Si vous rencontrez un probleme que vous n'arrivez pas a situer dans les messages
d'erreurs generes par smail, vous pouvez mettre en route les messages de deboguage.
Il sut d'employer l'option -d suivie d'une valeur facultative, speci ant le niveau
de verbosite desire (ne mettez pas d'espace entre l'option et la valeur). Toutes les
operations qu'e ectuera smail s'acheront alors a l'ecran, ce qui pourra vous aider a
situer a quel moment le probleme se produit.
Si vraiment rien ne va plus, vous pouvez invoquer le mode Rogue de smail en lui
passant l'option -bR sur la ligne de commandes. La page de manuel dit a peu pres
ceci : (( Entrez dans le monde hostile des messages geants, ou de lent les standards
RFC. Tente de descendre au niveau de protocole 26, et de revenir a la normale. ))
Cette option ne reglera s^urement pas vos problemes, mais elle vous apportera peut-
^etre quelque consolation. :-)
226 Chapitre 14. Mise en route de smail
14.3.1 Compilation de smail
Si vous ^etes certain que le support reseau manque dans votre version de smail, vous
devrez vous procurer les sources. Vous les trouverez sur tous les sites di usant Linux,
et bien d'autres serveurs FTP. Si vous avez obtenu Linux sur un CD-ROM, elles se
trouvent sans aucun doute dessus 3 .
Pour compiler smail, vous devez partir de l'ensemble des chiers de con guration four-
nis avec la distribution newspak de Vince Skahan (vous gagnerez un temps precieux,
m^eme si vous ^etes un programmeur con rme). Pour valider le support du reseau
TCP/IP, vous devez positionner la macro DRIVER CONFIGURATION du chier
conf/EDITME soit a bsd-network, soit a arpa-network. La premiere valeur est cor-
recte pour une utilisation sur reseau local, mais pour l'Internet il faudra choisir la
seconde. La di erence est que l'option arpa-network inclut un pilote pour le service
BIND, capable de reconna^tre les enregistrements MX, ce que bsd-network ne sait pas
faire.

14.4 Modes de distribution du courrier


Comme nous l'avons vu, smail est capable de delivrer les messages immediatement, ou
de les mettre en attente dans une queue pour les gerer plus tard. Si vous choisissez la
queue, smail stockera tout le courrier dans le repertoire messages de /var/spool/smail.
Il ne traitera rien tant qu'on ne lui demandera pas de le faire. (L'operation s'appelle
en anglais (( running the queue )), ce que certains traduisent de maniere humoristique
par (( vider la queue )).)
Vous pouvez choisir parmi trois modes en positionnant l'attribut delivery mode dans
le chier con g sur l'une des valeurs foreground, background, ou queued. Cela selec-
tionnera respectivement le traitement en avant-plan (gestion immediate des messages
qui arrivent), en arriere-plan (le courrier est delivre par un processus ls de smail),
et en le d'attente. Le courrier entrant sera toujours mis dans une queue, quelle que
soit l'option choisie, si la variable booleenne queue only est positionnee dans le chier
con g.
Si vous validez cette le d'attente, vous devrez vous assurer qu'elle est traitee regulie-
rement, en general toutes les 10 a 15 minutes. Si vous utilisez smail en mode demon,
vous devrez ajouter l'option -q10m sur la ligne de commandes pour que la queue soit
traitee toutes les 10 minutes environ. Vous pouvez aussi faire invoquer la commande
runq par cron a intervalles reguliers. Cette commande est un lien sur smail.
Vous pouvez acher le contenu courant de la queue en invoquant smail avec l'option
-bp ; ou alors vous pouvez appeler la commande mailq, qui est l a encore un simple
3 Si vous avez (( achete )) une distribution de Linux comportant smail, le vendeur est tenu de vous
:
fournir le code source de ce programme sans autre supplement de prix que l'expedition du support,
selon la licence de copie de smail.
14.5. Options diverses du chier con g 227

lien sur smail :


$ mailq -v
m0pvB1r-00023UB From: root (in /var/spool/smail/input)
Date: Sun, 24 Apr 94 07:12 MET DST
Args: -oem -oMP sendmail root@gueuze.bibine.com
Log of transactions:
Xdefer: <root@gueuze.bibine.com> reason: (ERR_148) transport smtp:
connect: Connection refused

Elle montre ici qu'un seul message est en attente. La trace de transaction (qui ne
sera achee que si vous appelez mailq avec l'option -v) peut donner la raison pour
laquelle il est toujours en attente d'^etre delivre. Si aucune tentative de distribution
n'a encore ete faite, aucune trace de transaction ne sera indiquee.
M^eme si vous n'employez pas de le d'attente, smail l'utilisera quand m^eme en cer-
taines occasions, lorsqu'il ne peut delivrer un message en raison d'un probleme mo-
mentane. Dans le cas de connexions SMTP, ce peut ^etre une machine injoignable,
mais le courrier sera aussi stocke si le systeme de chiers est plein. Il faut donc impe-
rativement traiter la queue au moins toutes les heures, sinon les eventuels messages
en attente y resteraient pour l'eternite.

14.5 Options diverses du chier con g


Voici quelques-unes des options les plus utiles que vous pouvez positionner dans le
chier de con guration :
error copy postmaster
Si cette variable booleenne est positionnee, tout message d'erreur
generera un courrier au postmaster. Il faut faire suivre cette variable
du signe plus (+) dans le chier con g pour valider ce mode.
max hop count Si le nombre de hops (nombre d'h^otes deja traverses par le mes-
sage) est superieur ou egal a cette valeur, toute tentative de distri-
bution distante resultera en un message d'erreur, retourne a l'expe-
diteur. Cette option est utilisee pour prevenir les bouclages in nis.
Le nombre de hops est generalement calcule en comptant la quantite
de champs Received dans l'en-t^ete du message, mais peut aussi ^etre
indique explicitement par l'option -h de la ligne de commandes.
La valeur par defaut de cette variable est 20.
postmaster L'adresse du postmaster. Si l'adresse Postmaster ne peut pas ^etre
resolue en une adresse locale valide, c'est celle-ci qui sera utilisee en
dernier lieu. Sa valeur par defaut est root.
228 Chapitre 14. Mise en route de smail
14.6 Routage et distribution
Smail divise la distribution du courrier en trois t^aches di erentes, gerees respective-
ment par le module routeur, le module directeur, et le module de transport.
Le routeur resout toutes les adresses distantes, determinant vers quel h^ote le message
doit ^etre envoye et quel type de transport doit ^etre utilise. En fonction de la nature
de la liaison, di erents transports comme UUCP ou SMTP peuvent ^etre employes.
Les adresses locales sont passees au module directeur, qui resout les alias ou les relais.
Par exemple, ce peut ^etre un alias ou une liste de di usion, ou l'utilisateur peut
vouloir renvoyer tout son courrier a une autre adresse. Si la destination qui en resulte
est distante, elle est geree par le module routeur pour ce routage supplementaire,
sinon il est decide d'un transport pour la distribution locale. En principe, le cas le
plus courant sera l'ajout a une bo^te aux lettres, mais il est aussi possible que les
messages soient envoyes a une commande externe ou ajoutes a tout autre chier.
Le module de transport est responsable de la methode de transfert qui a ete choisie.
Il essaie de delivrer le message, et en cas d'echec, genere un courrier de rejet ou le
stocke en attente d'une nouvelle tentative.
Avec smail, vous avez toute liberte pour con gurer ces t^aches. Pour chacune, un cer-
tain nombre de pilotes sont fournis, et vous pouvez choisir celui dont vous avez besoin.
Vous les decrivez a smail dans trois chiers, nommes routers, directors et transports,
situes dans /usr/lib/smail. Si ces chiers n'existent pas, le programme prendra des
valeurs par defaut raisonnables qui devraient fonctionner pour beaucoup de sites uti-
lisant SMTP ou UUCP pour le transport. Si vous desirez changer le comportement de
smail concernant le routage, ou modi er un transport, vous devez prendre les chiers
d'exemples fournis dans la distribution source du programme 4. Copiez ces exemples
dans /usr/lib/smail, et modi ez-les selon vos besoins. Vous trouverez des exemples
dans l'annexe B.

14.7 Routage des messages


Lorsqu'on lui passe un message, smail commence par regarder si la destination est
locale ou distante. Si elle correspond a l'un des noms locaux con gures dans le chier
con g, le message est passe au module directeur. Sinon, smail donne l'adresse de des-
tination a un certain nombre de pilotes de routage pour trouver a quel site s'adresser.
Ils peuvent ^etre decrits dans le chier routers ; s'il n'existe pas, c'est un ensemble de
routeurs par defaut qui sera utilise.
L'h^ote de destination est passe a tous les routeurs tour a tour, et celui qui trouve
la route la plus speci que est selectionne. Considerons un message adresse a al-
fred@toto.titi.com. Un routeur peut conna^tre une route par defaut pour tous les
4 Les chiers de con guration par defaut se trouvent dans le repertoire samples/generic.
:
14.7. Routage des messages 229

h^otes du domaine titi.com, alors qu'un autre a des informations sur toto.titi.com.
Dans ce cas, comme c'est le dernier qui est le plus speci que, c'est lui qui sera choisi.
Si deux routeurs arrivent a egalite, c'est le premier rencontre dans le chier routers
qui sera selectionne.
Maintenant, ce routeur speci e un transport a utiliser, par exemple UUCP, et ge-
nere une nouvelle adresse de destination. La nouvelle adresse est passee au mo-
dule de transport avec le nom de la machine a laquelle renvoyer le message. Dans
notre exemple ci-dessus, smail pourra trouver que toto.titi.com peut ^etre atteint
par UUCP en utilisant le chemin ernie!bert. Il generera alors une nouvelle cible,
bert!toto.titi.com!alfred, qui sera l'adresse d'enveloppe pour le transport UUCP
qui sera passee a ernie.
Avec la con guration par defaut, sont disponibles les modules routeurs suivants :
{ Si l'adresse de la machine de destination peut ^etre resolue par les fonctions
gethostbyname(3) ou gethostbyaddr(3), le message sera delivre par SMTP. La
seule exception sera lorsque cette adresse correspondra a la machine locale ; il
sera alors passe au module directeur.
Les adresses IP sont egalement reconnues comme noms legaux, tant qu'elles
peuvent ^etre resolues par la fonction gethostbyaddr(3). Par exemple, duge-
nou@[149.76.12.4] est une adresse valide, bien que peu habituelle ; elle cor-
respond selon nos exemples a l'adresse de l'utilisateur dugenou sur la machine
quark.physique.groucho.edu.
Si votre machine est sur l'Internet, ces routeurs ne sont pas ceux qu'il vous faut
car ils ne reconnaissent pas les enregistrements de type MX. Nous verrons plus
loin ce qu'il faut faire dans ce cas.
{ Si /usr/lib/smail/paths, la base de donnees pathalias, existe, smail essaiera de
trouver la machine destinataire (amputee de tout pseudo-domaine .uucp) dans
ce chier. Le courrier a destination d'une adresse trouvee par ce routeur sera
delivre par UUCP en utilisant le chemin indique dans la base de donnees.
{ L'adresse (amputee de tout pseudo-domaine .uucp) sera comparee a la sortie
de la commande uuname pour tester si la cible est en fait un voisin UUCP. Si
c'est le cas, le message sera delivre par UUCP.
{ Si l'adresse n'a pu ^etre geree par aucun des routeurs precedents, le message sera
delivre au smart host. Le chemin vers cette machine, et le transport a utiliser,
sont con gures dans le chier con g.
Ces valeurs par defaut fonctionnent pour beaucoup de petits sites, mais echouent
des que le routage necessaire est un peu plus complique. Si vous ^etes confronte a
l'un des problemes que nous allons expliquer ci-dessous, vous devrez installer votre
propre chier routers pour modi er ces comportements par defaut. Vous en trouverez
un exemple dans l'annexe B, qui pourra vous servir de point de depart. Certaines
230 Chapitre 14. Mise en route de smail
distributions de Linux sont fournies avec un ensemble de chiers de con guration
etudies pour contourner ces dicultes.
Le pire des cas est probablement lorsque votre machine est reliee a l'exterieur a la fois
par des liaisons UUCP et des connexions IP temporaires, avec PPP ou SLIP. Vous
aurez dans votre chier hosts, le nom de certains h^otes avec lesquels vous communiquez
de temps en temps en IP, et smail tentera de delivrer tout courrier pour ces machines
par SMTP. Ce n'est s^urement pas ce que vous desirez, car m^eme si la liaison SLIP est
regulierement active, le transfert par SMTP est bien plus lent que par UUCP. Avec
la con guration par defaut, il n'y a pas de solution.
Pour eviter ce probleme, il va falloir que smail teste le chier paths avant d'interroger
le resolver, et que vous mettiez tous les h^otes pour lesquels vous voulez forcer un
transport UUCP dans ce chier. Si vous ne voulez jamais utiliser SMTP, vous pou-
vez egalement mettre en commentaire tout ce qui concerne les routeurs bases sur le
resolver.
La con guration par defaut sou re d'un autre probleme : elle ne peut faire de reel
routage Internet, car le routeur ne sait pas evaluer les MX. Pour remedier a cela,
vous devez mettre entre commentaires le routeur par defaut et supprimer les com-
mentaires de celui qui utilise BIND. Il existe cependant des distributions de Linux qui
fournissent un binaire de smail dans lequel le support de BIND n'est pas compile. Si
vous validez le bon routeur, mais que vous obtenez dans le chier paniclog un message
disant : (( router inet hosts: driver bind not found )), vous devrez recompiler
smail (voyez la section (( Con guration reseau )) plus haut).
En n, l'utilisation du pilote uuname est en general une mauvaise idee. D'une part,
il generera une erreur de con guration si vous n'avez pas installe UUCP, car il ne
trouvera pas la commande uuname. D'autre part, vous pouvez avoir plus de sites
indiques dans votre chier Systems de UUCP, que vous n'avez de liaisons pour le
courrier. Il peut s'agir de machines avec lesquelles vous n'echangez que des chiers ou
des News Usenet, par exemple.
Pour contourner le premier probleme, il est facile de substituer un shell-script a la
commande uuname, qui fera un simple exit 0. La solution la plus propre est toutefois
d'editer le chier routers pour supprimer ce pilote.

14.7.1 La base de donnees paths


Smail s'attend a trouver la base de donnees pathalias dans le chier paths du repertoire
/usr/lib/smail. Ce chier n'est pas obligatoire, aussi si vous ne comptez pas e ectuer
de tels routages, supprimez-le s'il existe.
Il s'agit d'un chier ASCII, trie par ordre alphabetique, qui contient des entrees
mettant en correspondance des noms de sites avec des chemins UUCP. Le tri est obli-
gatoire en raison de l'algorithme de recherche employe par smail. Les commentaires
ne sont pas autorises, et les noms de sites doivent ^etre separes des chemins par une
14.8. Gestion des adresses locales 231

tabulation. Les bases de donnees pathalias sont presentees avec un peu plus de details
dans le chapitre 13.
Si vous realisez ce chier a la main, vous devez faire bien attention d'y mettre tous les
noms legaux d'un site. Par exemple, si une machine est connue a la fois par un nom
purement UUCP et un nom pleinement quali e, il faudra une entree pour les deux
cas. Le chier peut ^etre trie par la commande standard sort(1).
Si votre site est juste un petit site UUCP isole en bout de cha^ne, aucun chier paths
ne sera necessaire; il sut de con gurer le smart host dans le chier con g, et laisser
cette machine s'occuper de router tous vos messages pour vous.

14.8 Gestion des adresses locales


Le plus souvent, une adresse locale n'est qu'un nom d'utilisateur, et le message est de-
livre dans sa bo^te aux lettres, /var/spool/mail/nom-utilisateur. Mais il existe d'autres
cas ou cette adresse est un alias, le nom d'une liste de di usion, ou une autre adresse
a laquelle l'utilisateur veut renvoyer son courrier. Dans tous ces cas, cette adresse est
expansee en une nouvelle liste d'adresses, qui peuvent ^etre soit locales, soit distantes.
En dehors de ces cas (( normaux )), smail peut gerer d'autres types de destinations
locales, comme des noms de chiers et des tubes vers des commandes. Ce ne sont
pas a proprement parler des adresses, aussi est-il impossible d'envoyer un courrier a,
disons, /etc/passwd@bibine.com ; elles ne sont valides que si elles ont ete prises
dans un chier de renvoi ou d'alias.
Un chier sera n'importe quoi commencant par le caractere slash (/) ou par un tilde
(~). Ce dernier reference le repertoire personnel de l'utilisateur et n'est possible que
si le nom de chier provient du chier .forward ou d'une entree de renvoi dans la
bo^te aux lettres (voir plus loin). Lorsqu'il delivre un message dans un chier, smail
le rajoute a la n des donnees deja existantes, ou cree le chier s'il n'existait pas.
Une commande tube 5 peut ^etre n'importe quelle commande UNIX precedee du sym-
bole tube (|). Dans ce cas, smail passe la commande et ses arguments au shell, sans
le | du debut. Le message est envoye sur l'entree standard de cette commande.
Par exemple, pour envoyer une liste de di usion dans un forum local, vous pouvez
utiliser un shell-script, appelons-le mon ltre, et positionner un alias local qui delivre
tous les messages de cette liste a ce script en utilisant "|monfiltre".
Si l'invocation contient des espaces, il faut la mettre entre quotes (" "). En raison des
problemes de securite mis en jeu, la commande ne sera pas executee si l'adresse a ete
obtenue d'une facon douteuse (par exemple, si le chier d'alias d'ou provient l'adresse
est en ecriture pour tout le monde).
5 Pipe.
:
232 Chapitre 14. Mise en route de smail
14.8.1 Utilisateurs locaux
Une adresse locale denote le plus souvent une bo^te aux lettres d'utilisateur. Il s'agit
d'un chier situe dans /var/spool/mail qui porte le nom de cet utilisateur. Il a le mode
660, les proprietaires etant l'utilisateur et le groupe mail. S'il n'existe pas, smail le
creera.
Notez que, bien que /var/spool/mail soit le repertoire standard pour les bo^tes aux
lettres, certains programmes peuvent ^etre compiles avec d'autres chemins d'acces,
comme par exemple /usr/spool/mail. Si le courrier echoue toujours, veri ez ce chemin
d'acces et creez un lien symbolique vers /var/spool/mail si necessaire.
Smail requiert deux adresses : MAILER-DAEMON et Postmaster. Lorsqu'il ge-
nere un courrier de rejet pour un message impossible a delivrer, une copie est en-
voyee au compte postmaster pour examen (au cas ou ce serait d^u a un probleme de
con guration). L'utilisateur MAILER-DAEMON est utilise comme expediteur du
message de rejet.
Si ces adresses n'aboutissent pas a des comptes valides sur votre systeme, smail enverra
automatiquement tout ce qui est destine a MAILER-DAEMON a postmaster, et
si ce dernier n'existe pas non plus, ce sera root qui recuperera le tout. En general, on
positionne postmaster comme un alias du compte de l'utilisateur qui est responsable
de l'administration du courrier electronique.

14.8.2 Renvoi de courrier


Tout utilisateur peut rediriger son courrier vers une autre adresse par l'une des deux
methodes supportees par smail. La premiere consiste a mettre

Forward to destinataire, :::

dans la premiere ligne de son chier de bo^te aux lettres. Tout son courrier sera alors
envoye aux destinataires indiques. L'autre solution est de creer un chier .forward
dans son repertoire personnel, contenant la liste des destinataires, separes par des
virgules. Avec cette methode, toutes les lignes du chier sont lues et interpretees.
N'importe quel type d'adresse peut ^etre utilise. Un exemple pratique de chier .for-
ward pendant la periode des vacances pourrait ^etre :

marcel, "|vacation"

La premiere adresse delivre le courrier a l'utilisateur marcel, et la seconde appelle la


commande vacation, destinee a envoyer un petit mot a l'expediteur pour lui indiquer
la situation.
14.8. Gestion des adresses locales 233

14.8.3 Les alias


Le programme smail est capable de manipuler des chiers d'alias compatibles avec
ceux connus par le programme sendmail de Berkeley. Les entrees sont de la forme :
alias: destinataires

Ou destinataires est une liste d'adresses, separees par des virgules, qui seront sub-
stituees a cet alias. La liste peut s'etendre sur plusieurs lignes si la ligne suivante
commence par une tabulation.
Une possibilite supplementaire o erte par smail consiste a pouvoir gerer des listes
de di usion directement depuis le chier d'alias : si vous speci ez :include:fichier
comme destinataire, smail lira le chier indique et son contenu sera considere comme
une liste de destinataires.
Le chier d'alias principal se nomme /usr/lib/aliases. Si vous choisissez de rendre ce
chier modi able par tout le monde, smail ne delivrera aucun message aux commandes
shell qu'il y rencontrera, par securite. Voici un exemple de chier /usr/lib/aliases :
# bibine.com fichier /usr/lib/aliases
hostmaster: marcel
postmaster: marcel
usenet: alfred
# La liste de diffusion des developpeurs.
developpement: rene, remy, roberto, boudinus
/var/mail/log/developpement
owner-developpement: roberto
# Les annonces d'int
er^
et g
eneral sont envoy
ees 
a tout
# le staff
annonces: :include: /usr/lib/smail/staff,
/var/mail/log/annonces
owner-annonces: root
# Envoie la liste de diffusion ppp vers un forum local.
ppp-list: "|/usr/local/lib/monfiltre local.listes.ppp"

Si une erreur se produit sur une adresse generee depuis le chier aliases, smail ten-
tera d'envoyer une copie du message d'erreur a l'alias (( owner )) (le proprietaire).
Par exemple, si lors de la repartition de la liste de di usion de developpement, il est
impossible de delivrer le courrier a boudinus, une copie du message d'erreur sera
postee a l'expediteur, aussi bien qu'a postmaster et owner-developpement (ro-
berto dans cet exemple). Si cette derniere adresse n'existe pas, aucun message d'erreur
supplementaire ne sera genere.
Lorsqu'il delivre du courrier dans des chiers ou lorsqu'il invoque des programmes
indiques dans le chier aliases, smail devient l'utilisateur nobody le temps de l'ope-
ration, par securite. Ce peut ^etre tres g^enant, particulierement lorsque la destination
est un chier. Dans l'exemple ci-dessus, les chiers du repertoire log doivent pouvoir
^etre ecrits par nobody et doivent lui appartenir, sinon rien n'y sera delivre.
234 Chapitre 14. Mise en route de smail
14.8.4 Listes de di usion
Au lieu d'utiliser le chier aliases, les listes de di usion peuvent aussi ^etres gerees
par des chiers situes dans le repertoire /usr/lib/smail/lists. Une liste de di usion
nommee restaurants sera decrite par le chier lists/restaurants, qui devra contenir les
adresses des membres de cette liste, separees par des virgules. Il peut y avoir plusieurs
lignes, et on peut y introduire des commentaires par le traditionnel signe diese.
Pour chaque liste de di usion, un utilisateur (ou un alias) dont le nom est de la
forme owner-nom-de-la-liste doit exister ; toute erreur se produisant lors de la
resolution des adresses sera rapportee a cet utilisateur. C'est aussi l'adresse qui sera
utilisee comme etant celle de l'expediteur sur tous les messages emis, par le champ
Sender de l'en-t^ete.

14.9 Transport par UUCP


Un certain nombre de transports compiles dans smail font appel a la serie de pro-
grammes composant UUCP. Dans un environnement UUCP, le courrier est genera-
lement delivre en invoquant rmail sur la machine distante, en lui passant le message
sur l'entree standard et l'adresse d'enveloppe sur la ligne de commandes. Sur votre
machine, rmail doit ^etre un lien vers le programme smail.
Lorsqu'il passe un message a UUCP, smail convertit l'adresse de destination en un
chemin UUCP, avec la notation par bangs. Par exemple, utilisateur@machine sera
transforme en machine!utilisateur. Chaque occurrence de l'operateur d'adressage %
est preservee, par consequent une adresse comme utilisateur%machine@passerelle
deviendra alors passerelle!utilisateur%machine. Toutefois, smail ne generera ja-
mais ce type d'adresses lui-m^eme.
Alternativement, smail peut envoyer et recevoir des lots BSMTP par UUCP. Avec
BSMTP, un ou plusieurs messages sont rassembles en un seul lot qui contient les
commandes que le MTA local aurait executees si une veritable connexion SMTP avait
ete etablie. Cette methode est souvent utilisee pour economiser de la place disque.
Le chier transports donne en exemple dans l'annexe B contient un transport bsmtp
associe qui genere des lots BSMTP partiels dans un repertoire d'attente. Ils devront
ensuite ^etre combines en lots de nitifs par un shell-script qui rajoutera les commandes
HELO et QUIT necessaires.
Pour valider le transport bsmtp sur des liens UUCP speci ques, vous devrez utiliser
les chiers method (consultez la page de manuel smail(5) pour plus de details). Si
vous n'avez qu'une seule liaison UUCP et que vous employez le routeur smart host,
vous pouvez mettre en service les lots SMTP en mettant la variable de con guration
smart transport a bsmtp au lieu de uux.
Pour recevoir des lots SMTP via UUCP, vous devez veri er que vous possedez la
commande d'extraction correspondant aux lots que le site distant vous prepare. Si ce
14.10. Transport par SMTP 235

dernier utilise aussi smail, vous devrez creer un lien nomme rsmtp vers le programme
smail. S'il s'agit de sendmail, vous devrez installer un shell-script que vous appellerez
/usr/bin/bsmtp, qui fera tout simplement (( exec rsmtp )) (un lien symbolique ne
marchera pas).

14.10 Transport par SMTP


Smail supporte un pilote SMTP permettant de delivrer du courrier par une connexion
TCP 6 . Il est capable de delivrer un message a un nombre quelconque d'adresses
sur une machine, dont le nom est speci e soit sous la forme pleinement quali ee
pouvant ^etre resolu par la couche reseau, soit sous forme d'adresse IP en notation
decimale, contenue entre crochets. Generalement, les adresses resolues par l'un des
pilotes des routeurs BIND, gethostbyname(3) ou gethostbyaddr(3) seront atteintes
par le transport SMTP.
Le pilote SMTP tentera immediatement de se connecter a la machine distante par le
port smtp indique dans /etc/services. Si la connexion ne peut se faire, smail retentera
l'operation un peu plus tard.
Delivrer du courrier sur l'Internet necessite que les routes vers l'adresse de destina-
tion soient speci ees selon le format des adresses de routage (route-addr) decrit dans
le chapitre 13, plut^ot que dans la notation par bangs 7 . Par consequent, smail trans-
formera une adresse comme utilisateur%machine@passerelle, ou passerelle est
atteinte, par exemple, par le chemin machine1!machine2!machine3, en l'adresse
de routage :
<@machine2,@machine3:utilisateur%machine@passerelle>, qui sera donc en-
voyee a machine1 comme adresse d'enveloppe du message. Pour valider ces transfor-
mations (avec le pilote BIND integre), vous devrez editer l'entree pour le pilote smtp
dans le chier transports. Un exemple de chier transports est donne dans l'annexe B.

14.11 Quali cation de noms


Il est quelquefois necessaire de detecter les noms d'h^otes non quali es (c'est-a-dire
sans nom de domaine) speci es dans une adresse d'expediteur ou de destinataire,
par exemple en cas de passerelle entre deux reseaux dont l'un necessite des noms
pleinement quali es. Sur un relais Internet-UUCP, les noms de machines non qua-
li es doivent ^etre mis dans le pseudo-domaine uucp par defaut. Des modi cations
d'adresses autres que celles-ci sont tres discutables.
6 Les auteurs l'appellent (( simple )). Pour les futures versions de smail, ils annoncent une reecriture
:
totale qui gerera ce cas beaucoup plus ecacement.
7 Toutefois, l'usage de routes sur l'Internet est fortement deconseille. Il faut utiliser des noms
:
pleinement quali es.
236 Chapitre 14. Mise en route de smail
Le chier /usr/lib/smail/qualify indique a smail quels noms de domaines rajouter a
quels noms d'h^otes. Les entrees de ce chier consistent en un nom de machine commen-
cant sur la premiere colonne, suivi par un nom de domaine. Le signe diese introduit
un commentaire. Ces entrees sont recherchees dans l'ordre ou elles apparaissent.
Si ce chier n'existe pas, aucune quali cation de noms ne sera e ectuee.
Le caractere * correspond a tout nom de machine, ce qui vous permet d'associer tout
h^ote non mentionne auparavant dans un domaine par defaut. Il ne doit ^etre utilise
que pour la derniere entree, bien entendu.
A (( La biere virtuelle )), toutes les machines ont ete con gurees pour utiliser des
noms pleinement quali es dans les adresses des expediteurs. Les adresses recues non
quali ees sont considerees ^etre toutes dans le domaine uucp, aussi il sut d'une
entree dans le chier qualify :
# /usr/lib/smail/qualify, derni
ere modification le 25 Dec. 94 par Noel
#
* uucp
237

Chapitre 15
Sendmail+IDA
15.1 Introduction a Sendmail+IDA
On dit souvent que celui qui n'a jamais edite un chier sendmail.cf n'est pas un
veritable administrateur UNIX. La legende dit aussi qu'il ne faut jamais le faire deux
fois, sous peine de devenir fou.
Sendmail est un programme o rant des possibilites incroyables. Pour la plupart des
gens, il est aussi incroyablement dicile a apprendre et a comprendre. Tout pro-
gramme dont la reference absolue (sendmail, par Brian Costales, Eric Allman et Neil
Rickert) fait 792 pages, a de quoi epouvanter les plus temeraires.
Sendmail+IDA est di erent. Avec lui, plus besoin d'editer le redoutable chier send-
mail.cf, il permet a l'administrateur de de nir le routage et la con guration speci ques
au site par des chiers relativement simples a comprendre, appeles tables. Passer a
Sendmail+IDA peut vous faire economiser beaucoup d'heures de travail et de stress.
Compare aux principaux autres agents de transport de courrier, il n'y a probablement
rien qui ne puisse ^etre fait plus rapidement et simplement qu'avec Sendmail+IDA.
Les t^aches classiques consistant a con gurer un site UUCP ou Internet deviennent
simples a accomplir. Les con gurations qui sont normalement longues et complexes
sont faciles a creer eta maintenir.
A l'heure ou nous ecrivons ces lignes, la version courante, sendmail5.67b+IDA1.5, est
disponible par FTP anonyme sur le site vixen.cso.uiuc.edu. Elle se compile sous
Linux sans aucune modi cation 1 .
1 La version courante, a l'heure ou ces lignes sont traduites, est sendmail 8.6.9, qui est fournie sous
:
forme binaire dans les distributions de Linux et utilisee sur bien d'autres systemes. Elle est beaucoup
plus simple et universelle, et sa con guration n'a plus rien a voir avec sendmail5.67b+IDA1.5 qui,
bien que decrit dans ce livre, est obsolete.
238 Chapitre 15. Sendmail+IDA
Tous les chiers de con guration requis pour la compilation de Sendmail+IDA, son
installation et son utilisation sous Linux sont inclus dans l'archive newspak-2.2.tar.gz,
disponible par FTP anonyme sur le site d'archivage sunsite.unc.edu, dans le reper-
toire /pub/Linux/system/Mail.

15.2 Apercu des chiers de con guration


Le programme sendmail se con gure par un chier de con guration systeme (typique-
ment /etc/sendmail.cf ou /usr/lib/sendmail.cf) dont la syntaxe ne ressemble a aucun
des langages que vous avez pu rencontrer auparavant. E diter sendmail.cf pour obtenir
une con guration sur mesure peut ^etre une experience traumatisante pour certains.
Avec Sendmail+IDA, tout cela devient du passe. Toutes les options sont de nies par
des tables et une syntaxe tres simple a assimiler. Elles sont con gurees en executant
m4 (un processeur de macro-instructions) ou dbm (un processeur de base de donnees)
sur un certain nombre de chiers, par l'intermediaire de Make les fournis avec les
sources.
Le chier sendmail.cf ne de nit que le comportement par defaut du systeme. Pra-
tiquement, toutes les adaptations speci ques sont faites par un certain nombre de
tables optionnelles plut^ot qu'en modi ant directement sendmail.cf. Voici la liste de
ces tables :
mailertable De nit le comportement pour les domaines ou les h^otes distants.
uucpxtable Force le transfert du courrier par UUCP pour les h^otes qui sont au
format DNS.
pathtable De nit les chemins UUCP vers les domaines ou h^otes distants.
uucprelays Court-circuite le chemin pathalias pour les h^otes distants bien connus.
genericfrom Convertit les adresses internes en adresses generiques visibles du reste
du monde.
xaliases Convertit les adresses generiques en adresses internes valides.
decnetxtable Convertit les adresses RFC-822 en adresse DECnet.

15.3 Le chier sendmail.cf


Le chier sendmail.cf de Sendmail+IDA n'est pas edite a la main, mais est genere
a partir d'un chier de con guration m4 fourni par l'administrateur systeme local.
Nous appellerons ce chier sendmail.m4.
15.3. Le chier sendmail.cf 239

Il contient quelques de nitions, et ne fait essentiellement que pointer vers les tables,
ou le vrai travail se fait. En general, il sut de speci er les informations suivantes :

{ Les noms de chiers et chemins d'acces utilises sur le systeme local.


{ Le nom (ou les noms) par lequel le site est connu pour le courrier electronique.
{ Quel programme doit delivrer le courrier par defaut (et peut-^etre quel est le
smart-host).

Toute une variete de parametres peuvent ^etre de nis pour etablir le comportement
du site local ou pour forcer la con guration compilee par defaut. Ces options sont
identi ees dans le chier ida/cf/OPTIONS, dans le repertoire source.
Un chier sendmail.m4 destine a une con guration minimale (UUCP ou SMTP avec
tout le courrier non local envoye a un smart-host directement connecte) peut ne pas
depasser 10 a 15 lignes, commentaires exclus.

15.3.1 Exemple de chier sendmail.m4


Un chier sendmail.m4 pour la machine gueuze de l'entreprise (( La biere virtuelle ))
est represente dans la gure 15.1. Pour le courrier avec tous les h^otes du reseau des
brasseurs, gueuze utilise SMTP ; et elle envoie tous les messages pour les autres
destinations par UUCP a moria, qui est la passerelle vers l'Internet.
En fait, la plupart des gens n'appellent pas leur chier de con guration sendmail.m4.
Ils lui donnent un nom en relation avec celui de la machine ; gueuze.m4 dans notre
cas. Ce nom n'a aucune importance, tant que la sortie s'appelle bien sendmail.cf.

15.3.2 Parametres couramment utilises dans sendmail.m4


Un petit nombre d'items du chier sendmail.m4 sont systematiquement necessaires,
les autres peuvent ^etre ignores si les valeurs par defaut vous conviennent. Les sections
qui vont suivre decrivent chaque parametre de l'exemple de la gure 15.1 avec plus
de details.

Parametres de nissant les chemins d'acces


dnl #define(LIBDIR,/usr/local/lib/mail)dnl # o
u vont les fichiers support

LIBDIR de nit le repertoire dans lequel Sendmail+IDA ira chercher les chiers de
con guration, les di erentes tables dbm, et les de nitions locales speciales. Dans une
distribution binaire typique, ce parametre est compile dans le programme et n'a pas
besoin d'^etre explicitement indique dans le chier sendmail.m4.
240 Chapitre 15. Sendmail+IDA

dnl #---------------- EXEMPLE DE FICHIER SENDMAIL.M4 -------------------


dnl # (La cha^
ne 'dnl' est l'equivalent m4 d'un commentaire de ligne)
dnl # Il est pref
erable de ne pas changer le LIBDIR compile dans le programme
dnl #define(LIBDIR,/usr/local/lib/mail)dnl # o
u vont les fichiers support
define(LOCAL_MAILER_DEF, mailers.linux)dnl # prog. delivrant le courrier local
define(POSTMASTERBOUNCE)dnl # postmaster re coit les rejets
define(PSEUDODOMAINS, BITNET UUCP)dnl # ne pas essayer DNS sur ceux-l a
dnl #-------------------------------------------------------------------
dnl #
define(PSEUDONYMS, gueuze.bibine.com gueuze.UUCP bibine.com)
dnl # noms par lesquels nous sommes
dnl # connus
define(DEFAULT_HOST, gueuze.bibine.com)dnl # notre 'nom' primaire pour
dnl # le courrier
define(UUCPNAME, gueuze)dnl # notre nom uucp
dnl #
dnl #------------------------------------------------------------------
dnl #
define(UUCPNODES, |uuname|sort|uniq)dnl # nos voisins uucp
define(BANGIMPLIESUUCP)dnl # assurons-nous que le courrier
define(BANGONLYUUCP)dnl # uucp sera trait e correctement
define(RELAY_HOST, moria)dnl # notre smart-host
define(RELAY_MAILER, UUCP-A)dnl # nous joignons moria par uucp
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # les differentes tables dbm de recherche
dnl #
define(ALIASES, LIBDIR/aliases)dnl # alias systeme
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainisation des noms
define(PATHTABLE, LIBDIR/pathtable)dnl # base de donnees chemins uucp
define(GENERICFROM, LIBDIR/generics)dnl # adresses 'from' g en
eriques
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers par h^ ote ou par domaine
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # chemins vers les h^ otes uucp
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # court-circuite pathalias
dnl #
dnl #-----------------------------------------------------------------------
dnl #
dnl # inclusion du 'vrai' code qui fait fonctionner le tout
dnl # (fourni avec le code source)
dnl #
include(Sendmail.mc)dnl # ENTREE INDISPENSABLE !!!
dnl #
dnl #---------------- FIN DE L'EXEMPLE DE FICHIER SENDMAIL.M4 ---------------

Fig. 15.1 - Exemple du chier de con guration gueuze.m4.


15.3. Le chier sendmail.cf 241

La ligne de l'exemple commence par les trois lettres dnl, ce qui signi e qu'il s'agit
d'un commentaire.
Pour modi er l'endroit ou vous desirez placer les chiers de con guration, supprimez
la cha^ne dnl, indiquez le chemin d'acces voulu, puis reconstruisez et reinstallez le
chier sendmail.cf.

De nition du programme delivrant le courrier local


define(LOCAL_MAILER_DEF, mailers.linux)dnl # prog. pour courrier local

La plupart des systemes d'exploitation proposent un programme pour delivrer le


courrier local. Sur beaucoup de versions d'UNIX, les noms de ces programmes sont
deja inclus dans le binaire de sendmail.
Sous Linux, il est necessaire d'indiquer quel sera le programme approprie car il n'est
pas forcement present dans la distribution que vous avez installee. Il sut de speci er
la valeur de LOCAL MAILER DEF dans le chier sendmail.m4.
Par exemple, pour que ce soit le programme deliver, tres souvent utilise dans ce but 2 ,
vous positionnerez LOCAL MAILER DEF a mailers.linux.
Le chier suivant devra alors ^etre installe sous le nom de mailers.linux dans le re-
pertoire pointe par LIBDIR. Il de nit le programme deliver comme le mailer interne
Mlocal avec les parametres corrects, a n que sendmail puisse correctement delivrer
le courrier destine au systeme local. A moins que vous ne soyez un expert sendmail,
vous n'aurez pas inter^et a modi er cet exemple.
# -- /usr/local/lib/mail/mailers.linux --
# (local mailers for use on Linux )
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=10, A=sh -c $u

Il existe aussi une valeur par defaut pour deliver dans le chier Sendmail.mc qui
est inclus dans sendmail.cf. Pour le speci er, vous ne devez pas utiliser le chier
mailers.linux mais de nir a la place, dans votre chier sendmail.m4, ce qui suit :
dnl --- (in sendmail.m4) ---
define(LOCAL_MAILER_DEF, DELIVER)dnl # prog. pour courrier local

Malheureusement, Sendmail.mc considere que deliver est installe dans le repertoire


/bin, ce qui n'est pas le cas dans les distributions de Linux comme Slackware, qui le
placent dans /usr/bin. Dans ce cas, vous devrez soit le tromper avec un lien symbo-
lique, soit recompiler a partir des sources pour qu'il fonctionne depuis /bin.
2 Le programme deliver est l'uvre de Chip Salzenberg (chip%tct@ateng.com). Il fait partie
:
de plusieurs distributions de Linux et peut ^etre trouve sur les archives FTP anonymes courantes.
242 Chapitre 15. Sendmail+IDA
Gerer les courriers rejetes
define(POSTMASTERBOUNCE)dnl # postmaster re
coit les rejets

Beaucoup de sites considerent qu'il est tres important d'assurer les envois et receptions
de courrier avec un taux de reussite proche de 100 %. Bien que l'examen des traces
de syslogd(8) soit utile, l'administrateur a generalement besoin de voir les en-t^etes
des messages rejetes a n de pouvoir determiner s'ils n'ont pu ^etre delivres en raison
d'une erreur de l'utilisateur ou d'un probleme de con guration sur l'un des systemes
mis en jeu.
De nir POSTMASTERBOUNCE permettra d'envoyer une copie de chaque message
rejete a l'utilisateur de ni comme Postmaster du systeme.
Helas ! positionner ce parametre a pour consequence d'envoyer egalement le texte du
message non delivre au postmaster, ce qui est une atteinte a la vie privee des personnes
utilisant le courrier sur son systeme.
Les administrateurs de site doivent par principe tenter de se retenir de lire des mes-
sages prives qui ne leur sont pas adresses (ou le faire par des moyens techniques, par
exemple a l'aide de shell-scripts qui suppriment le contenu des courriers rejetes dont
ils recoivent une copie).

Parametres relatifs au DNS


define(PSEUDODOMAINS, BITNET UUCP)dnl # ne pas essayer DNS sur ceux-l
a

Il existe plusieurs reseaux bien connus qui sont souvent references dans des adresses de
courrier pour des raisons historiques, mais qui ne sont pas valides lors d'une recherche
par le DNS. De nir PSEUDODOMAINS evite d'inutiles requ^etes aux serveurs de
noms, qui echoueront toujours.

De nition des noms du systeme local


define(PSEUDONYMS, gueuze.bibine.com gueuze.UUCP bibine.com)
dnl # noms par lesquels nous sommes
dnl # connus
define(DEFAULT_HOST, gueuze.bibine.com)dnl # notre 'nom' primaire pour
dnl # le courrier

Souvent, les systemes doivent cacher leur vraie identite, servir de passerelle de courrier,
ou recevoir et traiter des messages adresses a d'anciens noms, sous lesquels ils etaient
connus auparavant.
PSEUDONYMS speci e la liste de tous les noms pour lesquels le systeme local ac-
ceptera du courrier.
15.3. Le chier sendmail.cf 243

DEFAULT HOST speci e le nom qui appara^tra dans les messages emis depuis le
systeme local. Il faut absolument que ce parametre soit positionne a une valeur valide,
sinon toutes les reponses aux courriers ne pourront ^etre delivrees.

Parametres relatifs a UUCP


define(UUCPNAME, gueuze)dnl # notre nom uucp
define(UUCPNODES, |uuname|sort|uniq)dnl # nos voisins uucp
define(BANGIMPLIESUUCP)dnl # assurons-nous que le courrier
define(BANGONLYUUCP)dnl # uucp sera trait
e correctement

Tres souvent, les systemes sont connus sous un nom pour le DNS et sous un autre pour
UUCP. UUCPNAME vous permet de de nir un nom d'h^ote di erent, qui appara^tra
dans les en-t^etes du courrier emis par UUCP.
UUCPNODES de nit les commandes qui retournent une liste de machines avec les-
quelles vous ^etes directement en liaison UUCP.
BANGIMPLIESUUCP et BANGONLYUUCP assurent que le courrier adresse avec
la notation par bangs UUCP sera traite selon la methode UUCP plut^ot que par celle
du DNS utilisee de nos jours sur l'Internet.

Machines relais (smart-host)


define(RELAY_HOST, moria)dnl # notre smart-host
define(RELAY_MAILER, UUCP-A)dnl # nous joignons moria par uucp

Beaucoup d'administrateurs systeme ne veulent pas passer tout leur temps a con -
gurer leur machine pour s'assurer qu'elle peut vraiment atteindre tous les h^otes de la
planete. Ils preferent envoyer tout le courrier dont la destination est inconnue vers une
machine relais, qui saura prendre ce routage en charge, que l'on appelle le smart-host.
RELAY HOST de nit le nom UUCP d'une telle machine.
RELAY MAILER de nit l'agent de transport utilise pour relayer les messages.
Il est important de noter que positionner ces parametres aura pour consequence d'en-
voyer tout votre courrier sortant vers ce systeme distant, ce qui a ectera la charge de
cette machine. Assurez-vous auparavant d'avoir obtenu l'accord de son administrateur
avant de lui envoyer tout ce travail.

Tables de con guration


define(ALIASES, LIBDIR/aliases)dnl # alias syst
eme
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainisation des noms
define(PATHTABLE, LIBDIR/pathtable)dnl # base de donn
ees chemins uucp
define(GENERICFROM, LIBDIR/generics)dnl # adresses 'from' gen
eriques
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers par h^ote ou par domaine
244 Chapitre 15. Sendmail+IDA
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # chemins vers les h^
otes uucp
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # court-cirtuite pathalias

Avec ces macros, vous pouvez changer l'endroit ou Sendmail+IDA recherche les di-
verses tables dbm qui de nissent le comportement (( reel )) du systeme. Il est raisonnable
de les laisser dans LIBDIR.

Le chier de base Sendmail.mc


include(Sendmail.mc)dnl # ENTR
EE INDISPENSABLE !!!

Les auteurs de Sendmail+IDA fournissent le chier Sendmail.mc, qui est le cur de


ce qui deviendra le chier sendmail.cf. De nouvelles versions sont di usees periodi-
quement, pour corriger des bogues ou rajouter des fonctionnalites sans avoir besoin
d'une distribution complete ou de recompiler sendmail. Par consequent, il est tres
important de ne jamais editer ce chier.

Mais quelles sont donc les entrees vraiment necessaires ?


Lorsque vous n'utilisez aucune des tables dbm optionnelles, Sendmail+IDA delivre
le courrier par le DEFAULT MAILER (et eventuellement par RELAY HOST et RE-
LAY MAILER) de ni dans le chier sendmail.m4 servant a generer sendmail.cf. Il
est facile de modi er ce comportement par les entrees des chiers domaintable et
uucpxtable.
Un site ordinaire sur l'Internet, interrogeant le DNS, ou qui est uniquement UUCP
et envoie tout son courrier vers son smart-host, n'a probablement besoin d'aucune
entree speci que dans les tables.
Pratiquement, tous les systemes doivent positionner les macros DEFAULT HOST et
PSEUDONYMS, qui de nissent le nom canonique du site et les alias sous lesquels il
est connu, et DEFAULT MAILER. Si tout ce que vous faites est de passer le travail
a une machine relais, vous n'aurez pas besoin de positionner ces valeurs par defaut
car cela fonctionne automatiquement.
Les machines UUCP necessiteront sans doute d'assigner UUCPNAME a leur nom
ociel UUCP, ainsi que de positionner RELAY MAILER et RELAY HOST, qui valide
l'utilisation d'un smart-host, le transport utilise pour le courrier sera de ni dans
RELAY MAILER et devra normalement ^etre UUCP-A pour les sites UUCP.
Si votre site est uniquement SMTP et utilise le DNS, vous devrez changer la valeur
assignee a DEFAULT MAILER pour y mettre TCP-A et probablement supprimer les
deux lignes RELAY MAILER et RELAY HOST.
15.4. Presentation des tables de Sendmail+IDA 245

15.4 Presentation des tables de Sendmail+IDA


Sendmail+IDA propose un certain nombre de tables qui vous permettent de modi er
le comportement par defaut de sendmail (speci e dans le chier sendmail.m4) et de
de nir des modes de fonctionnements particuliers pour certaines situations, certains
sytemes distants, ou certains reseaux. Ces tables sont traitees par dbm via le Make le
fourni dans la distribution.
La plupart des sites n'auront besoin que de tres peu de tables, voire pas du tout.
Si le v^otre n'en necessite aucune, le mieux est alors de leur donner une taille de 0
octet (avec la commande touch) et d'utiliser le Make le par defaut se trouvant dans
LIBDIR, plut^ot que de modi er ce Make le lui-m^eme.

15.4.1 La table mailertable


Le chier mailertable de nit des traitements speciaux pour des h^otes ou reseaux spe-
ci ques. Il est souvent employe sur les sites Internet pour selectionner un relais de
courrier ou passerelle intermediaire pour atteindre un reseau donne, et pour indiquer
un protocole particulier (UUCP ou SMTP) a utiliser. Les sites UUCP n'ont genera-
lement pas besoin de ce chier.
L'ordre est important, car sendmail lit le chier de haut en bas et traite les messages
en fonction de la premiere regle correspondante qu'il rencontre. Par consequent, il
faut placer les regles les plus speci ques au debut, et les plus generales a la n.
Supposons que vous voulez envoyer tout le courrier destine au departement informa-
tique de l'universite Groucho Marx (cs.groucho.edu) par UUCP vers un relais nomme
ada. Pour cela, il vous faudra une entree dans mailertable comme celle-ci :
# (extrait de mailertable)
#
# renvoie tout le courrier pour le domaine .cs.groucho.edu
# par UUCP sur la machine ada.
UUCP-A,ada .cs.groucho.edu

Supposons maintenant que vous desirez que tout le courrier pour le gros domaine
groucho.edu aille vers un h^ote relais di erent (grostas) pour la resolution des
adresses et la distribution. La table mailertable deviendra alors comme ceci :
# (extrait de mailertable)
#
# renvoie tout le courrier pour le domaine .cs.groucho.edu
# par UUCP sur la machine ada.
UUCP-A,ada .cs.groucho.edu
#
# renvoie tout le courrier pour le domaine groucho.edu par UUCP
# vers la machine grostas.
UUCP-A,grostas .groucho.edu
246 Chapitre 15. Sendmail+IDA
Comme nous l'avons dit plus haut, l'ordre des entrees est important. Si les deux regles
ci-dessus apparaissaient dans le sens inverse, tout le courrier vers .cs.groucho.edu
serait dirige par la regle generale vers grostas au lieu d'^etre traite par la regle plus
speci que devant l'envoyer vers ada.
Dans l'exemple de mailertable ci-dessus, UUCP-A indique a sendmail de delivrer le
courrier par UUCP avec des en-t^etes domainises.
La virgule entre la methode et le nom du systeme lui indique d'envoyer le message a
ada pour la resolution d'adresses et l'expedition (ce n'est pas qu'un caractere sepa-
rateur, il peut avoir plusieurs valeurs, nous allons voir ca).
Les entrees mailertable ont le format suivant :

m
ethode d
elimiteur h^
ote-relais ote ou domaine
h^

Il y a plusieurs methodes possibles. Les di erences se trouvent generalement dans la


maniere dont les adresses sont traitees. Les valeurs typiques sont TCP-A (TCP/IP
avec des adresses de type Internet), TCP-U (TCP/IP avec des adresses de type
UUCP), et UUCP-A (UUCP avec des adresses de type Internet).
Le caractere qui separe la methode de la partie h^ote sur la gauche d'une ligne mai-
lertable de nit comment l'adresse sera modi ee.
! Un point d'exclamation supprime le nom d'h^ote destinataire avant
l'envoi. Vous l'utiliserez essentiellement lorsque vous voulez forcer le
courrier vers un site distant mal con gure.
, Une virgule ne modi e jamais l'adresse. Le message est envoye par
la methode indiquee vers la machine relais speci ee.
: Le caractere (( deux-points )) supprime le nom d'h^ote destinataire
seulement s'il existe des machines intermediaires entre vous et la
destination. Donc, dans toto!titi!marcel, toto sera supprime, alors
que xyzzy!alfred restera inchange.
Ce qui est important, c'est que mailertable ne reecrit que l'enveloppe (pour que le sys-
teme distant accepte le message). Reecrire autre chose que l'enveloppe est en general
tres mal vu (et peut completement deregler la con guration du courrier).

15.4.2 La table uucpxtable


Generalement, le courrier vers des machines avec un nom pleinement quali e est deli-
vre par SMTP, en interrogeant le DNS ou bien via le smart-host. La table uucpxtable
force l'utilisation du routage UUCP en convertissant le nom domainise en style UUCP,
sans domaine.
15.4. Presentation des tables de Sendmail+IDA 247

Cette methode est utilisee lorsque vous ^etes une passerelle courrier pour un site,
ou lorsque vous voulez envoyer directement des messages vers une liaison UUCP
directe plut^ot que de passer par la liaison par defaut et plusieurs autres systemes
intermediaires.
Les sites UUCP qui sont connectes a vos voisins UUCP utilisant des en-t^etes do-
mainises utiliseront ce chier pour forcer l'envoi du courrier par la liaison UUCP
directe entre les deux systemes, plut^ot que d'utiliser la route moins directe par RE-
LAY MAILER et RELAY HOST ou via DEFAULT MAILER.
Les sites Internet qui n'utilisent pas UUCP n'auront pas besoin de uucpxtable.
Supposons que vous o rez le renvoi du courrier a un systeme appele sesame.com dans
le DNS et sesame dans les cartes UUCP. Vous aurez besoin de l'entree suivante dans
uucpxtable pour forcer le courrier pour cette machine a passer par votre connexion
UUCP directe :
#============== /usr/local/lib/mail/uucpxtable ============
# Le courrier pour utilisateur@sesame.com est r
e
ecrit sous
# la forme sesame!utilisateur et par cons
equent sera d
elivre
# par UUCP
#
sesame sesame.com
#
#----------------------------------------------------------

15.4.3 La table pathtable


Le chier pathtable sert a de nir explicitement le routage vers des machines ou des
reseaux distants. Son format est celui de la base de donnees pathalias, trie par ordre
alphabetique. Les deux champs de chaque ligne doivent ^etre separes par un caractere
de tabulation.
La plupart des systemes n'ont besoin d'aucune entree dans pathtable.
#=============== /usr/local/lib/mail/pathtable ================
#
# Il s'agit d'un fichier au format pathalias permettant de
# forcer le passage du courrier pour vos voisins UUCP par
# le lien direct UUCP, au lieu de lui laisser prendre le long
# chemin normal, par le smart-host.
#
# Le s
eparateur doit absolument ^etre un vrai caract
ere de tabulation.
#
# Route le courrier 
a travers un ou plusieurs sites intermediaires
# vers un syst
eme distant utilisant des adresses de style UUCP.
#
sesame!ernie!%s ernie
#
# Renvoi vers un syst
eme qui est un voisin UUCP d'un site internet
# accessible.
248 Chapitre 15. Sendmail+IDA
#
swim!%s@gcc.groucho.edu swim
#
# Les entr
ees suivantes envoient tout le courrier a destination
# de deux reseaux par des passerelles diff
erentes. Notez le << . >>
# Dans cet exemple, << uugate >> et << byte >> sont des systemes sp
ecifiques
# servant de passerelle de courrier pour les pseudo-domaines
# .UUCP et .BITNET.
#
%s@uugate.groucho.edu .UUCP
byte!%s@mail.shift.com .BITNET
#
#=================== end of pathtable =======================

15.4.4 La table domaintable


Elle est utilisee pour forcer le comportement a adopter apres qu'une requ^ete DNS a
eu lieu. Elle permet a l'administrateur de donner des surnoms a certains systemes
ou domaines souvent references, en remplacant automatiquement le surnom par le
nom reel. Elle peut aussi servir a remplacer des noms de machines ou de domaines
incorrects par une information (( correcte )).
La plupart des sites n'ont pas besoin d'entree dans domaintable.
L'exemple qui suit montre comment remplacer une adresse incorrecte | a laquelle
des utilisateurs essaient d'envoyer du courrier | par la bonne :
#============= /usr/local/lib/mail/domaintable =================
#
#
lamachine.correct.domaine lamachine.pasbon.domaine
#
#
#=================== end of domaintable ========================

15.4.5 Le chier aliases


Les alias permettent un certain nombre de choses :

{ O rir des raccourcis ou des noms plus connus pour ecrire a une ou plusieurs
personnes.
{ Appeler un programme en lui passant le message sur l'entree standard.
{ Envoyer un courrier dans un chier.

Pour ^etre conforme aux RFC, tous les systemes necessitent au moins deux alias :
Postmaster et MAILER-DAEMON.
15.4. Presentation des tables de Sendmail+IDA 249

#--------------------- /usr/local/lib/mail/aliases ------------------


#
# demonstrate commonly seen types of aliases
#
usenet: alfred # alias pour une personne.
admin: alfred,marcel # alias pour plusieurs personnes.
linux-users: :include:/usr/lib/lists/linux
# lecture des destinataires depuis
# un fichier.
changefeed: | /usr/local/lib/gup # alias qui appelle un programme
plaintes: /var/log/plaintes # alias qui 
ecrit dans un fichier
#
# Les deux alias qui suivent doivent exister pour ^
etre conforme aux RFC.
# Il doivent pointer vers un utilisateur qui lit son courrier r
egulierement.
#
postmaster: root # Entr
ee obligatoire
MAILER-DAEMON: postmaster # Entr
ee obligatoire
#
#-------------------------------------------------------------------

Fig. 15.2 - Exemple de chier aliases.

Soyez toujours vigilant sur la securite lorsque vous de nissez des alias qui appelleront
des programmes ou ecriront dans des chiers car sendmail fonctionne avec un setuid
a root.
Les modi cations e ectuees dans le chier aliases ne prennent e et qu'apres avoir
execute la commande :

# /usr/lib/sendmail -bi

Cette commande reconstruit la table dbm necessaire. Vous pouvez egalement employer
la commande newaliases, que l'on fait souvent executer a intervalles reguliers par cron.
Tous les details concernant les alias peuvent se trouver dans la page de manuel
aliases(5). Ci-dessus, gure 15.2, un exemple de chier aliases.

15.4.6 Tables rarement utilisees


Les tables suivantes sont disponibles mais tres rarement utilisees. Consultez la docu-
mentation fournie avec les sources de Sendmail+IDA si vous desirez plus de details.
uucprelays Le chier uucprelays est utilise pour (( court-circuiter )) le chemin
UUCP vers des sites particulierement connus, plut^ot que de laisser
le message partir par une route incertaine generee par le traitement
des cartes UUCP avec pathalias.
250 Chapitre 15. Sendmail+IDA
genericfrom et xaliases Le chier genericfrom cache les noms d'utilisateurs locaux,
ainsi que leurs adresses, en les convertissant en adresses generiques
qui ne correspondent pas aux valeurs internes.
L'utilitaire associe xalparse automatise la generation des chiers ge-
nericfrom et aliases de sorte que les traductions entrantes et sortantes
soient faites a partir d'un chier de reference, xaliases.
decnetxtable Le chier decnetxtable reecrit les adresses domainisees en adresses de
style DECnet.

15.5 Installation de sendmail


Nous allons voir dans cette section, comment installer une distribution binaire typique
de Sendmail+IDA, et ce qu'il est necessaire de con gurer pour qu'elle soit parfaite-
ment fonctionnelle et adaptee au site.
La distribution binaire courante de Sendmail+IDA pour Linux peut ^etre obtenue
sur sunsite.unc.edu dans le repertoire /pub/Linux/system/Mail. Si vous posse-
dez une version anterieure de sendmail, il est conseille de passer a la version send-
mail5.67b+IDA1.5 car Linux est maintenant supporte en standard dans le code source,
et de plus, plusieurs trous de securite assez importants ont ete elimines, qui se trou-
vaient dans les versions anterieures au 1er decembre 1993.
Si vous compilez sendmail a partir des sources, vous devez suivre les instructions
contenues dans les chiers README de la distribution. Ces sources sont disponibles
sur le site vixen.cso.uiuc.edu. Il vous faudra egalement les chiers de con guration
spe ciques a Linux contenus dans l'archive newspak-2.2.tar.gz, disponible par FTP
anonyme sur sunsite.unc.edu dans le repertoire /pub/Linux/system/Mail.
Si vous avez installe smail ou un autre programme similaire auparavant, il vous faudra
supprimer (ou renommer) au prealable tous les chiers s'y rapportant pour eviter
d'eventuels con its.

15.5.1 Extraction de la distribution binaire


Tout d'abord, il faut extraire les chiers de l'archive dans un repertoire de travail :
$ gunzip -c sendmail5.65b+IDA1.5+mailx5.3b.tgz | tar xvf -

Si vous avez une commande tar (( moderne )), vous pourrez probablement obtenir le
m^eme resultat par la simple commande tar -zxvf fichier.tgz.
Une fois ce traitement termine, vous aurez obtenu un repertoire portant le nom
de sendmail5.65b+IDA1.5+mailx5.3b. Vous y trouverez une installation complete de
Sendmail+IDA plus un binaire du programme utilisateur mailx. Toute l'arborescence
15.5. Installation de sendmail 251

en dessous de ce repertoire re ete l'emplacement exact ou les chiers doivent ^etre
installes. Vous pouvez donc en toute securite les mettre en place ainsi :
# cd sendmail5.65b+IDA1.5+mailx5.3b
# tar cf - . | (cd /; tar xvvpoof -)

15.5.2 Generation du chier sendmail.cf


Pour construire un chier sendmail.cf adapte a votre site, il vous faut rediger un chier
sendmail.m4, puis le traiter par m4. Dans /usr/local/lib/mail/CF, vous trouverez un
exemple appele sample.m4. Copiez-le sous un autre nom (par convention on le nomme
du nom de la machine, votre-h^ote.m4) et editez-le pour qu'il re ete la situation
desiree.
Cet exemple est con gure pour un site uniquement UUCP qui utilise des en-t^etes
domainises et envoie le courrier a un smart-host. De tels sites n'auront donc que tres
peu de choses a modi er.
Ici, nous ne vous donnerons qu'un bref apercu des macros que vous allez devoir chan-
ger. Pour une description plus complete, reportez-vous un peu plus haut dans ce
chapitre, ou sendmail.m4 est decrit avec plus de details.
LOCAL MAILER DEF
De nit le chier qui indique les programmes destines a delivrer le
courrier local. Consultez la section (( De nition du programme deli-
vrant le courrier local )) plus haut pour savoir de quoi il retourne.
PSEUDONYMS
De nit tous les noms sous lesquels votre h^ote local peut ^etre connu.
DEFAULT HOST
Mettez votre nom pleinement quali e ici. Ce nom appara^tra comme
votre nom d'h^ote dans tout le courrier emis.
UUCPNAME Mettez votre nom d'h^ote non quali e ici.
RELAY HOST et RELAY MAILER
Si vous vous connectez par UUCP a un smart-host, assignez le nom
de cette machine a RELAY HOST. Si vous desirez des en-t^etes do-
mainises, utilisez la methode UUCP-A.
DEFAULT MAILER
Si vous ^etes sur l'Internet et utilisez le DNS, vous devez mettre TCP-
A. Cela indiquera a sendmail d'utiliser la methode TCP-A, qui delivre
le courrier par SMTP avec un style RFC normal pour l'adresse d'en-
veloppe. Les sites Internet n'ont pas besoin de de nir RELAY HOST
ou RELAY MAILER.
252 Chapitre 15. Sendmail+IDA
Pour creer automatiquement le chier sendmail.cf, executez la commande :
# make votre-h^
ote.cf

Le chier votre-h^ote.m4 sera traite par m4 et un chier votre-h^ote.cf sera realise.


Ensuite, vous devez tester si le chier de con guration que vous venez de creer fait
bien ce que vous attendez de lui : ce sera l'objet des deux sections suivantes. Lorsque
vous en serez satisfait, mettez-le en place par la commande :
# cp votre-h^
ote .cf /etc/sendmail.cf

A ce stade, votre systeme sendmail est pr^et a fonctionner. Mettez la ligne suivante
dans le script qui lance les demons sur votre machine (generalement /etc/rc.inet2) ;
vous pouvez aussi l'executer a la main pour ne pas avoir a relancer Linux :
# /usr/lib/sendmail -bd -q1h

15.5.3 Tests du chier sendmail.cf


Pour passer sendmail en mode test, vous devez l'appeler avec l'option -bt. Le chier
de con guration par defaut est le sendmail.cf qui est installe sur la machine, mais
vous pouvez essayer tout autre chier gr^ace a l'option -Cnom-de-fichier.
Dans les exemples suivants, nous testons gueuze.cf, le chier de con guration genere
par l'exemple donne dans la gure 15.1, page 240.
# /usr/lib/sendmail -bt -Cgueuze.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>

Les tests qui suivent veri ent que sendmail est capable de delivrer tout le courrier a
vos utilisateurs. Dans tous les cas, le resultat du test doit ^etre le m^eme et pointer vers
le systeme local, avec le transport LOCAL.
Tout d'abord, regardons comment un courrier pour un utilisateur local sera delivre :

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 moi
rewrite: ruleset 3 input: moi
rewrite: ruleset 7 input: moi
rewrite: ruleset 9 input: moi
15.5. Installation de sendmail 253

rewrite: ruleset 9 returns: < moi >


rewrite: ruleset 7 returns: < > , moi
rewrite: ruleset 3 returns: < > , moi
rewrite: ruleset 0 input: < > , moi
rewrite: ruleset 8 input: < > , moi
rewrite: ruleset 20 input: < > , moi
rewrite: ruleset 20 returns: < > , @ gueuze . bibine . com , moi
rewrite: ruleset 8 returns: < > , @ gueuze . bibine . com , moi
rewrite: ruleset 26 input: < > , @ gueuze . bibine . com , moi
rewrite: ruleset 26 returns: $# LOCAL $@ gueuze . bibine . com $: moi
rewrite: ruleset 0 returns: $# LOCAL $@ gueuze . bibine . com $: moi

La sortie montre comment sendmail traite une adresse de maniere interne. Elle est
passee a di erentes regles qui l'analysent, et en appellent d'autres tour a tour, et
toutes ses composantes sont isolees.
Dans notre exemple, nous avons donne l'adresse moi aux regles 3 et 0 (d'ou le nombre
3,0 entr e avant l'adresse). La derniere ligne montre l'adresse analysee telle que re-
tournee par la regle 0, contenant la methode par laquelle le message serait delivre
ainsi que l'h^ote et l'utilisateur qui lui seront passes.
Ensuite, veri ons ce que donne un message a un utilisateur du systeme, avec une
syntaxe UUCP.

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 gueuze!moi
rewrite: ruleset 3 input: gueuze ! moi
[...]
rewrite: ruleset 0 returns: $# LOCAL $@ gueuze . bibine . com $: moi
>

Maintenant, un courrier pour un utilisateur du systeme, mais avec la syntaxe Internet


et le nom pleinement quali e de la machine :

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 moi@gueuze.bibine.com
rewrite: ruleset 3 input: moi @ gueuze . bibine . com
[...]
rewrite: ruleset 0 returns: $# LOCAL $@ gueuze . bibine . com $: moi
>

Vous devez recommencer les tests ci-dessus avec chacun des noms que vous avez
254 Chapitre 15. Sendmail+IDA
indique dans les parametres PSEUDONYMS et DEFAULT NAME de votre chier
sendmail.m4.
En n, veri ons que vous pouvez envoyer du courrier vers votre relais :

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 fred@moria.com
rewrite: ruleset 3 input: fred @ moria . com
rewrite: ruleset 7 input: fred @ moria . com
rewrite: ruleset 9 input: fred @ moria . com
rewrite: ruleset 9 returns: < fred > @ moria . com
rewrite: ruleset 7 returns: < @ moria . com > , fred
rewrite: ruleset 3 returns: < @ moria . com > , fred
rewrite: ruleset 0 input: < @ moria . com > , fred
rewrite: ruleset 8 input: < @ moria . com > , fred
rewrite: ruleset 8 returns: < @ moria . com > , fred
rewrite: ruleset 29 input: < @ moria . com > , fred
rewrite: ruleset 29 returns: < @ moria . com > , fred
rewrite: ruleset 26 input: < @ moria . com > , fred
rewrite: ruleset 25 input: < @ moria . com > , fred
rewrite: ruleset 25 returns: < @ moria . com > , fred
rewrite: ruleset 4 input: < @ moria . com > , fred
rewrite: ruleset 4 returns: fred @ moria . com
rewrite: ruleset 26 returns: < @ moria . com > , fred
rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ moria . com > , fred
>

15.5.4 Tests d'integration de sendmail.cf et des tables


A ce stade, vous avez veri e que le systeme de courrier a bien le comportement par
defaut desire, et que vous pouvez recevoir et expedier des messages valides. Pour
terminer l'installation, il peut ^etre necessaire de creer les tables dbm appropriees pour
obtenir les e ets desires.
Apres avoir cree celles qui sont necessaires a votre site, il vous faut les traiter par dbm
en tapant make dans le repertoire contenant ces tables.
Si vous ^etes un site uniquement UUCP, vous n'avez pas besoin de creer les tables
mentionnees dans le chier README.linux. Il vous sura de creer des chiers du
m^eme nom, mais vides, pour que le Make le puisse fonctionner.
En tant que site UUCP, si vous ^etes connectes a d'autres machines que votre smart-
host, vous devrez sans doute ajouter des entrees dans uucpxtable pour chaque machine,
(sinon le courrier pour ces sites passera par ce smart-host au lieu d'^etre direct) et
executer dbm sur cette nouvelle table uucpxtable.
Tout d'abord, assurez-vous que le courrier via votre RELAY HOST est envoye par
15.5. Installation de sendmail 255

l'intermediaire de RELAY MAILER :

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 fred@sesame.com
rewrite: ruleset 3 input: fred @ sesame . com
rewrite: ruleset 7 input: fred @ sesame . com
rewrite: ruleset 9 input: fred @ sesame . com
rewrite: ruleset 9 returns: < fred > @ sesame . com
rewrite: ruleset 7 returns: < @ sesame . com > , fred
rewrite: ruleset 3 returns: < @ sesame . com > , fred
rewrite: ruleset 0 input: < @ sesame . com > , fred
rewrite: ruleset 8 input: < @ sesame . com > , fred
rewrite: ruleset 8 returns: < @ sesame . com > , fred
rewrite: ruleset 29 input: < @ sesame . com > , fred
rewrite: ruleset 29 returns: < @ sesame . com > , fred
rewrite: ruleset 26 input: < @ sesame . com > , fred
rewrite: ruleset 25 input: < @ sesame . com > , fred
rewrite: ruleset 25 returns: < @ sesame . com > , fred
rewrite: ruleset 4 input: < @ sesame . com > , fred
rewrite: ruleset 4 returns: fred @ sesame . com
rewrite: ruleset 26 returns: < @ sesame . com > , fred
rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ sesame . com > , fred
>

Si vous avez des voisins UUCP autres que votre RELAY HOST, vous devrez veri er
que le courrier qui leur est destine est bien route comme vous l'avez prevu. Les mes-
sages adresses avec la syntaxe UUCP vers un h^ote avec lequel vous ^etes directement
connecte par UUCP doivent lui ^etre envoyes directement (sauf si vous l'emp^echez
explicitement par une entree dans domaintable). Considerons que swim est un de vos
voisins UUCP directs. Passer a sendmail un message adresse a swim!fred devrait
produire le resultat suivant :

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 swim!fred
rewrite: ruleset 3 input: swim ! fred
[...lignes supprim
ees...]
rewrite: ruleset 0 returns: $# UUCP $@ swim $: < > , fred
>

Si vous avez des entrees uucpxtable destinees a forcer l'envoi UUCP vers certains
voisins qui postent leur courrier avec le style Internet et des en-t^etes domainises, il
faudra aussi veri er ceci :
256 Chapitre 15. Sendmail+IDA

# /usr/lib/sendmail -bt -Cgueuze.cf


ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 machin@truc.bidule.com
rewrite: ruleset 3 input: machin @ truc . bidule . com
[...lignes supprim
ees...]
rewrite: ruleset 0 returns: $# UUCP $@ truc . bidule $: < > , machin
>

15.6 Trucs et astuces du parfait petit administra-


teur
Maintenant que nous avons vu la theorie de la con guration, l'installation et les tests
d'un systeme Sendmail+IDA, prenons un peu de temps pour regarder ce qui se passe
reellement dans la vie quotidienne d'un administrateur.
Les systemes distants tombent parfois en panne. Les modems marchent mal ou le
telephone est coupe. Les de nitions DNS sont erronees car quelqu'un s'est trompe.
Les reseaux s'arr^etent sans prevenir. Dans de tels cas, les administrateurs du courrier
doivent savoir exactement comment reagir ecacement et au plus vite, a n d'assurer
une continuite du service jusqu'a ce que tout fonctionne a nouveau normalement.
Le reste de ce chapitre est destine a vous proposer des solutions aux ennuis les plus
courants rencontres dans le monde du courrier electronique.

15.6.1 Renvoyer le courrier a une machine relais


Pour renvoyer le courrier destine a un domaine ou a un h^ote particulier, vers un
relais donne qui pourra en assurer l'expedition, il faut generalement utiliser le chier
mailertable. Par exemple, pour renvoyer tout le courrier destine a chezeux.org vers
leur passerelle UUCP tortue, vous mettrez l'entree suivante dans mailertable :
UUCP-A,tortue chezeux.org

15.6.2 Forcer du courrier dans des sites mal con gures


Les h^otes Internet ont souvent des problemes pour envoyer du courrier aux sites
distants mal con gures. Il y a plusieurs variantes de la chose, mais le sympt^ome
general se traduit par des messages rejetes par le systeme distant ou du courrier
irremediablement perdu.
15.6. Trucs et astuces du parfait petit administrateur 257

Ces problemes font souvent du tort a l'administrateur local, car les utilisateurs se
moquent generalement que vous n'administriez pas personnellement tous les systemes
du monde (ou ne puissiez pas joindre leurs responsables pour qu'ils corrigent leurs
erreurs). Tout ce qu'ils voient, c'est que leurs messages n'aboutissent pas a leurs
destinataires et que vous ^etes la personne ideale sur laquelle passer leur colere.
La con guration d'un site distant n'est pas votre probleme. Dans tous les cas, ne
tentez pas de deregler votre systeme pour arriver a communiquer avec une machine
mal con guree. Si vous ne pouvez pas joindre son responsable a n qu'il corrige ce
qu'il faut en temps voulu, vous avez deux options :
{ Il est generalement possible de forcer le systeme distant a accepter du courrier,
mais puisqu'il n'est pas correctement con gure, les reponses ne reviendront sans
doute pas ; mais la, c'est le probleme de son administrateur.
Vous pouvez corriger les mauvais en-t^etes de l'enveloppe de vos messages sor-
tants, uniquement en utilisant une entree domaintable pour leur h^ote ou do-
maine, qui fera que les informations non valides seront corrigees pour tout le
courrier provenant de votre site :
malade.correct.domaine.com malade.incorrect.domaine.com

{ Souvent, les sites mal con gures rejettent le courrier en le renvoyant vers la
machine expeditrice en disant sans honte (( ce courrier ne nous est pas destine )),
simplement parce qu'ils n'ont pas leur PSEUDONYMNS ou equivalent con gure
proprement. Il est alors possible de supprimer tout nom d'h^ote et de domaine
de l'enveloppe des messages partant de votre site vers le leur.
Le point d'exclamation ! dans le chier mailertable ci-dessous delivre les mes-
sages a leur site en les faisant appara^tre a leur sendmail comme s'ils arrivaient de
leur systeme local. Notez que cela ne change que l'adresse d'enveloppe, l'adresse
de retour correcte sera toujours presente dans le message.
TCP!malade.correct.domaine.com malade.incorrect.domaine.com

Neanmoins, m^eme si vous arrivez a leur poster du courrier, il n'y a aucune garantie
qu'ils puissent vous repondre (ce sont des nuls, ne l'oubliez pas) ; mais au moins, leurs
utilisateurs casseront les pieds a leur administrateur, et vous serez tranquille de votre
c^ote.

15.6.3 Forcer le courrier a partir par UUCP


Dans un monde ideal (vu du c^ote Internet), tous les h^otes sont dans le DNS et postent
des messages sous des noms pleinement quali es.
Si vous communiquez par UUCP avec un tel site, vous pouvez forcer le courrier a
passer par la connexion UUCP plut^ot que par la methode par defaut en (( anti-
domainisant )) le nom du site distant par le chier uucpxtable.
258 Chapitre 15. Sendmail+IDA
Pour forcer le courrier par sesame.com, vous mettrez ce qui suit dans votre uucpx-
table :

# supprime le domaine de sesame.com pour forcer UUCP


sesame sesame.com

Le resultat sera que sendmail determinera (via UUCPNODES dans le chier send-
mail.m4) que vous ^etes directement connecte au systeme distant, et mettra le courrier
en attente dans la queue UUCP, pour qu'il soit delivre a la prochaine connexion de
ce type avec ce site.

15.6.4 Emp^echer le courrier de partir par UUCP


La situation inverse peut aussi se produire. Souvent, des systemes peuvent avoir un
certain nombre de connexions UUCP directes qui ne sont utilisees que de temps en
temps, ou ne sont pas aussi ables et disponibles que le routage par defaut ou le
smart-host.
Par exemple, il y a dans la region de Seattle 3 des sites qui s'echangent les di erentes
distributions de Linux par UUCP lorsqu'elles sont disponibles. Ces machines ne sont
connectees que lorsque c'est necessaire, il est donc generalement beaucoup plus ra-
pide de faire passer le courrier par de multiples sites, mais plus ables et toujours
disponibles.
Il est tres facile d'eviter de delivrer le courrier directement a un site avec lequel vous
avez une connexion UUCP directe. Si le systeme distant possede un nom pleinement
quali e, vous pouvez ajouter une entree comme celle-ci dans la table domaintable :

# 
evite le courrier direct pour un voisin UUCP
voisin.com voisin

Cela remplacera toute occurrence du nom UUCP par le nom pleinement quali e, et
par consequent evitera qu'il soit trouve par la ligne UUCPNODES du chier send-
mail.m4. Le resultat sera generalement que le courrier partira via le RELAY MAILER
et RELAY HOST (ou DEFAULT MAILER).

15.6.5 Vider sur demande la queue de Sendmail


Pour traiter immediatement les messages qui sont en attente dans la queue, il sut de
taper la commande /usr/lib/runq. Elle appelle sendmail avec les options adequates.
3 Ainsi que dans la region parisienne.
:
15.7. Coherence des distributions binaires 259

15.6.6 Obtenir des statistiques sur le courrier traite


Beaucoup d'administrateurs (et leurs employeurs) ont besoin de conna^tre le volume
du courrier traite par leur site. Il y a plusieurs methodes pour quanti er ce tra c :

{ sendmail est fourni avec un utilitaire appele mailstats qui lit un chier appele
/usr/local/lib/mail/sendmail.st et rapporte le nombre de messages et la taille
qui ont ete transferes par chaque methode declaree dans le chier sendmail.cf.
Ce chier de statistiques doit ^etre cree manuellement par l'administrateur pour
que sendmail commence a y enregistrer des traces. Les resultats sont remis a
zero en e acant puis recreant ce chier sendmail.st ; il sut par exemple de
faire :
# cp /dev/null /usr/local/lib/mail/sendmail.st

{ La meilleure methode est probablement de mettre en route le deboguage par


syslogd(8). Vous aurez des traces detaillees de qui fait quoi, en quelle quantite,
pour ou, par ou, etc. Cela signi e que le demon /etc/syslogd est en service sur
la machine (ce qui est sans doute, et heureusement, le cas sur un systeme bien
administre) et que vous aurez ajoute dans sa con guration /etc/syslog.conf(5)
une ligne comme celle-ci :
mail.debug /var/log/syslog.mail

Si vous utilisez mail.debug avec un tra c de courrier assez important, la trace


peut devenir assez grande. Les chiers de trace de syslogd necessitent genera-
lement une maintenance routiniere destinee a les classer ou les purger, par le
truchement de crond(8).
Vous trouverez bon nombre d'utilitaires qui e ectuent des statistiques a partir
des chiers generes par syslogd. L'un des plus connus s'appelle syslog-stat.pl, il
s'agit d'un programme en perl qui est fourni avec les sources de Sendmail+IDA.

15.7 Coherence des distributions binaires


Il n'y a pas de reel standard de con guration du courrier electronique, et il n'y a pas
(( une arborescence de repertoires de reference )) pour y placer ces programmes.
Il est necessaire de s'assurer que les di erents composants du systeme (courrier, News
Usenet, TCP/IP) sont d'accord sur l'emplacement du programme qui delivre le cour-
rier local (lmail, deliver, etc.), de celui pour le courrier distant (rmail), et de l'agent
de transport du courrier (sendmail ou smail). De telles considerations ne sont pas
toujours documentees, bien que l'emploi de la commande strings puisse aider a de-
terminer quels chiers et quels repertoires sont attendus par tel ou tel binaire. Voici
260 Chapitre 15. Sendmail+IDA
quelques problemes que nous avons rencontre dans le passe avec certaines distributions
binaires et sources de Linux parmi les plus courantes.
{ Certaines versions de la distribution NET-2 de TCP/IP ont un programme
nomme umail de ni comme service, au lieu de sendmail.
{ Divers portages de elm et mailx recherchent, pour delivrer le courrier, l'agent
/usr/bin/smail plut^ot que sendmail.
{ Sendmail+IDA conna^t en interne deliver, mais il pense le trouver dans /bin
plut^ot que dans /usr/bin, ou il est le plus souvent place sous Linux.
Plut^ot que de perdre du temps a recompiler tous les programmes a partir des sources,
nous contournons en general le probleme par un lien symbolique approprie.

15.8 Pour en savoir plus...


Pour obtenir plus d'informations sur sendmail, consultez le document Linux (( MAIL-
HOWTO )) poste regulierement dans comp.answers. Il est aussi disponible par FTP
anonyme sur rtfm.mit.edu 4. Toutefois, les meilleurs renseignements se trouvent dans
les sources de Sendmail+IDA. Regardez dans le repertoire ida/cf, les chiers DBM-
GUIDE, OPTIONS et Sendmail.mc.

4 Ce document est disponible en version francaise sur les sites di usant Linux en France.
:
261

Chapitre 16
Les News Usenet
16.1 L'histoire de Usenet
L'idee de di user des (( nouvelles )) par reseau date de 1979, lorsque deux etudiants
americains, Tom Truscott et Jim Ellis, eurent l'idee d'utiliser UUCP dans le but
d'echanger des informations entre les utilisateurs de plusieurs machines UNIX. Ils
etablirent alors un petit reseau de trois systemes, en Caroline du Nord.
Tout au debut, le tra c etait gere par quelques shell-scripts (reecrits plus tard en
langage C), mais aucun code ne fut jamais di use. Cet ensemble fut rapidement
remplace par (( A news )), la premiere version publique des logiciels de (( News )).
Cette version n'etait pas prevue pour gerer plus de quelques articles par groupe et
par jour. Lorsque le volume se mit a augmenter, Mark Horton et Matt Glickman
realiserent une nouvelle version des programmes, qu'ils baptiserent la version (( B )),
soit (( Bnews )). La premiere version publique de Bnews portait le numero 2.1, c'etait
en 1982. Depuis, elle a continuellement evolue, subissant de profondes evolutions.
Actuellement, Bnews en est a la version 2.11, qui devient obsolete; le responsable de
sa maintenance etant passe a INN.
Une autre reecriture fut entreprise et di usee en 1987 par Geo Collyer et Henry
Spencer ; il s'agit de la version (( C )), ou C News, la plus courante etant la ver-
sion (( C News Performance )). Sur les sites qui transportent un tres grand nombre
de groupes, la surcharge due a l'appel frequent de relaynews, qui est le programme
distribuant les articles vers les autres machines, est assez importante. La version (( Per-
formance )) ajoute une option a ce programme permettant de l'utiliser en mode demon,
dans lequel il fonctionne en t^ache de fond. Cette version, tres repandue, est fournie
avec beaucoup de distributions binaires de Linux.
Jusqu'a la version C, cet ensemble etait etudie pour une utilisation sur des reseaux
UUCP, bien que son emploi dans d'autres environnements rest^at possible. Mais obte-
262 Chapitre 16. Les News Usenet
nir des transferts ecaces sur des reseaux performants comme TCP/IP ou DECnet
demandait une nouvelle orientation du projet. Aussi, en 1986, fut introduit NNTP, le
Network News Transfer Protocol (protocole de transfert de News par reseau). Il est
base sur des connexions reseau et speci e un certain nombre de commandes interac-
tives permettant le transfert et la lecture des articles.
Il existe beaucoup d'applications basees sur NNTP sur l'Internet. Le paquetage nntpd
de Brian Barber et Phil Lapsley, que vous pouvez employer pour o rir un service de
lecture des News a des h^otes d'un reseau local, est l'un des plus connus. Il est prevu
pour completer les ensembles de gestion de News comme Bnews ou C News, en leur
apportant le support du protocole NNTP.
INN, ou Internet News, en est un autre. Ce n'est pas qu'un simple frontal, mais un
systeme a part entiere. Il comprend un demon tres sophistique qui peut supporter de
multiples liaisons NNTP concurrentes, et est devenu le serveur de News ideal employe
sur un nombre de plus en plus grand de sites Internet.

16.2 Mais qu'est-ce que Usenet ?


Ce qui stupe e beaucoup de gens, c'est que Usenet ne fait partie d'aucune organisa-
tion, n'a aucune gestion centralisee, aucun responsable, Usenet n'a pas de chef. En
fait, l'un des principes de Usenet, c'est qu'en dehors des descriptions techniques, il
est impossible de de nir ce que c'est ; tout ce que l'on peut indiquer, c'est ce que
Usenet n'est pas. Si vous avez a portee de main l'excellent livre Zen and the Art of
the Internet de Brendan Kehoe, vous pourrez y trouver une liste tres amusante des
non-proprietes de Usenet.
Au risque de para^tre stupide, on peut de nir Usenet comme la collaboration de sites
distincts qui s'echangent des News Usenet 1 . Pour devenir un site Usenet, tout ce
que vous avez a faire est de trouver un autre site et vous mettre d'accord avec ses
proprietaires et administrateurs pour echanger des articles avec vous. Comme ils ont le
m^eme accord avec un autre site qui agit de m^eme pour eux, vous voyez immediatement
appara^tre un autre aspect de la philosophie de Usenet : (( Trouvez un fournisseur, et
vous en ferez partie. ))
L'unite de base des News Usenet est l'article. Il s'agit d'un message redige par un
utilisateur, qu'il (( poste )) sur le reseau. A n que les autres sites puissent le gerer, on
lui rajoute des informations administratives, le fameux en-t^ete. Il ressemble beaucoup
a celui du courrier au standard RFC 822, en ce sens qu'il est constitue de di erentes
lignes de texte, chacune commencant par un mot-cle termine par le caractere (( : )),
suivi de la valeur attribuee a ce champ 2 .
1 Prononcez (( les niouzes iouzenet )) pour faire pro.
:
2 Le format des articles Usenet est actuellement de ni dans le document RFC 1036. Il sera a
:
terme remplace par un autre document en cours de redaction, de nissant des criteres plus stricts
dans le respect des normes ; la recente arrivee de nombreux sites utilisant des programmes concus en
depit des speci cations causant une degradation du service, il a ete decide d'y mettre bon ordre.
16.3. Comment les News sont-elles gerees sur Usenet ? 263

Les articles sont postes dans un ou plusieurs newsgroups. On peut considerer un news-
group comme un forum destine a recevoir des articles concernant un sujet particulier.
On utilise indi eremment les termes newsgroups, groupes, forums, voire conferences
pour les designer; a l'etranger seuls les deux premiers termes sont employes dans le
cadre de Usenet. Tous les groupes sont organises en hierarchies, leur nom indiquant
leur emplacement dans cette arborescence ; ce qui permet souvent de savoir facilement
quel est le sujet traite, au vu du nom. Par exemple, tout le monde comprendra que le
groupe appele comp.os.linux.announce sert aux annonces concernant un systeme
d'exploitation (os) d'ordinateurs (computers) nomme Linux.
Ces articles sont alors echanges entre tous les sites Usenet qui ont l'intention de trans-
porter les messages de ce groupe. Lorsque deux sites se mettent d'accord pour echanger
des News, ils sont libres de transporter les groupes qu'ils desirent, et peuvent m^eme
creer de nouvelles hierarchies locales a leurs systemes. Par exemple, groucho.edu
peut avoir un lien avec barnyard.edu, qui est un site Usenet important, et plusieurs
liaisons avec des sites plus petits auxquels il fournit certains groupes (vous verrez
souvent designer la fourniture de News par le terme anglais feed). Maintenant, bar-
nyard.edu peut recevoir toute les hierarchies Usenet, alors que GMU n'en desire que
quelques-unes comme sci, comp, rec, etc. Certains petits sites, disons par exemple
une machine UUCP appelee brewhq, ne voudront prendre que quelques forums, pour
des raisons de lenteur de liaison et de ressources limitees. De plus, brewhq peut vou-
loir recuperer une hierarchie locale fj, que GMU ne possede pas. Il sera par consequent
oblige d'etablir une autre liaison avec gargleblaster.com, qui transporte ces groupes,
et qui les fournira a brewhq. Le ux de News correspondant a cette situation est
illustre dans la gure 16.1.
Les reperes inscrits a c^ote des eches en provenance de brewhq necessitent toutefois
une explication. Par defaut, ce site veut que tous les articles generes localement soient
envoyes a groucho.edu. Mais comme groucho.edu ne transporte pas les groupes
fj, il n'y a aucun inter^et a les leur envoyer, ils seront rejetes. Par consequent, le ux
allant de brewhq a GMU est repere all,!fj, signi ant que tous (all) les groupes sauf
ceux de la hierarchie fj sont transmis.

16.3 Comment les News sont-elles gerees sur Use-


net ?
Aujourd'hui, Usenet a pris des proportions enormes. Les sites qui transportent la
totalite des hierarchies transferent environ 180 Mo d'articles par jour 3 . Bien s^ur, cela
necessite un peu plus de procedures que de simples copies de chiers. Aussi, voyons
comment la plupart des systemes UNIX gerent les News Usenet.
Elles sont distribuees sur le reseau par di erents moyens de transport. Au tout de-
3 Attendez... 180 Mo a 9 600 bps, cela nous fait 180 millions divises par 1 200, ce qui nous don-
:
nerait... plus de 40 heures de transfert !
264 Chapitre 16. Les News Usenet

Usenet

barnyard.edu gargleblaster.com

comp,sci,
fj
rec fj
all

all,!fj
groucho.edu brewhq
comp.os,
comp.periphs

Fig. 16.1 - Circuit des News Usenet a l'universite Groucho Marx.


16.3. Comment les News sont-elles gerees sur Usenet ? 265

but, il s'agissait de UUCP ; mais de nos jours le plus gros du tra c se fait par des
sites Internet. L'algorithme de routage utilise est base sur la redondance : chaque site
maintient un certain nombre de liens (les fameux feeds de News) avec d'autres. Tout
article genere ou recu par le systeme local leur est expedie, sauf s'il est deja passe
par eux. Il est possible de savoir par ou est passe un article gr^ace au champ Path de
l'en-t^ete, qui contient la liste de tous les systemes qu'il a traverses, separes par un
point d'exclamation (bang-path).
Pour distinguer les articles et reconna^tre les doublons, chacun d'eux doit comporter
dans son en-t^ete un identi cateur unique, appele le Message-ID, qui est realise a partir
du nom du site associe a un numero de serie unique sur cette machine, presente sous
la forme numero@site . Le systeme de News enregistre chaque article traite par
< >

ce numero dans un chier appele history, qui est teste a chaque fois qu'un nouveau
message se presente.
Le ux entre deux sites quelconques peut ^etre limite selon deux criteres. D'une part, il
existe un champ indiquant l'etendue de sa distribution (Distribution dans l'en-t^ete),
permettant eventuellement de ne le transmettre qu'a un nombre limite de sites accep-
tant cette distribution particuliere. D'autre part, le nombre de groupes echanges peut
^etre limite par l'un ou l'autre des systemes. L'ensemble des groupes et distributions
autorises a ^etre transmis est generalement con gure dans le chier sys.
La grande quantite d'articles a traiter necessite generalement quelques ameliorations
de la methode precedente. Sur les reseaux UUCP, il est naturel de collecter les mes-
sages sur une certaine periode puis de les combiner ensemble en un seul gros chier,
qui est compresse puis envoye sur le site distant. C'est la di usion par lots.
Une autre technique fait appel au protocole ihave/sendme qui evite aux articles du-
pliques d'^etre transferes avant d'^etre nalement rejetes. Au lieu de mettre tous les
articles dans des lots et de les expedier tels quels, ce ne sont que les message-ID qui
sont utilises pour constituer un enorme message nomme (( ihave )) (je possede) expedie
au site distant. Celui-ci en prend connaissance, le compare a son chier d'historique,
et retourne la liste des articles pour lesquels il desire un message appele (( sendme ))
(envoie-moi). Seuls ces articles seront alors transferes.
Bien s^ur, ce protocole ihave/sendme n'a d'inter^et que s'il met en jeu deux gros sites
qui recoivent les News depuis plusieurs ux independants les uns des autres, et qui
sont connectes susamment souvent pour obtenir des echanges ecaces.
Les sites connectes a l'Internet utilisent generalement des programmes bases sur
TCP/IP faisant appel au protocole NNTP 4 . Il permet de transferer les articles et
d'o rir des acces individuels a Usenet a tout utilisateur se trouvant sur une machine
distante et possedant un programme de lecture adequat.
NNTP permet le transfert de trois facons di erentes. La premiere est une version
temps reel de ihave/sendme, aussi connue sous le nom de methode du pushing (on
(( pousse )) les articles). Dans la deuxi eme, le client demande une liste d'articles dans
4 Decrit dans le RFC 977.
:
266 Chapitre 16. Les News Usenet
une hierarchie ou un groupe donne, qui sont arrives sur le serveur apres une certaine
date, et choisit ceux qu'il ne peut pas trouver dans son chier d'historique. C'est
le pulling (on (( tire )) les articles). La troisieme methode est destinee a la lecture
interactive et permet de recuperer des articles depuis les groupes speci es, aussi bien
que d'en poster, le plus souvent a l'aide de programmes conviviaux appeles (( lecteurs )).
Sur chaque site, les News sont stockees dans une arborescence de repertoires situee
sous /var/spool/news, chaque article faisant l'objet d'un chier separe. Le nom du
repertoire est constitue du nom du groupe, ses composants etant ceux du chemin
d'acces. C'est-a-dire que, par exemple, les messages de comp.os.linux.misc se trou-
veront dans le repertoire /var/spool/news/comp/os/linux/misc. Ils se voient assigner
un numero, dans l'ordre ou ils arrivent, qui sert de nom de chier. L'etendue de ces
numeros est conservee dans un chier nomme active, qui sert en m^eme temps de liste
des groupes connus sur le site en question.
Puisque l'espace de stockage o ert par les disques durs est encore de nos jours une
ressource nie 5 , il faut penser a eliminer regulierement les articles devenus trop vieux :
c'est le processus d'expiration. En principe, il est possible de con gurer cela de ma-
niere souple, les articles de certains groupes ou certaines hierarchies etant elimines un
certain nombre de jours apres leur arrivee sur le systeme. L'expediteur peut lui-m^eme
decider de la date a partir de laquelle son message pourra ^etre supprime, en speci ant
une date d'expiration dans le champ Expires de l'en-t^ete.

5 Certains arment que Usenet est le fruit d'un complot ourdi par les constructeurs de modems
:
et les fabricants de disques durs.
267

Chapitre 17
C News
C News est l'un des ensembles de logiciels de News les plus connus. Il est destine aux
sites transportant les articles par UUCP. Ce chapitre traitera de son fonctionnement,
decrira son installation et les t^aches de maintenance necessaires a son fonctionnement
correct.
Les chiers de con guration de C News se trouvent dans /usr/lib/news, et l'essentiel
de ses programmes executables se situent dans le repertoire /usr/lib/news/bin. Les
articles sont stockes dans /var/spool/news. Vous devez veri er, car c'est tres impor-
tant, que tous les chiers contenus dans ces repertoires appartiennent a l'utilisateur
news et au groupe news. La plupart des problemes rencontres sont dus a des chiers
inaccessibles a l'application. Vous devez prendre l'habitude de passer sous le compte
utilisateur news (par la commande su) avant de toucher a quoi que ce soit dans la
gestion des News. La seule exception a cette regle concerne le programme setnew-
sids, qui est utilise pour positionner le numero d'identi cation utilisateur de certains
utilitaires : il doit appartenir a root et avoir le bit setuid positionne.

17.1 L'injection des articles


Les articles peuvent ^etre fournis a C News de di erentes facons. Lorsqu'un utilisateur
local poste un message, son programme lecteur l'envoie generalement a la commande
inews, qui complete les informations necessaires dans l'en-t^ete. Les articles en prove-
nance des sites distants | que ce soit un lot ou un message individuel | sont passes au
programme rnews, qui les place dans le repertoire /var/spool/news/in.coming, d'ou ils
seront extraits plus tard par newsrun. Dans les deux cas, l'article sera eventuellement
traite par la commande relaynews.
Pour chaque article, relaynews commence par tester s'il a deja ete vu sur le site local
en recherchant son Message-ID dans le chier history : les articles dupliques seront
268 Chapitre 17. C News
rejetes. Puis il regarde la ligne d'en-t^ete Newsgroups pour veri er si le site demande
bien le ou les groupes indiques. Si c'est le cas, et que le chier active contient bien
ce nom, relaynews essaie de placer le message dans le repertoire correspondant du
spoule, qui sera cree s'il n'existait pas encore. En n, le Message-ID est enregistre
dans le chier history. Sinon, l'article sera rejete.
Si relaynews ne peut pas mettre en place un article parce qu'il a ete poste dans un
groupe qui n'est pas dans le chier active, cet article sera rejete et deplace dans le
groupe junk 1 . Le programme relaynews veri era aussi l'integrite de l'article, sa date,
et rejettera ceux qu'il trouvera non conformes. Les lots qui sont declares defectueux
pour une raison quelconque sont deplaces dans /var/spool/news/in.coming/bad, et un
message d'erreur est enregistre dans les chiers de trace.
Ensuite, l'article sera relaye vers tous les autres sites qui demandent des News de
ce groupe, par le transport speci e pour chacun d'eux. Pour ^etre s^ur qu'il n'est pas
envoye vers un site qui l'aurait deja vu passer, le nom de chacun de ces sites est
recherche dans la ligne Path de l'en-t^ete : seuls ceux dont le nom n'appara^t pas dans
cette ligne recevront le message.
C News est utilise couramment pour relayer Usenet entre des sites UUCP, bien qu'il
soit possible de l'utiliser aussi dans un environnement NNTP. Pour fournir une ma-
chine distante par UUCP (soit par des articles isoles, soit par des lots de messages),
il est fait appel a la commande uux, a n qu'elle execute rnews sur le site distant, le
message lui etant passe sur son entree standard.
Lorsque la creation de lots est validee pour un site, C News n'envoie aucun article
immediatement, mais rajoute le nom du chier correspondant dans un chier gene-
ralement appele out.going/site/togo. Periodiquement, un programme de generation
de lots est execute par une entree crontab 2 , ce qui rassemble tous les articles dans un
ou plusieurs gros chiers compresses en option, et les envoie a la commande rnews du
site distant.
La gure 17.1 illustre le ux des News via relaynews : les articles peuvent ^etre relayes
depuis le site local (denote par convention par le mot cle ME), par courrier vers un
site nomme ponderosa, et sous forme de lots vers la machine moria.

17.2 Installation
Pour installer C News, mettez en place les chiers contenus dans l'archive si ce n'est
pas encore fait, et editez les chiers de con guration indiques ci-dessous. Ils se trouvent
1 Il peut y avoir une di erence entre les groupes qui existent sur votre site, et ceux qu'il desire
:
recevoir. Par exemple, la liste de souscription peut speci er comp.all, ce qui signi e tous les groupes
de la hierarchie comp, mais seule une partie de ces groupes peut ^etre indiquee dans votre chier
active. Les articles pour les groupes absents de ce chier seront places dans junk.
2 Il est tres important que ce soit le crontab de l'utilisateur news, a n de ne pas modi er les
:
permissions des di erents chiers.
17.2. Installation 269

article

relaynews

history

ME ponderosa moria

courrier

active spoule out.going/


moria/togo

Fig. 17.1 - Flux des News par relaynews.

tous dans /usr/lib/news, et leurs di erents formats vont ^etre decrits dans les sections
suivantes :
sys Vous devrez sans doute modi er la ligne ME qui decrit votre systeme,
bien que l'emploi de all/all soit une solution qui fonctionne toujours.
Il faudra aussi ajouter une ligne pour chaque site a qui vous enverrez
des articles.
Si vous ^etes un site UUCP isole en bout de cha^ne, il vous sura d'une
ligne qui renvoie tous les articles generes localement a votre fournis-
seur. En supposant que ce soit moria, votre chier sys ressemblera
simplement a ceci :
ME:all/all::
moria/moria.orcnet.org:all/all,!local:f:

organization Le nom de l'organisme auquel la machine appartient. Par exemple,


(( SARL La biere virtuelle )). S'il s'agit de votre ordinateur domes-
tique, mettez ce que vous voulez, sinon la plupart des gens ne consi-
dereront pas votre site comme correctement con gure.
newsgroups Une liste de groupes, un par ligne, suivi de leur description sommaire.
Ces descriptions sont utilisees par les programmes lecteurs lorsqu'ils
achent la liste des forums accessibles.
270 Chapitre 17. C News
mailname L'adresse electronique de votre site, comme par exemple bibine.com.
whoami Le nom de votre site, pour le traitement des News. On y met le plus
souvent le nom UUCP, par exemple gueuze.
explist Vous devrez editer ce chier pour qu'il corresponde a vos besoins
d'expiration des messages. Son contenu depend etroitement de la
place disque dont vous disposez.
Pour creer une hierarchie initiale, recuperez les chiers active et newsgroups d'un
site qui vous fournit, et installez-les dans /usr/lib/news, en veri ant bien qu'ils ap-
partiennent a news et ont le mode 644. Supprimez tous les groupes to.* du chier
active, puis rajoutez to.mon-site et to.fournisseur, ainsi que junk et control. Les
groupes to.* sont utilises pour l'echange de messages ihave/sendme, mais vous devez
les creer m^eme si vous ne comptez pas employer ce protocole. Ensuite, remplacez tous
les numeros d'articles contenus dans la deuxieme et la troisieme colonne du chier
active en executant la commande suivante :
# cp active active.old
# sed 's/ [0-9]* [0-9]* / 0000000000 00001 /' active.old > active
# rm active.old

La deuxieme ligne appelle la commande sed(1), l'utilitaire favori des administrateurs.


Ici, il s'agit de remplacer deux cha^nes de chi res par une cha^ne de zeros et la valeur
000001, respectivement.
En n, creez le repertoire de spoule et les sous-repertoires utilises pour l'arrivee et le
depart des articles :
# cd /var/spool
# mkdir news news/in.coming news/out.going
# chown -R news.news news
# chmod -R 755 news

Si vous possedez une version recente de C News, il vous faudra aussi creer le repertoire
news/out.master.
Si vous utilisez des programmes lecteurs de provenances diverses, vous vous ren-
drez compte que certains recherchent le spoule dans /usr/spool/news au lieu de
/var/spool/news, et dans ce cas, ils seront incapables de trouver les articles. Si c'est le
cas, il vous sura de creer un lien symbolique de /usr/spool/news vers /var/spool/news.
Vous ^etes maintenant equipe pour recevoir des News. Notez que vous n'aurez pas
besoin de creer d'autres repertoires que ceux mentionnes ci-dessus, C News s'occupera
de le faire automatiquement lorsque des articles arriveront.
En particulier, cela se produit pour tous les groupes dans lesquels un article a ete cross-
poste. Aussi, au bout d'un moment, vous trouverez le spoule rempli de repertoires
17.3. Le chier sys 271

correspondant a des groupes que vous n'avez jamais demande, comme alt.lang.teco.
Il est possible d'eviter cela en supprimant chacun de ces groupes du chier active, ou
en lancant periodiquement un shell-script qui supprime les repertoires vides a partir
de /var/spool/news (sauf bien entendu out.going et in.coming).
C News envoie les messages d'erreur et de service a un utilisateur particulier. Par
defaut, il s'appelle usenet. Si vous utilisez ce nom (ce qui est conseille), vous devrez
declarer un alias qui enverra tout le courrier a ce nom vers les bo^tes aux lettres des
personnes responsables. (Les chapitres 14 et 15 vous expliqueront comment faire.)
Vous pouvez aussi changer cette valeur par defaut en donnant a la variable d'en-
vironnement NEWSMASTER le nom approprie. Vous devrez le faire dans le chier
crontab de l'utilisateur news, ainsi qu'a chaque fois que vous aurez a lancer un outil
d'administration a la main. Il est donc preferable d'installer un alias pour ne pas se
compliquer la vie.
Il faudra aussi veri er que dans le chier /etc/passwd, le vrai nom de chaque utilisateur
gure bien dans le champ pw gecos (c'est le quatrieme champ). Ce nom appara^tra
dans la ligne From de l'article, et il ne faut pas qu'il y apparaisse n'importe quoi ; c'est
une question de netiquette 3. Si vous utilisez deja le courrier electronique, tout cela
est probablement deja proprement con gure.

17.3 Le chier sys


Le chier sys, situe dans /usr/lib/news, contr^ole quelles hierarchies vous recevez et
envoyez aux autres sites. Bien qu'il existe des outils de maintenance pour le gerer
(addfeed et delfeed), tout le monde s'accorde a dire qu'il vaut bien mieux e ectuer ces
operations a la main.
Il contient des entrees pour chaque site auquel vous envoyez des News, et une des-
cription des groupes que vous accepterez. Chaque entree est de cette forme :

site[/exclusions]:liste-groupes[/distributions][:drapeaux[:commandes]]

Une entree peut s'etendre sur plusieurs lignes, en rajoutant un anti-slash au bout (\).
Le signe diese (#) denote un commentaire.
site Il s'agit du nom du site auquel cette entree s'applique, c'est genera-
lement le nom UUCP qui est choisi. Il doit y avoir une entree pour
votre propre site dans ce chier sys, sinon vous ne recevrez jamais
aucun article.
3 La nettiquette est en quelque sorte le manuel de savoir-vivre sur Usenet. Un document humo-
:
ristique poste tous les mois en rappelle les principaux traits, vous pouvez en consulter la version
francaise dans la hierarchie francophone fr.*, ou la telecharger sur le serveur ftp.fdn.org.
272 Chapitre 17. C News
Le nom special ME denote votre site. Cette entree de nit tous les
groupes que vous comptez stocker localement. Les articles de groupes
qui ne sont pas decrits dans cette ligne seront places dans junk.
Puisque C News compare site avec ceux contenus dans la ligne
Path des en-t^etes d'articles, vous devez vous assurer que tout cor-
respond bien. Certains mettent leur nom pleinement quali e, ou un
alias comme news.site.domaine. Pour eviter que des articles en
provenance de tels sites ne leur soient inutilement reexpedies, vous
devrez ajouter ces noms a la liste d'exclusion, separes par des vir-
gules.
Par exemple, pour l'entree s'appliquant a la machine moria, le champ
site contiendrait moria/moria.orcnet.org.

liste-groupes
Il s'agit d'une liste de souscription de groupes et hierarchies (dont le
caractere separateur est la virgule) pour le site en question. Une hie-
rarchie peut ^etre speci ee en donnant son pre xe (comme comp.os
pour tous les groupes dont le nom commence par ces lettres), suivie
facultativement par le mot cle all (par exemple, comp.os.all).
Une hierarchie ou un groupe est exclus en le faisant preceder par
un point d'exclamation, marquant la negation. Si un groupe est re-
cherche dans cette liste, c'est le plus long qui gagne. Par exemple, si
liste-groupes contient :

!comp,comp.os.linux,comp.folklore.computers

Cela signi era qu'aucun groupe appartenant a la hierarchie comp ne


sera envoye a ce site, sauf comp.folklore.computers et tous ceux
en dessous de comp.os.linux.
Pour lui envoyer toutes les News que vous recevez vous-m^eme, mettez
simplement all dans liste-groupes.
distributions
Ce champ, separe du precedent par un slash (/) contient une liste
des distributions qui seront envoyees au site concerne. La encore,
vous pouvez en exclure certaines en les faisant preceder d'un point
d'exclamation, ou les designer toutes par le mot all. Si vous omettez
ce champ distributions, cela denote implicitement all.
Par exemple, vous pouvez mettre comme liste de distributions quelque
chose comme all,!local, pour eviter d'envoyer les groupes a usage local
aux sites distants.
Il y a en principe au moins deux distributions : world, qui est souvent
celle par defaut lorsque aucune n'est precisee, et local. Il peut y en
avoir d'autres s'appliquant a certaines regions, etats, pays, departe-
17.3. Le chier sys 273

ments, etc. En n, il en existe deux speci ques a C News : ce sont


sendme et ihave, qu'il utilise pour le protocole sendme/ihave.
L'utilisation des distributions fait l'objet de nombreuses polemiques 4.
Pour certains, quelques lecteurs de News creent de (( fausses )) distri-
butions en utilisant simplement le nom de la hierarchie (comp par
exemple) en postant dans des groupes tel comp.os.linux.advocacy.
Les distributions s'appliquant aux regions sont douteuses, car les ar-
ticles peuvent prendre un chemin detourne et devoir sortir hors de
cette region pour y revenir 5. Les distributions s'appliquant a une or-
ganisation particuliere ont, par contre, un certain sens : par exemple,
pour eviter que des informations con dentielles sur votre entreprise
s'echappent d'un groupe local. Mais pour ce genre de cas, mieux vaut
creer une hierarchie separee.
drapeaux Cette option decrit certains parametres du ux. Elle peut ^etre ab-
sente, ou bien comporter une combinaison des valeurs suivantes :
F Ce drapeau valide la creation de lots 6 .
f Pratiquement identique a F, mais permet a C News
de calculer la taille des lots a partir, de maniere plus
precise.
I Ce drapeau indique a C News de produire une liste
d'articles pour l'utilisation du protocole d'echange
ihave/sendme. Il faut egalement e ectuer quelques
modi cations aux chiers sys et batchparms dans ce
cas.
n Cree des chiers de lots pour les transferts NNTP
avec des clients comme nntpxmit (voir le chapitre 18).
Ces lots contiennent les noms des chiers contenant
les articles ainsi que leurs Message-ID.
L Indique a C News de ne transmettre que les articles
postes sur votre site. Ce drapeau peut ^etre suivi par
un nombre decimal n, qui permettra alors de ne pos-
ter que les messages en provenance d'au plus n hops
de votre site. Le nombre de hops est determine par
:4 En fait, de nos jours la plupart des administrateurs de sites Usenet s'accordent a dire que si
l'idee n'etait pas mauvaise au depart, son application s'est plut^ot tres mal passee et qu'il faut eviter
a tout prix d'utiliser un champ (( distribution )), aucun site ne le gerant de la m^eme maniere ; c'est le
meilleur moyen de perdre des articles.
:5 Il est tres courant de voir des articles postes par exemple a Hambourg, se retrouver a Francfort
via reston.ans.net aux Pays-Bas, voire en passant par un site des USA.
:6 Ce sont les (( batches de News )) chers aux administrateurs dont la langue natale est le (( fran-
glais )).
274 Chapitre 17. C News
le contenu du champ Path de l'en-t^ete.
u Seuls les articles des groupes non moderes seront
emis.
m Seuls les articles des groupes moderes seront emis.
Vous ne pouvez employer au plus qu'un F, f, I, ou n.
commandes Ce champ contient la commande a executer pour chaque article
lorsque le traitement par lots est en service. Le message sera passe
a cette commande via son entree standard ; a n'utiliser que sur les
petits ux, sinon la charge sur chacun des deux systemes deviendra
prohibitive.
La commande par defaut est :
uux - -r -z syst
eme !rnews

Elle execute rnews sur le systeme distant, en lui passant l'article sur
son entree standard.
Le chemin de recherche des commandes indiquees dans ce champ
est par defaut /bin:/usr/bin:/usr/lib/news/bin/batch. Le dernier re-
pertoire contient un certain nombre de shell-scripts dont les noms
commencent par via ; nous les decrirons brievement un peu plus loin
dans ce chapitre.
Si le traitement par lots a ete valide par l'un des drapeaux F, f,
I ou n, C News s'attendra a trouver un nom de chier dans ce
champ, et non pas une commande. Si ce nom ne commence pas
par un slash (/), il sera considere comme etant relatif au repertoire
/var/spool/news/out.going. Si le champ est vide, la valeur par defaut
sera systeme /togo.
Lors de la con guration de C News, vous devrez probablement rediger votre propre
chier sys. Pour vous aider dans cette t^ache, nous allons vous donner un exemple
concernant bibine.com, a partir duquel vous pourrez recopier tout ce dont vous avez
besoin et l'adapter a votre site.
# Nous prenons tout ce qu'ils nous envoient.
ME:all/all::

# Nous envoyons tout ce que nous recevons 


a moria, sauf les
# articles locaux et ceux relatifs aux brasseurs. Nous utilisons
# des lots (batching).
moria/moria.orcnet.org:all,!to,to.moria/all,!local,!brasseurs:f:

# Nous exp
edions comp.risks par courrier 
electronique 
a
# l'utilisateur jack@ponderosa.uucp
17.4. Le chier active 275

ponderosa:comp.risks/all::rmail jack@ponderosa.uucp

# La machine swim veut un petit flux de News:


swim/swim.twobirds.com:comp.os.linux,rec.humor.oracle/all,!local:f:

# Nous enregistrons les cartes UUCP publi


ees pour traitement
# ult
erieur.
usenet-maps:comp.mail.maps/all:F:/var/spool/uumaps/work/batch

17.4 Le chier active


Le chier active est situe dans /usr/lib/news et contient la liste de tous les groupes
connus par votre site, ainsi que les articles actuellement accessibles. Vous n'aurez
que tres rarement besoin d'y toucher, mais nous allons tout de m^eme expliquer son
contenu pour que vous compreniez bien son r^ole. Il contient des entrees de la forme :

groupe haut bas permission

Le champ groupe contient le nom du groupe ; bas et haut sont les numeros du premier
et du dernier article actuellement disponibles dans ce groupe. S'il est vide, bas vaut
alors haut+1.
En n disons que c'est ce que bas est cense faire, parce que, pour des raisons d'eca-
cite, C News ne met jamais cette valeur a jour. Ce ne serait pas un probleme s'il n'y
avait pas certains lecteurs de News comptant sur ce champ pour veri er s'ils peuvent
purger des articles de leur base de donnees des ls de discussions. Pour mettre a jour
ce champ bas, vous devrez par consequent executer periodiquement la commande
updatemin (ou, dans de plus anciennes versions de C News, le script upact).
Le champ permission est un parametre indiquant quel type d'acces auront les utili-
sateurs, il peut prendre l'une des valeurs suivantes :
y Les utilisateurs ont le droit de poster dans ce groupe.
n Les utilisateurs n'ont pas le droit de poster dans ce groupe, mais ils
peuvent le lire.
x Ce groupe a ete invalide sur le systeme local. Cela arrive quelque-
fois lorsque des administrateurs (ou leurs superieurs) se plaignent du
contenu des messages y etant postes.
Les articles recus pour ce groupe ne sont pas stockes localement, mais
ils seront toujours emis vers les sites qui les demandent.
m Indique un groupe modere. Lorsqu'un utilisateur tente de poster de-
dans, si son lecteur de News est bien concu, il lui noti era ce fait et
276 Chapitre 17. C News
enverra l'article au moderateur par courrier electronique. L'adresse
du moderateur est prise dans le chier moderators situe dans le re-
pertoire /usr/lib/news.
=vrai-groupe
Marque groupe comme etant un alias local pour un autre groupe,
nomme en realite vrai-groupe. Tous les articles postes dans groupe
y seront rediriges.
Dans C News, vous n'aurez en general pas besoin d'acceder directement a ce chier.
Les groupes peuvent ^etre ajoutes ou supprimes localement par les commandes add-
group et delgroup (consultez la section (( Outils et travaux de maintenance )) page 287).
Les messages de contr^ole newgroup et rmgroup creent ou suppriment un groupe dans
la totalite de Usenet. N'envoyez jamais un tel message vous-m^eme ! Vous vous feriez
har du monde entier. Toutes les instructions de creation de groupe a un tel niveau
sont postees tous les mois dans news.announce.newusers.
Le chier active.times est tres lie a active : chaque fois qu'un nouveau groupe est cree,
C News enregistre un message dans ce chier. Il contient le nom du groupe cree, la
date de creation, si celle-ci a ete faite sur un message de contr^ole newgroup ou locale-
ment, et le nom de la personne ayant cree ce groupe. Il sert aux programmes lecteurs
qui peuvent eventuellement noti er aux utilisateurs les nouveaux groupes recemment
crees. Il est egalement utilise par la commande NEWGROUPS du protocole NNTP.

17.5 Le traitement par lots (batching)


Les lots d'articles se conforment a un format particulier qui est le m^eme pour Bnews,
C News, and INN 7 . Chaque article est precede d'une ligne comme celle-ci :

#! rnews taille

La valeur taille est le nombre d'octets contenus dans l'article. Lorsque l'on utilise
la compression, c'est le chier resultant qui est compresse ; il est alors precede d'une
autre ligne, indiquant que les donnees qui suivent devront ^etre decompactees. L'outil
standard permettant la compression est compress, qui est repere par :

#! cunbatch

Il arrive que l'on doive faire passer des lots par courrier, ou certaines liaisons suppri-
ment le huitieme bit des donnees. Dans ce cas, on peut proteger un lot compresse en
utilisant l'encodage appele c7 ; ils seront alors reperes par c7unbatch.
7 Ce format est de ni dans le document RFC 1036.
:
17.5. Le traitement par lots (batching) 277

Lorque le programme rnews du site distant recoit un lot de News, il teste ces reperes
a n de traiter les donnees de maniere appropriee. Certains sites utilisent le compacteur
gzip, et indiquent alors zunbatch : C News ne reconna^t pas ces en-t^etes non standard,
vous devrez modi er le code source pour pouvoir les traiter.
Le programme /usr/lib/news/bin/batch/sendbatches est charge de la realisation des
lots. Il prend une liste d'articles dans le chier site/togo, et constitue les archives en
les repartissant dans un ou plusieurs lots. Il doit ^etre execute periodiquement, au moins
une fois par heure, voire plus, en fonction du volume du tra c. Son fonctionnement
est contr^ole par le chier batchparms situe dans /usr/lib/news, qui decrit la taille
maximale autorisee pour chaque lot, et le transport a utiliser pour les delivrer ; ceci
pour chaque site. Vous pouvez speci er ces parametres soit par site, soit par des
valeurs par defaut qui seront prises en compte pour tous les systemes non mentionnes
explicitement.
Pour preparer les lots destines a un site speci que, utilisez la commande suivante :
# su news -c "/usr/lib/news/bin/batch/sendbatches site "

Appelee sans argument, la commande sendbatches traite toutes les les d'attente. Si
une entree par defaut existe dans le chier batchparms, tous les repertoires contenus
dans /var/spool/news/out.going seront traites ; sinon ne seront pris en compte que les
entrees indiquees, dans l'ordre ou elles se trouvent dans batchparms. Notez que lors
de la recherche dans out.going, sendbatches ne considere comme nom de site que les
repertoires ne contenant aucun point ou signes @ dans leur nom.
Vous trouverez probablement dans votre distribution un chier batchparms tout pr^et
contenant une entree par defaut raisonnable, aussi il y a des chances que vous n'ayez
rien a modi er. Malgre tout, nous allons decrire ce format, qu'il est bon de conna^tre.
Chaque ligne contient six champs, separes par des espaces ou tabulations :
site taille max outil compacteur transport

Le champ site contient le nom du site auquel s'applique cette entree. Le chier togo
correspondant devra se trouver dans le repertoire out.going/togo, dans le spoule. Le
mot cle /default/ indique l'entree par defaut.
Le champ taille indique la taille maximale autorisee pour chaque lot, avant com-
pression. Si un article depasse a lui seul cette taille, C News fera une exception et
creera un lot ne contenant que cet article.
La valeur max correspond au nombre maximum de batches a preparer pour le transfert
vers ce site. C'est tres utile lorsqu'un systeme doit ^etre indisponible pour une longue
periode, car il evite de voir le spoule UUCP rempli par des milliers de lots en attente
d'^etre transferes.
C News determine le nombre de lots en attente gr^ace au script queulen, situe dans
le repertoire /usr/lib/news/bin. Le paquetage newspak de Vince Skahan en contient
278 Chapitre 17. C News
une version adaptee aux implementations d'UUCP compatibles BNU. Si vous utilisez
un autre style de repertoires de spoule, comme Taylor UUCP, vous devrez ecrire un
script adapte 8.
Le champ outil designe la commande utilisee pour produire un lot a partir de la liste
d'articles contenue dans le chier togo. Pour les ux standard, il s'agit normalement
de batcher. Pour d'autres besoins, vous pouvez indiquer di erents autres programmes;
par exemple, le protocole ihave/sendme necessite que cette liste soit transformee en
un message de contr^ole poste dans le groupe to.site. Cette operation est realisee par
batchih et batchsm.
Le champ compacteur speci e la commande utilisee pour la compression. Generale-
ment, il s'agit du shell-script compcun 9 . Mais vous pouvez aussi indiquer un script
appelant gzip (que vous redigerez vous-m^eme) ; vous devrez cependant vous mettre
d'accord avec le site distant pour que sa commande uncompress sache traiter les -
chiers compactes par gzip.
Si le systeme distant ne possede pas du tout de commande uncompress, vous pouvez
speci er nocomp ; dans ce cas, les lots resteront non compactes.
Le dernier champ, transport, decrit la methode de transport qu'il faudra utiliser.
Il y a un certain nombre de commandes standard pour cela, dont le nom commence
par via. Le programme sendbatches leur passe le nom du site destinataire sur la ligne
de commandes. Si l'entree dans batchparms n'est pas /default/, il derive ce nom du
champ site en prenant toute la partie precedant un eventuel point ou slash. S'il s'agit
de l'entree /default/, ce seront les noms des repertoires presents dans out.going qui
seront utilises.
Il y a deux commandes utilisant uux pour faire executer rnews sur le systeme distant :
viauux et viauuxz. La derniere positionne l'option -z necessaire aux anciennes versions
de uux pour eviter qu'il retourne un message pour chaque article indiquant que le
transfert s'est bien passe. Vous trouverez une liste complete de ces transports dans la
page de manuel newsbatch(8).
Toutes les commandes des trois derniers champs doivent se trouver soit dans le reper-
toire out.going/site, soit dans /usr/lib/news/bin/batch. La plupart d'entre elles sont
des shell-scripts, vous pourrez donc facilement vous ecrire des outils sur mesure le cas
echeant. Elles sont invoquees par un tube ; la liste des articles est envoyee sur l'entree
standard, et le lot realise arrive sur la sortie standard, qui elle-m^eme est redirigee vers
le compacteur, etc.
Voici un exemple de ce chier :

8 Si le nombre de lots spoules ne vous preoccupe pas (parce que vous ^etes le seul a utiliser votre
:
machine et ne redigez pas des megaoctets d'articles), vous pouvez remplacer le contenu de ce script
par la simple instruction exit 0.
9 Tel que livre avec C News, compcun utilise compress avec l'option 12 bits, car c'est le plus
:
petit denominateur commun pour la plupart des sites. Vous pouvez en faire une copie, que vous
appellerez par exemple compcun16, ou vous utiliserez la compression 16 bits.
17.6. Expiration des News 279

# Fichier batchparms pour les brasseurs


# site | taille | max | outil |compacteur |transport
#-------------+--------+-------+---------+-----------+-----------
/default/ 100000 22 batcher compcun viauux
swim 10000 10 batcher nocomp viauux

17.6 Expiration des News


Dans Bnews, l'expiration etait realisee par un programme appele expire, qui prenait
une liste de groupes en arguments, ainsi que la date a prendre en compte. Pour que
des hierarchies di erentes aient des delais d'expiration di erents, il fallait ecrire un
script appelant expire separement pour chacune d'elles. C News propose maintenant
une solution bien meilleure : dans un chier nomme explist, vous indiquez des groupes
et des intervalles d'expiration. Une commande appelee doexpire est invoquee tous les
jours par cron, et traite ces groupes en fonction de ce que vous avez indique dans
cette liste.
Il est parfois necessaire de conserver les articles de certains groupes, m^eme apres
qu'ils ont expire. Par exemple, vous pouvez vouloir conserver les programmes postes
dans comp.sources.unix. Cela s'appelle naturellement l'archivage ; explist permet
de selectionner des groupes a archiver.
Une entree du chier explist est constituee ainsi :

liste-groupes permission jours archive

Le champ liste-groupes est une liste de forums, separes par des virgules, auxquels
cette entree s'appliquera. Les hierarchies peuvent ^etre speci ees en indiquant le pre-
xe des groupes, suivi le cas echeant du mot cle all. Par exemple, pour designer
tous les groupes en dessous de comp.os, vous pouvez indiquer soit comp.os, soit
comp.os.all.
Lors de l'expiration d'un groupe, son nom est recherche dans les entrees du chier ex-
plist, dans l'ordre donne. La premiere entree qui correspond s'appliquera. Par exemple,
pour supprimer la majorite de comp au bout de quatre jours, sauf les articles du
groupe comp.os.linux.announce que vous voudriez conserver une semaine, il vous
sut d'une entree pour ce dernier speci ant une periode d'expiration de sept jours,
suivie par celle pour comp, qui indiquera quatre jours.
Le champ permission precise si l'entree s'applique aux groupes moderes, non mode-
res, ou tous les groupes. Il peut prendre la valeur m (moderes), u (non moderes), ou
x (tous).
Le troisieme champ, jours, contient le nombre de jours au bout desquels les articles
expireront s'ils ne se sont pas vu assigner une date d'expiration particuliere par le
280 Chapitre 17. C News
champ Expires de l'en-t^ete. Notez que ce nombre de jours est compte a partir de
l'arrivee sur votre site, et non pas de la date ou le message a ete emis.
Ce champ jours peut toutefois ^etre plus complexe. Il peut contenir une combinaison
pouvant aller jusqu'a trois nombres separes les uns des autres par un tiret. Le premier
denotera le nombre de jours devant s'ecouler avant que l'article ne soit considere
comme candidat a l'expiration. Il est rare d'y mettre autre chose que zero. Le deuxieme
champ contiendra le nombre de jours avant expiration, c'est le m^eme que celui que
nous venons de decrire plus haut. Le troisieme contiendra le nombre de jours au
bout desquels l'article sera supprime de force, quel que soit le contenu du champ
Expires de son en-t^ ete. Si l'on n'indique seulement que le nombre du milieu, les deux
autres prennent des valeurs par defaut, qui peuvent ^etre speci ees par l'entree speciale
/bounds/, decrite un peu plus loin.
Le quatrieme champ, archive, indique si le groupe doit ^etre archive, et a quel endroit.
Si l'archivage n'est pas demande, il sut d'y mettre un tiret. Sinon, vous pouvez
utiliser un chemin d'acces complet a un repertoire (et non pas d'un chier), ou le signe
@ qui symbolisera le repertoire d'archivage par defaut. Celui-ci sera alors indique a
doexpire par l'option -a de sa ligne de commandes. Un repertoire destine a l'archivage
doit appartenir a l'utilisateur news. Lorsque doexpire archive un article de, disons,
comp.sources.unix, il le place dans le repertoire comp/sources/unix a partir
du repertoire d'archivage, en creant l'arborescence si necessaire. Mais ce repertoire
d'archivage devra exister, il n'est jamais cree automatiquement.
Le programme doexpire tient comte de deux entrees de votre chier explist : au lieu
d'une liste de groupes, elles contiennent les mots-cles /bounds/ et /expired/. L'entree
/bounds/ contient les valeurs par defaut a assigner aux trois valeurs du champ jours
decrit plus haut.
Le champ /expired/ determine combien de temps C News devra tenir compte des
lignes du chier history. Il est necessaire, car les lignes de ce chier ne seront pas
supprimees immediatement lorsque les articles correspondants auront expire : cela
permet de rejeter tout article deja expire qui viendrait a se representer, en provenance
d'un ux tres lent ou pour toute autre raison. Si vous n'avez qu'un fournisseur, vous
pouvez choisir une valeur assez faible. Pour les reseaux UUCP, quinze jours semble
une valeur raisonnable ; a vous de voir en fonction des delais obtenus dans votre cas
particulier.
Voici ci-dessous un exemple de chier explist contenant des intervalles d'expiration
assez courts :
# Conservation des lignes du fichier history pendant quinze jours.
/expired/ x 14 -
# Personne ne conserve un article plus de trois mois.
/bounds/ x 0-1-90 -

# groupes que nous voulons conserver plus longtemps que les autres
comp.os.linux.announce m 10 -
comp.os.linux x 5 -
17.7. Fichiers divers 281

alt.folklore.computers u 10 -
rec.humor.oracle m 10 -
soc.feminism m 10 -

# Archivage des groupes *.sources


comp.sources,alt.sources x 5 @

# d
efauts pour les groupes tech
comp,sci x 7 -

# Suffisant pour un long week-end


misc,talk x 4 -

# supprime le groupe junk tr


es rapidement
junk x 1 -

# les messages de contr^


ole ne sont pas plus int
eressants
control x 1 -

# entr
ee qui s'appliquera 
a tout le reste
all x 2 -

Le processus d'expiration pose plusieurs problemes. Le premier se presente si votre


lecteur de News tient compte du troisieme champ du chier active, qui contient le
numero du premier article de chaque groupe. C News ne met jamais cette valeur a
jour. Si ce champ doit vraiment representer la situation reelle, vous devrez executer un
programme appele updatemiin apres chaque appel a doexpire. (Dans de precedentes
versions, le nom du programme est upact.)
C News ne scrute pas le repertoire du groupe, mais teste simplement dans le -
chier history si l'article doit expirer 10. Si ce chier est endommage ou ne represente
plus exactement la situation pour une raison quelconque, certains articles resteront
eternellement sur votre disque, car C News les aura litteralement oublies 11. Vous
pouvez remedier a la situation gr^ace au script addmissing situe dans le repertoire
/usr/lib/news/bin/maint, qui rajoutera tous les articles absents du chier history, ou
encore la commande mkhistory, qui reconstruira entierement un nouveau chier tout
neuf. N'oubliez pas de passer sous l'utilisateur news auparavant, sinon le chier serait
inaccessible a C News.

17.7 Fichiers divers


Il existe un certain nombre de chiers contr^olant le comportement de C News, mais qui
ne sont pas indispensables a son fonctionnement. Tous resident dans /usr/lib/news,
en voici une liste :
10 La date d'arrivee est enregistree dans le champ du milieu de la ligne d'historique, exprimee en
:
nombre de secondes depuis le premier janvier 1970.
11 Ce cas se produit reellement de temps en temps, sans qu'on puisse trouver d'explication...
:
282 Chapitre 17. C News
newsgroups C'est le compagnon du chier active ; il contient une liste de chaque
groupe connu sur votre systeme, avec une breve description (sur une
ligne) du groupe en question. Il est automatiquement mis a jour
lorsque C News recoit un message de contr^ole checknews.
localgroups Si vous avez cree des groupes locaux et que vous ne voulez pas que
C News se plaigne chaque fois que vous recevez un message check-
news, indiquez leurs noms et descriptions dans ce chier, de la m^eme
maniere que dans le chier newsgroups.
mailpaths Ce chier contient les adresses des moderateurs de chaque groupe
modere. Chaque ligne contient le nom du groupe, suivi de l'adresse
electronique de la personne en question. Les deux champs sont sepa-
res par un caractere de tabulation.
Deux entrees speciales sont fournies par defaut : backbone et inter-
net. Toutes deux indiquent, en notation par bangs, le chemin vers
un site central et celui qui comprend les adresses RFC 822 (utilisa-
teur@machine). Les entrees par defaut sont :
internet backbone

Vous n'aurez pas besoin de modi er l'entree internet si vous utilisez


smail ou sendmail, car ils comprennent l'adressage RFC 822.
L'entree backbone est utilisee chaque fois qu'un utilisateur poste dans
un groupe modere dont le moderateur n'est pas indique explicite-
ment. Si le nom du groupe est alt.machin, et que l'entree back-
bone contient chemin!%s, C News enverra par courrier l'article a
chemin!alt-machin, en esp erant que cette machine sera capable de le
traiter. Pour trouver quel chemin utiliser, demandez aux administra-
teurs du site qui vous fournit les News. En tout dernier ressort, vous
pouvez mettre uunet.uu.net!%s.
distributions Il ne s'agit pas a proprement parler d'un chier de C News, il est
utilise par certains programmes lecteurs et le demon nntpd. Il contient
la liste des distributions reconnues par votre site, et une description
des e ets induits (ou esperes...) Par exemple, celui de (( La biere
virtuelle )) contient ceci :
world partout dans le monde
local Local 
a ce site
nl Hollande uniquement
mugnet MUGNET uniquement, s'il vit encore
fr France uniquement
de Allemagne uniquement
brasseurs Soci
et
e La bi
ere virtuelle seulement
17.8. Les messages de contr^ole 283

Me ez-vous de ces distributions, evitez-les. Lisez ou relisez ce qui est


dit a leur propos, page 272.
log Ce chier contient toutes les traces des activites de C News. Il est
purge regulierement par newsdaily ; les copies des anciennes traces
sont conservees dans log.o, log.oo, etc.
errlog Il contient les enregistrements de tous les messages d'erreurs generes
par C News. Cela ne comprend pas les articles deplaces dans junk. Il
est automatiquement envoye par courrier au newsmaster (usenet par
defaut) par newsdaily s'il n'est pas vide au moment ou cet utilitaire
est mis en route.
Ce chier est remis a zero par newsdaily, et sauvegarde dans errlog.o,
errlog.oo, etc.
batchlog Il contient la trace de tous les travaux de sendbatches ; il n'a que peu
d'inter^et. Il est egalement traite par newsdaily.
watchtime Il s'agit d'un chier vide cree chaque fois que newswatch est execute.

17.8 Les messages de contr^ole


Le protocole de News Usenet comprend une categorie d'articles speciaux qui corres-
pondent en fait a des actions e ectuees par le systeme. On les appelle les messages de
contr^ole. Ils sont reconnaissables par la presence d'un champ Control dans l'en-t^ete,
qui contient le nom de l'operation a realiser. Toutes ces operations sont executees par
des shell-scripts situes dans le repertoire /usr/lib/news/ctl.
La plupart s'e ectueront automatiquement au moment ou l'article sera traite par
C News, sans que personne soit avise. Par defaut, seuls les messages checkgroups
seront passes au newsmaster, mais vous pouvez modi er ce comportement en editant
les scripts.

17.8.1 Le message cancel


C'est le plus connu, il permet a un utilisateur de supprimer un article qu'il a prece-
demment poste. Cette operation supprime physiquement le chier contenant l'article.
Le message cancel est expedie a tous les sites qui recoivent le groupe concerne, qu'ils
aient deja recu l'article ou non ; il peut avoir ete retarde pour une raison quelconque.
Certains systemes permettent aux utilisateurs de supprimer des messages postes par
d'autres personnes ; ils sont a proscrire absolument, c'est un bogue impardonnable.
284 Chapitre 17. C News
17.8.2 Les messages newgroup et rmgroup
Ces messages gerent la creation et la suppression de groupes. Les groupes situes en
dessous des hierarchies (( usuelles )) ne peuvent ^etre crees qu'apres une discussion et
un vote qui ont lieu au niveau mondial. Tous les utilisateurs de Usenet sont concernes.
Les regles s'appliquant a la hierarchie alt sont, en revanche, assez proche de l'anarchie.
Pour plus d'informations, vous devez lire les articles d'information postes reguliere-
ment dans news.announce.newusers et news.announce.newgroups. N'envoyez
jamais de messages de contr^ole newgroup ou rmgroup vous-m^eme, a moins que vous
soyez absolument certain d'en avoir obtenu l'autorisation.

17.8.3 Le message checkgroups


Les messages checkgroups sont envoyes par les administrateurs pour que tous les sites
d'un reseau synchronisent leurs chiers active avec la realite. Par exemple, certains
fournisseurs de service IP peuvent envoyer de tels messages a tous leurs clients uti-
lisant Usenet. Une fois par mois, un checkgroups (( ociel )) concernant toutes les
principales hierarchies mondiales est poste dans comp.announce.newgroups par
son moderateur. Toutefois, il y est place comme un article ordinaire et non pas sous
la forme d'un message de contr^ole. Pour que l'operation de mise a jour ait lieu, sauvez
cet article dans un chier (appelons-le /tmp/maj, par exemple), supprimez tout ce
qui precede le debut du message lui-m^eme, et envoyez-le au shell-script checkgroups
par la commande suivante :

# su news -c "/usr/lib/news/bin/ctl/checkgroups" </tmp/maj

Votre chier newsgroups sera mis a jour, les groupes indiques dans localgroups seront
pris en compte. L'ancien chier sera sauve sous le nom de newsgroups.bac. Notez que
poster un tel message localement fonctionnera rarement, car inews refuse des articles
aussi longs.
Si C News trouve des di erences entre la liste contenue dans le message checkgroups et
le chier active, il generera une serie de commandes qui mettront tout votre systeme
a jour et enverront un rapport par courrier a l'administrateur des News. La sortie
ressemble typiquement a ceci :
From news Sun Jan 30 16:18:11 1994
Date: Sun, 30 Jan 94 16:18 MET
From: news (News Subsystem)
To: usenet
Subject: Problems with your active file

The following newsgroups are not valid and should be removed.


alt.ascii-art
bionet.molbio.gene-org
comp.windows.x.intrisics
17.8. Les messages de contr^ole 285

de.answers

You can do this by executing the commands:


/usr/lib/news/bin/maint/delgroup alt.ascii-art
/usr/lib/news/bin/maint/delgroup bionet.molbio.gene-org
/usr/lib/news/bin/maint/delgroup comp.windows.x.intrisics
/usr/lib/news/bin/maint/delgroup de.answers

The following newsgroups were missing.


comp.binaries.cbm
comp.databases.rdb
comp.os.geos
comp.os.qnx
comp.unix.user-friendly
misc.legal.moderated
news.newsites
soc.culture.scientists
talk.politics.crypto
talk.politics.tibet

Le premier paragraphe indique les groupes non valides que vous devez supprimer ; le
deuxieme vous donne les commandes necessaires pour le faire ; et le troisieme est une
liste des groupes qui n'ont pas ete trouves sur votre site.
Lorsque vous recevez un courrier comme celui-ci de la part de votre systeme de News,
ne le croyez pas aveuglement. En fonction de qui a envoye le message checkgroups, il
peut manquer quelques groupes voire des hierarchies entieres ; aussi vous devez faire
attention a ne pas supprimer des choses qu'il aurait fallu conserver. Si vous notez
dans les groupes manquants, certains que vous aimeriez supporter sur votre site, vous
devrez les rajouter en utilisant le script addgroup. Sauvez la liste de ces groupes
manquants dans un chier, et envoyez-le dans le petit shell-script suivant :
#!/bin/sh
cd /usr/lib/news

while read group; do


if grep -si "^$group[[:space:]].*moderated" newsgroup; then
mod=m
else
mod=y
fi
/usr/lib/news/bin/maint/addgroup $group $mod
done

17.8.4 Les messages sendsys, version et senduuname


Ces trois messages peuvent ^etre utilises pour obtenir la topologie du reseau. Lorsqu'il
les recoit, C News retourne a l'expediteur les informations demandees, par courrier
electronique. Le message sendsys renvoie le chier sys dans son integralite, version une
cha^ne de caracteres indiquant la version du systeme de News utilise, et senduuname
286 Chapitre 17. C News
renvoie la sortie de la commande uuname(1). C News est tres laconique lorsqu'on lui
demande son numero de version ; il se contente de renvoyer un simple (( C )), sans
oritures.
La encore, vous ne devez jamais poster un tel message, sauf si vous ^etes parfaitement
certain qu'il ne sortira pas de votre reseau regional. Les reponses aux messages sendsys
peuvent generer un tra c proprement gigantesque, et mettre beaucoup de sites UUCP
en diculte. N'essayez jamais sur l'Internet.

17.9 C News dans un environnement NFS


Une facon simple de distribuer les News sur un reseau local est de conserver les articles
sur un h^ote central et d'exporter les repertoires concernes par NFS, de sorte que les
programmes lecteurs puissent acceder directement aux messages. L'avantage de cette
methode sur NNTP, c'est que les ressources necessaires pour recuperer et lire les
articles sont tres inferieures. Par contre, NNTP gagne sur tous les tableaux dans un
reseau heterogene ou l'equipement est tres varie, ou si les utilisateurs n'ont pas de
comptes equivalents sur la machine serveur.
Avec un montage NFS, les articles postes sur un h^ote local doivent ^etre envoyes sur
la machine centrale, car l'acces aux chiers administratifs peut donner lieu a des
con its entre systemes, et provoquer des inconsistances dans les donnees. De plus,
vous prefererez sans doute exporter votre repertoire de spoule en lecture seule, ce qui
necessitera obligatoirement un envoi des articles a poster sur le serveur qui aura les
droits d'ecriture.
C News gere cette situation de maniere transparente. Lorsque vous postez un ar-
ticle, votre programme lecteur appelle en principe inews pour injecter le message
dans le systeme de News. Cette commande e ectue un certain nombre de tests sur
l'article, complete l'en-t^ete, et recherche un chier nomme server dans le repertoire
/usr/lib/news. Si ce chier existe et contient le nom d'un h^ote di erent de la machine
locale, inews est invoque sur ce systeme par la commande rsh. Puisque le script inews
utilise certaines commandes et chiers de con guration de C News, il faudra avoir
installe C News sur la machine locale, ou l'avoir monte par NFS depuis le serveur.
Pour que l'appel a rsh fonctionne correctement, chaque utilisateur doit posseder un
compte equivalent sur le systeme serveur, c'est-a-dire un compte ou il peut acceder
par le reseau sans avoir besoin de donner son mot de passe.
Veri ez bien que le nom d'h^ote donne dans le chier server correspond lettre pour
lettre a la sortie de la commande hostname(1) sur la machine serveur, sinon C News
bouclera a l'in ni en essayant de delivrer l'article.
17.10. Outils et travaux de maintenance 287

17.10 Outils et travaux de maintenance


Malgre la complexite de C News, la vie d'un administrateur de News n'est pas si
dicile qu'on pourrait le penser car ce systeme o re une grande variete d'utilitaires
de maintenance. Certains sont destines a ^etre appeles a intervalles reguliers par cron,
comme par exemple newsdaily. L'emploi de ces scripts reduit considerablement le
temps necessaire a l'administration de votre systeme C News.
Sauf exception, toutes ces commandes se trouvent dans /usr/lib/news/bin/maint.
Vous devez absolument passer utilisateur news avant de les utiliser. Les employer
depuis tout autre compte peut rendre certains chiers inaccessibles a C News.

newsdaily Comme son nom l'indique 12 , vous devez lancer cette commande une
fois par jour. C'est un script tres important qui permet de conser-
ver des chiers de trace susamment courts, veri er toute anomalie
comme de mauvais lots dans les repertoires de depart et d'arrivee,
les tentatives d'envoi vers des groupes inconnus ou moderes, etc. Les
messages d'erreur sont envoyes dans la bo^te aux lettres de l'admi-
nistrateur newsmaster.
newswatch Vous devrez lancer ce script regulierement pour veri er l'etat du sys-
teme de News, toutes les heures par exemple. Il detecte les problemes
qui peuvent avoir un e et immediat sur le fonctionnement du sys-
teme, et envoie un rapport a newsmaster. Parmi les choses testees,
citons les chiers de verrouillage oublies, l'arrivee de lots inattendus,
et l'espace disque disponible.
addgroup Rajoute un groupe a votre systeme, localement. La commande s'uti-
lise ainsi :
addgroup groupe y|n|m|=vrai-groupe

Le second argument a la m^eme signi cation que le drapeau corres-


pondant dans le chier active, c'est-a-dire que tout le monde peut
poster (y), personne ne peut poster (n), que c'est un groupe modere
(m), ou qu'il s'agit d'un alias pour un autre groupe (=vrai-groupe).
Vous utiliserez aussi cette commande lorsque le premier article d'un
tout nouveau groupe arrive avant le message de contr^ole destine a
creer le groupe en question.
delgroup Permet de supprimer un groupe, localement. Sa syntaxe est simple :
delgroup groupe

12 Dans une autre langue...


:
288 Chapitre 17. C News
Vous devrez supprimer ensuite tous les articles qui resteront dans le
repertoire concerne, soit manuellement, soit en attendant tranquille-
ment que la procedure d'expiration le fasse toute seule.
addmissing Rajoute les articles absents dans le chier history. Lancez ce script
lorsque vous constatez que certains messages semblent rester inde -
niment, sans jamais expirer.
newsboot Ce script doit ^etre execute a chaque demarrage de la machine. Il net-
toie tout chier de verrouillage pouvant provenir de processus tues
lors de l'arr^et du systeme, et referme puis extrait tout lot d'articles
laisse par les connexions NNTP qui se sont terminees au m^eme mo-
ment.
newsrunning Celui-la se trouve dans le repertoire /usr/lib/news/bin/input et peut
^etre utilise pour invalider l'extraction des lots de News qui arrivent,
par exemple pendant les heures de travail. Vous pouvez arr^eter ce
traitement par :
/usr/lib/news/bin/input/newsrunning off

Il sera remis en service en mettant on au lieu de o .


289

Chapitre 18
Description du protocole
NNTP
Pour l'echange de News Usenet, le protocole NNTP constitue une approche radicale-
ment di erente de C News. NNTP signi e Network News Transfer Protocol, protocole
de transfert de News par reseau. Il ne s'agit pas d'un programme particulier, mais
d'un standard Internet 1 . Il est base sur une connexion (generalement TCP) entre un
client situe a n'importe quel endroit du reseau et un serveur fonctionnant sur un h^ote
qui centralise le stockage des articles. La connexion permet au client et au serveur
de negocier le transfert des articles de maniere interactive, sans pratiquement aucun
delai, ce qui contribue a limiter le nombre de messages dupliques. Allie a la grande
vitesse obtenue sur l'Internet, NNTP surpasse largement tout ce que l'on pouvait
obtenir auparavant par des reseaux UUCP. Alors qu'il y a encore quelques annees,
il n'etait pas rare qu'un article mette une quinzaine de jours pour arriver a l'autre
(( bout )) de Usenet, actuellement il ne faut plus, dans le pire des cas, qu'un jour ou
deux ; et a peine quelques minutes si l'on ne sort pas d'Internet.
Di erentes commandes permettent aux clients de recuperer, envoyer et poster des
articles. La di erence entre envoyer et poster est simple : un article poste peut avoir
un en-t^ete incomplet que le serveur achevera de remplir, alors qu'un article envoye est
un (( produit ni )) 2 . La recuperation des articles peut ^etre employee pour transferer
des News aussi bien que pour la lecture par des interfaces conviviales, les Lecteurs
de News. NNTP est le protocole ideal pour o rir un acces Usenet a de nombreuses
machines sur un reseau local, sans passer par toutes les complications induites par un
montage NFS.
Il permet aussi des methodes actives ou passives pour le transfert des articles, appelees
1 De ni dans le document RFC 977.
:
2 Lorsque l'on poste un article par NNTP, le serveur rajoute toujours au moins un champ dans
:
l'en-t^ete : Nntp-Posting-Host, qui contient le nom de la machine sur laquelle se trouve ce client.
290 Chapitre 18. Description du protocole NNTP
le (( pushing )) et le (( pulling )). Le pushing est pratiquement le m^eme que le proto-
cole ihave/sendme de C News : le client o re un article au serveur par la commande
(( IHAVE < Message-ID )), et ce dernier retourne un code de r
> eponse indiquant s'il
possede deja cet article ou s'il desire qu'il lui soit envoye. Dans ce dernier cas, le client
envoie l'article, termine par un point sur une ligne separee.
L'inconvenient de cette methode est la charge qu'elle induit sur le systeme serveur,
car il doit rechercher chaque article dans sa base de donnees d'historique.
Dans la technique opposee, le pulling, le client demande une liste de tous les articles
(disponibles) dans un groupe donne, arrives sur le serveur apres une certaine date.
Cette requ^ete se fait par la commande NEWNEWS. A partir de la liste de Message-ID
recus, le client selectionne ceux qu'il ne possede pas encore, en les reclamant par la
commande ARTICLE, un par un.
Cette methode presente l'inconvenient de demander au serveur un contr^ole tres serre
des groupes et distributions qu'il permet de transferer, pour chaque client. Par exemple,
il doit s'assurer qu'aucune information con dentielle en provenance de groupes locaux
ne peut ^etre envoyee a des machines non autorisees.
NNTP propose egalement un certain nombre de commandes utilitaires destinees aux
programmes lecteurs, leur permettant de recuperer separement l'en-t^ete et le corps des
articles, ou m^eme uniquement certaines lignes de ces en-t^etes. Ainsi, ces programmes
peuvent se trouver sur n'importe quelle machine du reseau (de preference local), et
acceder facilement a tous les articles qui restent centralises sur un seul h^ote, ce qui
est une excellente alternative au montage des repertoires de News par NFS, comme
il est decrit dans le chapitre 17.
NNTP sou re d'un petit defaut : quelqu'un d'experimente, connaissant bien le proto-
cole, peut inserer des articles portant de fausses informations (au nom de quelqu'un
d'autre, par exemple) 3 . Il existe une extension de NNTP permettant au serveur de
demander une authenti cation de l'utilisateur avant d'executer certaines commandes.
Il circule un certain nombre d'implementations de NNTP. Le demon NNTP, plus
connu sous l'appellation implementation de reference, est la plus celebre. A l'origine,
elle fut realisee par Stan Barber et Phil Lapsley pour illustrer les details des speci -
cations RFC 977. Nous allons decrire sa version la plus recente, nntpd-1.5.11. Vous
pouvez soit vous procurer le code source original et la compiler vous-m^eme, soit utili-
ser le nntpd contenu dans le paquetage net-std prepare par Fred van Kempen. Aucune
version binaire pre-compilee n'est fournie en raison des diverses con gurations speci-
ques au site qui doivent ^etre integrees au programme.
L'ensemble nntpd consiste en un serveur et deux clients realisant du pulling et du
pushing, ainsi qu'un remplacement de la commande inews. Ils sont prevus pour un
environnement Bnews, mais avec quelques petites modi cations, fonctionneront par-
faitement avec C News. Toutefois, si vous comptez utiliser NNTP pour faire plus
qu'o rir un acces aux lecteurs de News sur votre serveur, l'implementation de refe-
3 Le m^eme probleme se pose avec SMTP, le protocole de transfert du courrier electronique.
:
18.1. Installation du serveur NNTP 291

rence n'est plus vraiment une option. Par consequent, nous ne parlerons que du demon
NNTP contenu dans le paquetage nntpd et nous laisserons les programmes clients de
c^ote.
Il existe egalement un ensemble appele (( InterNet News )), ou INN, realise par Rich
Salz. Il o re a la fois un transport NNTP et UUCP, et est preferable pour les sites
importants. En matiere de News par NNTP, il est sans comparaison avec nntpd, c'est
vraiment lui qu'il faut choisir. Si vous voulez installer INN, consultez la documentation
fournie avec son code source, ainsi que le document (( INN FAQ )) poste regulierement
dans le groupe news.software.b.

18.1 Installation du serveur NNTP


Le serveur NNTP s'appelle nntpd, et peut ^etre compile de deux facons, en fonction
de la charge de la machine supportant les News. Il n'y a aucune version binaire
disponible, car la con guration speci que au site doit ^etre incluse dans l'executable.
Tout se con gure par des macros de nies dans le chier common/conf.h.
Soit vous con gurez nntpd en tant que serveur autonome qui sera lance au demarrage
du systeme depuis le script rc.inet2, soit vous le con gurez comme demon qui sera
appele par inetd. Dans ce dernier cas, vous devrez, bien entendu, avoir une entree
comme celle-ci dans /etc/inetd.conf :
nntp stream tcp nowait news /usr/etc/in.nntpd nntpd

Si vous decidez de l'employer en serveur autonome, veri ez que toute ligne comme
celle-ci dessus soit absente ou commentee dans inetd.conf. Dans un cas comme dans
l'autre, le chier /etc/services doit contenir la ligne :
nntp 119/tcp readnews untp # Network News Transfer Protocol

A n de gerer les articles qui arrivent, nntpd a besoin d'un repertoire temporaire .tmp
dans votre spoule de News. Vous devrez le creer a l'aide des commandes suivantes :
# mkdir /var/spool/news/.tmp
# chown news.news /var/spool/news/.tmp

18.2 Restreindre les acces NNTP


L'acces aux ressources NNTP est gouverne par le chier nntp access situe dans le re-
pertoire /usr/lib/news. Les lignes decrivent les droits accordes aux machines distantes,
avec le format suivant :
site read|xfer|both|no post|no [!groupes interdits]
292 Chapitre 18. Description du protocole NNTP
Si un client se connecte au port NNTP, nntpd va tenter d'obtenir son nom pleinement
quali e a partir de son adresse IP par une recherche inverse. Le nom et l'adresse de
ce client sont compares avec les champs site de chaque entree, dans l'ordre ou elles
appara^ssent dans le chier. Si une entree correspond exactement, elle s'applique ; si
elle ne correspond que partiellement, elle s'appliquera s'il n'y a pas, plus loin, une
autre entree correspondant mieux. Le champ site peut ^etre speci e sous l'une des
formes suivantes :
nom de machine
C'est le nom pleinement quali e d'un h^ote. S'il est identique au nom
canonique de la machine connectee, l'entree s'applique, et toutes les
suivantes sont ignorees.
adresse IP Il s'agit d'une adresse IP en notation sur 4 octets. Si l'adresse du
client correspond, l'entree s'applique et les suivantes sont ignorees.
nom de domaine
C'est un nom de domaine, indique sous la forme *.domaine. Si le
domaine auquel appartient l'h^ote connecte correspond, l'entree s'ap-
plique.
nom de r
eseau
Il s'agit du nom d'un reseau tel que speci e dans /etc/networks. Si
la partie reseau de l'adresse IP de la machine connectee correspond
a l'adresse reseau associee a ce nom, l'entree s'applique.
Default La cha^ne default correspond a tout client.
Les entrees comportant une speci cation de site plus generale doivent appara^tre en
premier, car toute correspondance eventuelle pourra ainsi ^etre remplacee par une
suivante, plus exacte.
Le deuxieme et le troisieme champ decrivent les droits d'acces autorises au client.
Le deuxieme de nit les permissions de lecture (read), et de transfert par pushing
(xfer). La valeur both valide les deux a la fois ; alors que no interdit tout acces. Le
troisieme champ autorise le client a poster des articles, c'est-a-dire a delivrer des
messages comportant des en-t^etes incomplets qui seront completes par le serveur. Si
le deuxieme champ contient le mot cle no, le troisieme sera ignore.
Le quatrieme champ est facultatif et contient une liste de groupes, separes par des
virgules, auxquels le client n'aura pas le droit d'acceder.
Voici ci-dessous un exemple de chier nntp access :
#
# par defaut, tout le monde peut transf
erer des News, mais
# ni lire ni poster:
default xfer no
18.3. Authenti cation NNTP 293

#
# la machine public.bibine.com offre un acc
es public par modem,
# nous leur autorisons de lire et de poster dans tous les groupes
# except
e les groupes local.*
public.bibine.com read post !local
#
# tous les autres h^
otes chez les brasseurs peuvent lire et poster
*.bibine.com read post

18.3 Authenti cation NNTP


Lorsqu'il totalise les droits d'acces de nis par xfer ou read dans le chier nntp acces,
le programme nntpd requiert une authenti cation de la part du client. Par exemple,
lorsqu'il est speci e Xfer ou XFER, il ne laissera pas le client transferer d'articles tant
qu'il n'aura pas passe la procedure d'authenti cation avec succes.
Cette procedure est implementee par l'intermediaire d'une nouvelle commande NNTP
appelee AUTHINFO. Par cette commande, le client transmet un nom d'utilisateur
et un mot de passe au serveur NNTP. Le demon nntpd les validera en les comparant
avec les donnees du chier /etc/passwd, et en veri ant que cet utilisateur appartient
bien au groupe nntp.
L'implementation courante de l'authenti cation NNTP n'est qu'experimentale est n'a
par consequent pas ete faite de maniere tres portable. En particulier, elle ne fonctionne
qu'avec des chiers /etc/passwd traditionnels ; les mots de passe shadow ne sont pas
reconnus.

18.4 Integration de nntpd dans C News


Lorsqu'il recoit un article, nntpd doit le delivrer au systeme de News. S'il est arrive par
une commande IHAVE, l'article sera passe a rnews ; s'il s'agit de la commande POST,
il sera transmis a inews. Au lieu d'invoquer rnews, vous pouvez aussi con gurer le
programme (a la compilation) pour qu'il cree des lots avec les articles entrants dans
/var/spool/news/in.coming, qui seront traites ensuite par relaynews.
Pour que le protocole ihave/sendme fonctionne correctement, nntpd doit avoir acces
au chier history. Vous devez donc vous assurer lors de la compilation que le chemin
d'acces correct est bien indique, et que C News et nntpd l'attendent sous le m^eme
format. C News utilise les fonctions de hachage de dbm pour y acceder ; mais il existe
plusieurs implementations incompatibles entre elles de cette bibliotheque. Si C News
a ete compile avec une version di erente de celle se trouvant dans votre bibliotheque
C standard, il vous faudra recompiler nntpd dans le m^eme environnement.
Le sympt^ome typique lorsque nntpd et C News ne sont pas d'accord sur le format de
la base de donnees se presente sous forme de messages d'erreurs dans les traces du
systeme, indiquant que nntpd n'a pas pu l'ouvrir correctement, ou que des messages
294 Chapitre 18. Description du protocole NNTP
dupliques arrivent par NNTP. Un bon test consiste a prendre un message de votre
spoule, vous connecter par telnet sur le port nntp, et le proposer comme nous le
montrons dans l'exemple ci-dessous. Bien s^ur, vous devrez remplacer msg@id par
< >

le Message-ID de l'article que vous voulez renvoyer a nntpd.


$ telnet localhost nntp
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
201 gueuze NNTP[auth] server version 1.5.11t (16 November 1991) ready at Sun
Feb 6 16:02:32 1194 (no posting)
IHAVE <msg@id>

435 Got it.


QUIT

Cette transaction montre une reaction correcte de nntpd ; le message (( Got it )) vous
indique qu'il possede deja l'article en question. Si a la place vous obtenez le message
(( 335 Ok )), c'est que la recherche dans la base de donn ees a echoue pour une raison
quelconque. Terminez la conversation en tapant Ctrl-D. Vous pourrez rechercher ce
qui ne va pas en inspectant les chiers de trace ; nntpd enregistre ces messages sous
la (( facilite )) daemon de syslog. Une bibliotheque dbm incompatible se manifeste
elle-m^eme en indiquant que la fonction dbminit a echoue.
295

Chapitre 19
Les lecteurs de News
Un (( lecteur de News )) est un programme que les utilisateurs appellent a n de lire,
sauvegarder, et creer des articles de News Usenet. Il en existe beaucoup, la plupart se
compilent parfaitement sous Linux ou ont fait l'objet d'un portage. Ici, nous decrirons
la con guration de base de trois d'entre eux qui comptent parmi les plus populaires :
tin, trn et nn.
Le lecteur le plus ecace est celui-ci :
$ find /var/spool/news -name '[0-9]*' -exec cat {} \; | more

C'est ainsi que les vrais mordus d'UNIX lisent leurs News.
Cela dit, la plupart des autres lecteurs sont bien plus sophistiques. Ils o rent generale-
ment une interface plein ecran comportant plusieurs niveaux d'achage pour scruter
les groupes que l'utilisateur frequente, un plan d'ensemble de tous les articles dans
chaque groupe, etc.
Au niveau groupe, pratiquement tous achent une liste d'articles, montrant leurs
sujets et leurs auteurs. Dans les forums les plus importants, il est souvent dicile de
suivre la trace des articles relatifs les uns aux autres, bien qu'il soit possible d'identi er
des reponses a de precedents messages.
Une reponse reprend en general le sujet original, en y rajoutant (( Re: )) au debut. De
plus, le Message-ID de l'article original appara^t dans la ligne References de l'en-
t^ete. Si l'on trie les messages selon ces deux criteres, on aboutit a de petits ensembles
(en fait, arborescences) d'articles, que l'on appelle alors ls de discussions 1 . L'une des
t^aches les plus diciles lors de l'elaboration d'un lecteur de News consiste a trouver
une methode ecace pour ce classement, car le temps requis est proportionnel au
carre du nombre d'articles a trier.
1 Dans les pays francophones, on utilise indi eremment les expressions (( l de discussion )), (( l ))
:
et (( discussion )) pour ce que les anglophones appellent un thread.
296 Chapitre 19. Les lecteurs de News
Nous n'entrerons pas plus dans le detail des interfaces utilisateur. Tous les lecteurs
disponibles sous Linux sont munis d'excellents manuels et de bonnes fonctions d'aide,
vous devriez pouvoir apprendre rapidement a les utiliser.
Nous allons nous concentrer sur les t^aches administratives permettant de faire fonc-
tionner ces programmes correctement ; ce ne sera bien s^ur qu'un tres bref apercu, vous
devrez ensuite vous referer a la documentation fournie avec le lecteur que vous aurez
choisi.

19.1 Con guration de tin


Tin est le lecteur le plus simple et universel concernant les ls de discussion. Il est
l'uvre de Iain Lea et est tres proche d'un ancien programme nomme tass (ecrit par
Rich Skrenta). Il commence le classement des articles lorsque l'utilisateur selectionne
un groupe, et il est tres rapide (sauf si cette operation a lieu dans certaines conditions
sous NNTP).
Sur une machine 486DX50, il lui faut environ 30 secondes pour trier 1 000 articles, s'il
les lit depuis le disque. Par NNTP sur un serveur charge, ce temps peut aller jusqu'a
plus de 5 minutes 2 . Vous pouvez aller encore plus vite en mettant regulierement a
jour vos chiers d'index par l'option -u, ou en appelant le programme avec l'option
-U.
En principe, tin ecrit ses bases de donnees de discussions dans le repertoire utilisateur,
dans .tin/index. Cela peut prendre trop de ressources pour votre con guration, aussi
vous devrez en conserver une seule copie dans un endroit central. Il vous faudra alors
passer tin setuid news, ou quelque autre compte non privilegie 3. Dans ce cas, le
programme ecrira toutes ses donnees dans le chier /var/spool/news/.index. Pour
tout acces chier ou appel au shell, il remettra son numero d'identi cation utilisateur
e ectif a celui du compte depuis lequel il a ete appele 4 .
Une meilleure solution consiste a installer le demon d'indexation tind qui met a jour
regulierement les chiers d'index. Il n'est pas fourni dans les distributions de Linux,
vous devrez donc le compiler vous-m^eme. Si vous ^etes sur un reseau comportant un
serveur de News central, vous pouvez aussi installer tind sur le serveur, et tous les
clients recupereront leurs chiers d'index par NNTP. Cela necessite une extension a ce
protocole ; les patches implementant cette modi cation dans nntpd sont fournis dans
les sources de tin 5 .
2 Mais ce cas n'arrive jamais, car les serveurs de News modernes comme INN sont prevus pour
:
ce type d'application, et si tout est proprement con gure, il n'y a pas de di erence notable entre une
lecture directe sur disque et par NNTP.
3 N'utilisez pas le compte nobody pour ca. Par principe, aucun chier, commande, ou autres ne
:
doit ^etre associe a cet utilisateur.
4 C'est la raison pour laquelle vous obtenez des messages d'erreurs lorsque vous l'appelez en tant
:
que root. Mais quoi qu'il en soit, vous ne devez jamais prendre la mauvaise habitude de travailler
sous le compte root, et en aucun cas l'utiliser pour poster sur Usenet.
5 Mais la meilleure solution dans ce cas est de ne pas employer C News mais INN, et d'oublier
:
19.2. Con guration de trn 297

La version de tin incluse dans certaines distributions de Linux est compilee sans aucun
support NNTP, mais cette erreur est maintenant corrigee dans la plupart d'entre elles.
Lorsqu'on l'appelle avec l'option -r, ou encore sous le nom de rtin, le programme tente
de se connecter au serveur NNTP speci e dans le chier /etc/nntpserver ou dans la
variable d'environnement NNTPSERVER. Le chier contient simplement une seule ligne,
indiquant le nom de la machine a contacter.

19.2 Con guration de trn


C'est aussi le successeur d'un ancien lecteur, qui s'appelait rn (ce qui signi e read
news, (( lecture de news ))). La lettre (( t )) au debut de son nom, est la pour (( threaded )),
petit terme qui se traduit chez nous par (( gerant les ls de discussions )). L'auteur de
trn s'appelle Wayne Davidson.
Contrairement a tin, trn ne comporte aucune routine pour generer ses bases de don-
nees. Il utilise des bases preparees a l'avance par un programme appele mthreads qui
doit ^etre execute a intervalles reguliers par cron.
Si ce programme ne tourne pas, vous pourrez bien s^ur acceder quand m^eme aux
articles, mais comme ils ne seront pas tries par discussions, vous aurez dans le menu
de selection des listes enormes de sujets tous semblables comme (( Ou se trouve la
documentation sur Linux ? )) au lieu de ne voir appara^tre qu'un seul l que vous
pourriez sauter en une fraction de seconde.
Pour generer les index, mthreads est appele en indiquant sur sa ligne de commandes,
la liste des groupes que vous voulez voir indexes. Cette liste doit ^etre speci ee selon
le m^eme format que le chier sys :
$ mthreads comp,rec,!rec.games.go

La commande ci-dessus validera les ls de discussion pour tous les groupes comp et
rec, sauf rec.games.go (les gens jouant a ce jeu n'ont pas grand-chose a dire). Apres
cela, il sura de l'appeler sans aucune option pour qu'il traite tous les nouveaux
articles arrives. Vous pouvez choisir d'indexer tous les groupes connus dans votre
chier active en appelant mthreads avec une liste contenant simplement le mot all.
Si vous recevez les News pendant la nuit, vous pourrez executer mthreads tous les
matins, ou plus souvent si vous en avez besoin. Les sites qui ont un tra c important
peuvent utiliser ce programme en mode demon. Lorsqu'il est lance au demarrage du
systeme avec l'option -d, il s'installe en arriere-plan, et teste toutes les 10 minutes si
de nouveaux articles sont arrives, et les traitera le cas echeant. Pour l'utiliser dans ce
mode, mettez cette ligne dans votre script rc.news :

ces chiers d'index au pro t de la methode des .overview, beaucoup plus elegante et ecace. Vous
en trouverez une description dans les sources du serveur INN (entre autres), et sans doute dans une
prochaine edition de ce livre...
298 Chapitre 19. Les lecteurs de News
/usr/local/bin/rn/mthreads -deav

L'option -a valide l'indexation automatique de tous les nouveaux groupes lorsqu'ils


sont crees; -v met en service les messages de trace, qui s'enregistreront dans le chier
mt.log, situe dans le repertoire ou vous avez installe trn.
Les vieux articles qui ne sont plus disponibles doivent ^etre regulierement supprimes
des chiers d'index. Par defaut, seuls les articles dont le numero est inferieur a celui du
premier qui est accessible sera supprime 6 . Les articles dont le numero est superieur a
ce nombre mais qui ont malgre tout expire (car le plus ancien s'etait sans doute vu at-
tribuer une tres longue vie par le champ Expires de l'en-t^ete), peuvent ^etre supprimes
en passant l'option -e a mthreads ; elle valide un mode d'expiration plus (( intelligent )).
Lorsqu'il fonctionne en demon, cette option le fera passer automatiquement dans ce
mode une fois par jour, peu apres minuit.

19.3 Con guration de nn


Le programme nn, ecrit par Kim F. Storm, se targue d'^etre un lecteur de News dont
le but essentiel est de ne pas lire les News. Son nom signi e (( No News )) (pas de
nouvelles), et sa devise est : (( Pas de nouvelles, bonnes nouvelles. ))
Pour arriver a ce but si ambitieux, nn est fourni avec tout un assortiment d'outils
de maintenance qui permettent non seulement la generation des ls de discussions,
mais egalement de realiser des tests de coherence de ces bases de donnees, des sta-
tistiques, des restrictions d'acces, etc. Il y a aussi un programme d'administration
nomme nnadmin, qui o re toutes ces operations dans un mode interactif. Il est tres
simple d'emploi, aussi nous ne nous etendrons pas plus sur ces aspects du logiciel et
passerons de suite a la generation des chiers d'index.
Le gestionnaire des bases de donnees de discussions de nn s'appelle nnmaster. Il fonc-
tionne normalement en demon, lance depuis le script rc.news ou rc.inet2 au demarrage
du systeme, de cette facon :
/usr/local/lib/nn/nnmaster -l -r -C

Cette commande valide les ls de discussions pour tous les groupes presents dans
votre chier active.
Vous pouvez aussi ne pas le faire fonctionner en demon, mais l'appeler regulierement
par cron, en lui passant une liste de groupes a traiter. Cette liste ressemble beaucoup
a la liste de souscription du chier sys, mais elle utilise des espaces a la place des
virgules. Au lieu du groupe symbolique all, c'est un argument vide comme "" qui
doit ^etre utilise pour indiquer tous les groupes. Voici un exemple d'appel :

6 C news ne met pas a jour cette valeur ; vous devez utiliser la commande updatemin pour le
:
faire. Consultez dans le chapitre 17, la page 275.
19.3. Con guration de nn 299

# /usr/local/lib/nn/nnmaster !rec.games.go rec comp

Notez que l'ordre est signi catif. La speci cation de groupe la plus a gauche qui
correspond, gagnera toujours. Donc, si nous avions mis !rec.games.go apres rec, tous
les articles de ce groupe auraient ete quand m^eme traites.
Le lecteur nn propose plusieurs methodes pour supprimer de ses index les articles
expires. La premiere consiste a mettre a jour la base en scrutant les repertoires conte-
nant les articles, et a supprimer les entrees correspondant a des messages qui ne sont
plus disponibles. C'est le mode operatoire par defaut, obtenu en appelant nnmaster
avec l'option -E. Elle est assez rapide, sauf par NNTP.
La deuxieme methode fonctionne exactement comme l'expiration par defaut de mthreads,
en ce sens qu'elle ne supprime que les entrees qui se referent a des articles dont le
numero est inferieur a celui du premier article dans le chier active. On la valide par
l'option -e.
En n, une troisieme strategie est possible, qui reconstruit entierement une nouvelle
base, en scrutant tous les articles. Elle peut ^etre mise en service par l'option -E3.
La liste des groupes a expirer est donnee de la m^eme facon par l'option -F. Toutefois,
si nnmaster fonctionne en mode demon, vous devez le tuer (par l'option -k) avant
que l'expiration ne se fasse, puis le relancer ; par consequent, la commande correcte
pour l'expiration de tous les groupes par la premiere methode sera :
# nnmaster -kF ""
# nnmaster -lrC

Il y a encore beaucoup d'autres options qui permettent d'ajuster precisement le com-


portement de nn. Si vous desirez supprimer les articles defectueux ou realiser des
compilations, resumes, ou autres, consultez la page de manuel de nnmaster.
Ce programme nnmaster necessite un chier nomme GROUPS, situe dans le repertoire
/usr/local/lib/nn. S'il n'existe pas, il sera automatiquement cree. Il contient pour
chaque groupe, une ligne commencant par le nom de ce forum, suivi eventuellement
par une date, et des drapeaux. Vous pouvez editer ces drapeaux pour valider un
comportement particulier sur le groupe en question, mais vous ne devez pas changer
l'ordre dans lequel ces groupes apparaissent dans le chier 7 . La description de ces
drapeaux se trouve dans la page de manuel de nnmaster.

7 Car leur ordre doit correspondre a celui des entrees du chier binaire MASTER.
:
300 Chapitre 19. Les lecteurs de News
301

Annexe A
C^able port parallele pour
PLIP
Pour realiser un c^able reliant les ports imprimante parallele de deux PC (c^able Null-
Printer), vous devez vous procurer deux connecteurs m^ales 25 broches (appeles DB-
25) et du c^able comportant au moins 11 conducteurs. La longueur maximale possible
est d'environ 15 metres.
Si vous regardez attentivement un des connecteurs, vous devriez pouvoir lire des
numeros (prenez une loupe le cas echeant) a la base de chaque broche. Vu du c^ote
soudures, la premiere broche en haut a droite porte le numero 1, et la derniere en bas
a gauche le numero 25. Les connexions a realiser seront les suivantes :
D0 2 () 15 ERREUR
D1 3 () 13 S
ELECTION
D2 4 () 12 PLUS de PAPIER
D3 5 () 10 ACQUITTEMENT
D4 6 () 11 OCCUP
EE
MASSE 25 () 25 MASSE
ERREUR 15 () 2 D0
S
ELECTION 13 () 3 D1
PLUS de PAPIER 12 () 4 D2
ACQUITTEMENT 10 () 5 D3
OCCUPEE 11 () 6 D4

Toutes les autres broches ne sont pas utilisees. S'il s'agit d'un c^able blinde, le blindage
doit ^etre soude sur le bo^tier metallique de l'un des connecteurs, et un seul.
302 Annexe A. C^able port parallele pour PLIP
303

Annexe B
Exemples de chiers de
con guration pour smail
Cette section donne des exemples de chiers de con guration adaptes a un site UUCP
isole, connecte a un reseau local. Ils sont bases sur les exemples fournis dans la distribu-
tion source de smail-3.1.28. Bien que nous ayons tente d'expliquer tres succinctement
comment ces chiers fonctionnent, nous devons vous prevenir que la lecture du manuel
de smail(8) est indispensable ; vous y trouverez tout le detail. Une fois que vous aurez
compris le principe et l'organisation de ces chiers, ce manuel vous para^tra bien plus
clair.
Le premier chier que nous vous presentons, routers, decrit un ensemble de routeurs
pour smail. Lorsqu'il doit delivrer un message a une adresse donnee, le programme
passe cette adresse successivement a tous les routeurs jusqu'a en trouver un qui cor-
responde. Correspondre signi e dans ce cas que le routeur trouve l'h^ote de destination
dans sa base de donnees, que ce soit le chier paths, /etc/hosts, ou tout autre meca-
nisme de resolution qu'il sait utiliser.
Les entrees des chiers de con guration de smail commencent toujours par un nom
unique identi ant routeur, transport et directeur. Ils sont suivis par une liste d'attri-
buts qui de nissent son comportement. Cette liste consiste en un ensemble d'attributs
globaux, comme le pilote utilise, et d'attributs prives qui ne sont compris que par ce
pilote particulier. Les attributs sont separes par des virgules, alors que les ensembles
globaux et prives sont separes les uns des autres par le caractere (( : )).
A n de clari er ces distinctions, considerons que vous desirez maintenir deux chiers
pathalias separes: l'un contenant les informations de routage pour votre domaine,
et l'autre des informations de routage generales, probablement generees a partir des
cartes UUCP. Avec smail, vous pouvez alors speci er deux routeurs dans le chier
routers, tous deux utilisant le pilote pathalias qui recherchera les noms dans une base
304 Annexe B. Exemples de chiers de con guration pour smail
de donnees pathalias, et on lui donnera le nom du chier dans un attribut prive :
#
# base de donnees pathalias pour routage dans le domaine
domaine_paths:
driver=pathalias, # cherche l'h^
ote dans un fichier paths
transport=uux; # si trouv
e, delivrer par UUCP

file=paths/domaine, # le fichier est /usr/lib/smail/paths/domaine


proto=lsearch, # il n'est pas tri
e (recherche lin
eaire)
optional, # ignorer si le fichier n'existe pas
required=bibine.com, # ne rechercher que les h^
otes de *.bibine.com

#
# base de donn
ees pathalias pour routage hors de notre domaine
monde_paths:
driver=pathalias, # cherche l'h^
ote dans un fichier paths
transport=uux; # si trouv
e, delivrer par UUCP

file=paths/monde, # le fichier est /usr/lib/smail/paths/monde


proto=bsearch, # il est tri
e par sort(1)
optional, # ignorer si le fichier n'existe pas
-required, # pas de domaines requis
domain=uucp, # supprime extension ".uucp" avant recherche

Le second attribut global donne dans chacune des deux entrees routers ci-dessus de-
nissent le transport qu'il faudra utiliser lorsque ce routeur trouvera l'adresse. Dans
notre cas, le message sera delivre par le transport uux. Ces transports sont de nis
dans le chier transports, qui est decrit un peu plus loin.
Vous pouvez ajuster avec precision par quel transport un message doit ^etre delivre si
vous speci ez un chier de methodes a la place de l'attribut transports. Les chiers
de methodes o rent une base de correspondance entre des noms de machines et des
transports. Nous ne les traiterons pas dans ce guide.
Le chier routers qui va suivre de nit des routeurs pour un reseau local qui interroge
la bibliotheque resolver. Sur un site Internet, il faudra en utiliser un autre, sachant
gerer les enregistrements MX du DNS. Par consequent, vous devrez supprimer les
commentaires devant le routeur inet bind qui utilise le pilote BIND integre a smail.
Dans un environnement mixte UUCP et TCP/IP, vous pouvez rencontrer des pro-
blemes avec des machines qui sont declarees dans votre chier /etc/hosts, avec les-
quelles vous avez occasionnellement des connexions SLIP ou PPP. Or, vous voudrez
sans doute que le courrier pour ces sites passe quand m^eme par UUCP. Pour eviter
que le pilote inet hosts ne reconnaisse ces h^otes, vous devrez les declarer dans le chier
paths/force. Il s'agit d'une autre base de donnees de type pathalias qui est consultee
avant que smail n'interroge le resolver.
# Un exemple de fichier /usr/lib/smail/routers
#
305

# force - force le transport par UUCP pour certaines machines,


# m^
eme si elles figurent dans votre /etc/hosts.
force:
driver=pathalias, # cherche l'h^
ote dans un fichier paths
transport=uux; # si trouv
e, delivrer par UUCP

file=paths/force, # le fichier est /usr/lib/smail/paths/force


optional, # ignorer si le fichier n'existe pas
proto=lsearch, # il n'est pas tri
e (recherche lin
eaire)
-required, # pas de domaines requis
domain=uucp, # supprime extension ".uucp" avant recherche

# inet_addrs - pour les domaines num


eriques, c'est-
a-dire contenant
# des adresses IP, comme dans dugenou@[172.16.2.1]
inet_addrs:
driver=gethostbyaddr, # pilote pour domaines IP num
eriques
transport=smtp; # d
elivrer par SMTP sur TCP/IP

fail_if_error, # e
choue si adresse mal form
ee
check_for_local, # d
elivrer directement si h^
ote = nous-m^
emes

# inet_hosts - recherche des noms par gethostbyname(3N).


# Commentez cette partie si vous voulez utiliser la version
# BIND 
a la place, pour la gestion des MX du DNS.
inet_hosts:
driver=gethostbyname, # utilise la fonction biblioth
eque
transport=smtp; # d
elivre par d
efaut par SMTP

-required, # pas de domaines requis


-domain, # pas de suffixes de domaines definis
-only_local_domain, # non restreint aux domaines d
efinis

# inet_hosts - alternative utilisant BIND pour acceder au DNS


#inet_hosts:
# driver=bind, # utilise le pilote BIND interne
# transport=smtp; # delivrer par SMTP sur TCP/IP
#
# defnames, # recherche de domaines standard
# defer_no_connect, # essaie plus tard si serveur de noms en panne
# -local_mx_okay, # 
echoue (ne traverse pas) un MX vers
# # la machine locale

#
# base de donnees pathalias pour routage dans le domaine
domaine_paths:
driver=pathalias, # cherche l'h^
ote dans un fichier paths
transport=uux; # si trouv
e, delivrer par UUCP

file=paths/domaine, # le fichier est /usr/lib/smail/paths/domaine


proto=lsearch, # il n'est pas tri
e (recherche lin
eaire)
optional, # ignorer si le fichier n'existe pas
required=bibine.com, # ne rechercher que les h^
otes de *.bibine.com

#
# base de donn
ees pathalias pour routage hors de notre domaine
306 Annexe B. Exemples de chiers de con guration pour smail
monde_paths:
driver=pathalias, # cherche l'h^
ote dans un fichier paths
transport=uux; # si trouv
e, delivrer par UUCP

file=paths/monde, # le fichier est /usr/lib/smail/paths/monde


proto=bsearch, # il est tri
e par sort(1)
optional, # ignorer si le fichier n'existe pas
-required, # pas de domaines requis
domain=uucp, # supprime extension ".uucp" avant recherche

# smart_host - sp
ecification d'un directeur particulier vers le smart host
# Si l'attribut smart_path n'est pas d
efini dans
# le fichier /usr/lib/smail/config, ce routeur sera ignore.
# L'attribut transport est 
ecras
e par la variable globale
# smart_transport.
smart_host:
driver=smarthost, # pilote sp
ecial
transport=uux; # d
elivre via UUCP par d
efaut

-path, # utilise la variable smart_path du


# fichier config.

Le traitement du courrier pour les adresses locales est con gure dans le chier direc-
tors. Il est constitue de la m^eme maniere que le chier routers, avec une liste d'entrees
qui de nissent chaque directeur. Les directeurs ne delivrent pas de messages, ils ne
font qu'e ectuer toutes les redirections qui sont possibles, par exemple par les alias,
le renvoi du courrier, etc.
Lorsqu'il delivre un message a une adresse locale, comme dugenou, smail passe le
nom de l'utilisateur successivement a tous les directeurs. Si l'un d'eux correspond,
soit il speci era un transport a utiliser pour delivrer le courrier (par exemple, vers la
bo^te aux lettres de l'utilisateur), soit il generera une nouvelle adresse (par exemple,
en evaluant un alias).
Pour des raisons de securite, les directeurs e ectuent generalement un grand nombre
de tests pour veri er que les chiers qu'ils ont a utiliser sont ables et integres. Les
adresses obtenues d'une maniere douteuse (par exemple, depuis un chier aliases qui a
des permissions d'ecriture pour tout le monde) sont notees comme non s^ures. Certains
pilotes de transport elimineront de telles adresses, celui qui delivre un message dans
un chier en fait partie.
En dehors de cela, smail associe aussi un utilisateur a chaque adresse. Toute ope-
ration de lecture ou d'ecriture est e ectuee sous ce nom d'utilisateur. Pour delivrer
un message dans la bo^te aux lettres de dugenou, l'adresse sera bien s^ur associee a
l'utilisateur dugenou. D'autres adresses, comme celles obtenues a partir du chier
aliases, se voient associer d'autres utilisateurs, comme par exemple nobody.
Pour plus de details sur ce sujet, consultez la page de manuel de smail(8).

# Un exemple de fichier /usr/lib/smail/directors


307

# aliasinclude - expanse les adresses ":include:fichier" produites


# par les fichiers alias
aliasinclude:
driver=aliasinclude, # utiliser ce pilote sp
ecial
nobody; # acc
eder aux fichiers sous l'utilisateur
# nobody si adresse peu s^
ure

copysecure, # prend permissions dans directeur alias


copyowners, # prend propri
etaires dans directeur alias

# forwardinclude - expanse les adresses ":include:fichier" produites


# par les fichiers forward
forwardinclude:
driver=forwardinclude, # utiliser ce pilote special
nobody; # acc
eder aux fichiers sous l'utilisateur
# nobody si adresse peu s^
ure

checkpath, # test d'accessibilit


e du chemin
copysecure, # prend permissions dans directeur alias
copyowners, # prend propri
etaires dans directeur alias

# aliases - cherche les alias a


 traiter stock
es dans une base de donnees
aliases:
driver=aliasfile, # directeur g
en
eral pour les alias
-nobody, # toutes les adresses seront associees par
# d
efaut 
a nobody
sender_okay, # ne supprime pas l'expediteur dans l'expension
owner=owner-$user; # probl
emes diriges vers l'adresse du propri
etaire

file=/usr/lib/aliases, # compatibilit
e sendmail par d
efaut
modemask=002, # ne doit pas pouvoir ^
etre 
ecrit par tous
optional, # ignorer si le fichier n'existe pas
proto=lsearch, # c'est un fichier ASCII non tri
e

# dotforward - expansion des fichiers .forward des r


epertoires personnels
dotforward:
driver=forwardfile, # directeur g
en
eral pour les forward
owner=real-$user, # probl
emes dirig
es dans la bo^
te aux lettres
# de l'utilisateur
nobody, # utiliser le compte nobody si adresse peu s^
ure
sender_okay; # ne supprime pas l'exp
editeur dans l'expansion

file=~/.forward, # fichiers .forward dans repertoires personnels


checkowner, # l'utilisateur doit ^
etre proprietaire du fichier
owners=root, # ou alors il doit appartenir a root
modemask=002, # il ne doit pas pouvoir ^
etre ecrit par tous
caution=0-10:uucp:daemon, # ne rien ex
ecuter sous root ou daemon
# faire tr
es attention aux r
epertoires suivants:
unsecure="~ftp:~uucp:~nuucp:/tmp:/usr/tmp",

# forwardto - expanse une ligne "Forward to " au tout d


ebut d'une bo^
te aux
# lettres d'utilisateur.
forwardto:
driver=forwardfile,
owner=Postmaster, # erreurs dirig
ees au Postmaster
308 Annexe B. Exemples de chiers de con guration pour smail
nobody, # utiliser le compte nobody si adresse peu s^
ure
sender_okay; # ne supprime pas l'exp
editeur dans l'expansion

file=/var/spool/mail/${lc:user}, # les bo^


tes aux lettres sont par l
a
forwardto, # valide le test de "Forward to "
checkowner, # l'utilisateur doit ^
etre propri
etaire du fichier
owners=root, # ou alors il doit appartenir 
a root
modemask=0002, # sous System V, le groupe mail peut 
ecrire
caution=0-10:uucp:daemon, # ne rien ex
ecuter sous root ou daemon

# user - traite les utilisateurs locaux et leur bo^


te aux lettres
user: driver=user; # pilote recherchant les utilisateurs locaux

transport=local, # le transport local aboutit aux bo^


tes aux
# lettres des utilisateurs

# user - traite les noms d'utilisateurs pr


efix
es par la cha^
ne "real-"
real_user:
driver=user; # pilote recherchant les utilisateurs locaux

transport=local, # le transport local aboutit aux bo^tes aux


# lettres des utilisateurs
prefix="real-", # correspond par exemple, a real-root

# lists - expanse les listes de diffusions de dans /usr/lib/smail/lists


lists: driver=forwardfile,
caution, # teste toutes les adresses avec soin
nobody, # et leur associe l'utilisateur nobody
sender_okay, # ne supprime pas l'exp
editeur
owner=owner-$user; # le propri
etaire de la liste

# passe le nom de la liste de diffusion en lettres minuscules


file=lists/${lc:user},

Apres avoir reussi a router ou rediriger un message, smail le passe au transport speci e
par le routeur ou le directeur correspondant. Ces transports sont de nis dans le chier
transports. La encore, les de nitions sont composees d'un ensemble d'attributs globaux
et prives.
L'option la plus importante de nie par chaque entree est le pilote qui gere ce transport,
par exemple le pilote pipe, qui appelle la commande speci ee dans l'attribut cmd.
A c^ote de cela, un transport peut utiliser un certain nombre d'attributs globaux
qui e ectuent diverses transformations sur l'en-t^ete, et eventuellement le corps du
message. L'attribut return path, par exemple, demandera au transport d'inserer un
champ return path dans l'en-t^ete du courrier. L'attribut unix from hack permet de
rajouter le caractere devant chaque ligne du message commencant par le mot From.
>

# Un exemple de fichier /usr/lib/smail/transports.

# local - d
elivre le courrier local aux utilisateurs
local: driver=appendfile, # rajoute le message au bout d'un fichier
return_path, # rajoute un champ Return-Path:
309

from, # met une ligne From_ d'enveloppe


unix_from_hack, # ins
ere > devant toute ligne From dans le corps
local; # utiliser le format local

file=/var/spool/mail/${lc:user}, # les bo^


tes aux lettres sont par l
a
group=mail, # groupe propri
etaire du fichier en System V
mode=0660, # le groupe mail peut lire et 
ecrire
suffix="\n", # rajoute un saut de ligne

# pipe - d
elivre le courrier 
a des commandes shell
pipe: driver=pipe, # envoie le message par tube 
a un autre programme
return_path, # rajoute un champ Return-Path:
from, # met une ligne From_ d'enveloppe
unix_from_hack, # ins
ere > devant toute ligne From dans le corps
local; # utiliser le format local

cmd="/bin/sh -c $user", # envoie l'adresse au shell Bourne


parent_env, # environnement de l'adresse parent
pipe_as_user, # utilise l'utilisateur associ
e 
a cette adresse
ignore_status, # ignore une valeur de retour non nulle
ignore_write_errors, # ignore erreurs d'
ecriture (comme broken pipe)
umask=0022, # umask du processus fils
-log_output, # n'envoie aucune trace sur stdout/stderr

# file - d
elivre le courrier dans des fichiers
file: driver=appendfile,
return_path, # rajoute un champ Return-Path:
from, # met une ligne From_ d'enveloppe
unix_from_hack, # ins
ere > devant toute ligne From dans le corps
local; # utiliser le format local

file=$user, # le fichier est pris dans l'adresse


append_as_user, # utilise l'utilisateur associ
e 
a cette adresse
expand_user, # expanse ~ et $ dans l'adresse
suffix="\n", # rajoute un saut de ligne
mode=0600, # met les permissions 
a la valeur 600

# uux - d
elivre le message 
a la commande rmail du site UUCP distant.
uux: driver=pipe,
uucp, # utilise le style d'adressage UUCP
from, # met une ligne From_ d'enveloppe
max_addrs=5, # pas plus de 5 adresses par appel
max_chars=200; # pas plus de 200 caract
eres d'adresse

cmd="/usr/bin/uux - -r -a$sender -g$grade $host!rmail $(($user)$)",


pipe_as_sender, # les logs UUCP contiendront l'appelant
log_output, # sauve les erreurs pour messages de rejet
# defer_child_errors, # r
eessaie si uux retourne une erreur

# demand - d
elivre le message 
a la commande rmail du site UUCP distant,
# en appelant imm
ediatement.
demand: driver=pipe,
uucp, # utilise le style d'adressage UUCP
from, # met une ligne From_ d'enveloppe
max_addrs=5, # pas plus de 5 adresses par appel
max_chars=200; # pas plus de 200 caract
eres d'adresse
310 Annexe B. Exemples de chiers de con guration pour smail

cmd="/usr/bin/uux - -a$sender -g$grade $host!rmail $(($user)$)",


pipe_as_sender, # les logs UUCP contiendront l'appelant
log_output, # sauve les erreurs pour messages de rejet
# defer_child_errors, # r
eessaie si uux retourne une erreur

# hbsmtp - semi SMTP par lots. Les fichiers de sortie devront ^


etre
# trait
es r
eguli
erement, puis exp
edi
es par UUCP.
hbsmtp: driver=appendfile,
inet, # utilise le style d'adressage RFC 822
hbsmtp, # SMTP par lots sans HELO ni QUIT
-max_addrs, -max_chars; # pas de limite sur le nombre des adresses

file="/var/spool/smail/hbsmtp/$host",
user=root, # le fichier appartient a root
mode=0600, # lecture et ecriture seulement pour root

# smtp - d
elivre le courrier par SMTP sur TCP/IP
smtp: driver=tcpsmtp,
inet, # utilise le style d'adressage RFC 822
-max_addrs, -max_chars; # pas de limite sur le nombre des adresses

short_timeout=5m, # temps maxi pour operations courtes


long_timeout=2h, # temps maxi pour operations SMTP plus longues
service=smtp, # connexion sur ce port
# Pour utilisation sur l'Internet: supprimez les commentaires sur
# ces 4 derni
eres lignes:
# use_bind, # resout les enregistrement MX et multiples A
# defnames, # recherche de domaines standard
# defer_no_connect, # essaie plus tard si serveur de noms en panne
# -local_mx_okay, # 
echoue (ne traverse pas) un MX vers
# # la machine locale
311

Annexe C
Licence Publique Generale
GNU
Vous trouverez ci-dessous la Licence Publique Generale GNU (GPL ou copyleft), qui
protege Linux. Elle est reproduite ici pour preciser le statut des droits d'auteurs de
Linux, qui a parfois donne lieu a certaines confusions ; Linux n'est pas un partagiciel et
n'est pas dans le domaine public. Les droits du noyau appartiennent a Linus Torvalds
depuis 1993, et le reste des programmes appartient a leurs auteurs respectifs. Ainsi,
Linux est protege, mais vous pouvez toutefois le redistribuer sous les termes de la
Licence Publique Generale (GPL) reproduite ici.
LICENCE PUBLIQUE GE NE RALE GNU
Version 2, Juin 1991
Copyright c 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge,
MA 02139, USA. La copie et la distribution de copies verbatim de ce document est
autorisee, mais aucune modi cation n'est permise.

C.1 Preambule
Les licences d'utilisation de la plupart des programmes sont concues pour limiter ou
pour supprimer toute liberte de l'utilisateur. A l'inverse, la Licence Publique Generale
est destinee a vous garantir la liberte de partager et de modi er les logiciels libres,
et de s'assurer que ces logiciels sont e ectivement accessibles a tout utilisateur. Cette
Licence Publique Generale s'applique a la plupart des programmes de la Free Software
Foundation, ainsi qu'a tout autre programme dont l'auteur l'aura decide (d'autres
logiciels de la Free Software Foundation sont couverts pour leur part par la Licence
Publique Generale pour Bibliotheques GNU). Vous pouvez aussi utiliser les termes
de cette Licence pour vos propres programmes, si vous le desirez.
312 Annexe C. Licence Publique Generale GNU
Liberte des logiciels ne signi e pas forcement gratuite ;. notre Licence est concue pour
vous assurer la liberte de distribuer des copies des programmes, gratuitement ou non,
de recevoir le code source ou de pouvoir l'obtenir, de modi er les programmes ou d'en
utiliser des elements dans de nouveaux programmes libres, en sachant que vous y ^etes
autorises.
A n de proteger vos droits, nous avons d^u introduire des restrictions interdisant a qui-
conque de vous refuser ces droits ou de vous demander d'y renoncer. Ces restrictions
vous imposenten retour certaines obligations si vous distribuez ou si vous modi ez
des copies de programmes proteges par la Licence.
Ainsi, si vous distribuez des copies d'un tel programme, gratuitement ou non, vous
devez transmettre aux destinataires tous les droits que vous possedez ; vous devez vous
assurer que les destinataires recoivent le code source ou qu'ils peuvent se le procurer.
Vous devez leur remettre cette Licence a n qu'eux aussi connaissent leurs droits.
Nous protegeons vos droits de deux facons : d'abord par le copyright du logiciel, ensuite
par la remise de cette Licence qui vous autorise legalement a copier, distribuer et/ou
modi er le logiciel.
En outre, pour la protection de chaque auteur et pour la n^otre, nous voulons nous
assurer que chacun comprenne bien qu'il n'existe aucune garantie pour ce programme
libre. Si le logiciel est modi e par quelqu'un d'autre et redistribue ensuite, nous vou-
lons que tous ceux qui recevront ce logiciel sachent qu'ils ne sont pas en presence de
l'original, a n que les problemes introduits par d'autres personnes n'entachent pas la
reputation de l'auteur du logiciel original.
En n, tout programme libre est sans cesse menace par des dep^ots de licences. Nous
voulons a tout prix eviter que des distributeurs puissent deposer des licences de logi-
ciels libres pour leur propre compte. Pour l'eviter, nous stipulons bien que tout dep^ot
eventuel de licence doit prevoir expressement un libre usage pour tous.
Les dispositions precises et les conditions pour la copie, la distribution et la modi -
cation de nos logiciels sont les suivantes :

C.2 Stipulations et conditions pour copie, distribu-


tion et modi cation
La presente licence s'applique a tout programme ou autre travail contenant une in-
dication placee par le detenteur des droits precisant que ce programme ou ce travail
peut ^etre distribue selon les termes de cette Licence. Le terme (( programme )) designe
soit le programme lui m^eme, soit n'importe quel travail qui en est derive selon la
loi : c'est-a-dire un ouvrage contenant le programme ou une partie de celui-ci, que ce
soit a l'identique ou avec des modi cations, et/ou traduit dans une autre langue (la
traduction est consideree comme une modi cation). Chaque personne a qui s'applique
la Licence Publique Generale sera designee par le terme "Vous".
C.2. Stipulations et conditions pour copie, distribution et modi cation313
Les activites autres que la copie, la distribution et la modi cation ne sont pas couvertes
par la presente Licence et sortent de son cadre. Il n'y a aucune limitation a l'utilisation
du programme, et les donnees issues de celui-ci ne sont couvertes que si leur contenu
constitue un travail base sur le logiciel (travail independant ou realise en lancant le
programme). Tout depend de ce que le programme est cense faire.
Article 1. Vous pouvez copier et distribuer des copies conformes du code source
du programme, tel que vous l'avez recu, sur n'importe quel support,
a condition de placer sur chaque copie un copyright approprie et une
limitation de garantie, a condition de ne pas modi er ou omettre
toutes les stipulations se referant a la presente Licence et a la li-
mitation de garantie, et a condition de fournir avec toute copie du
programme un exemplaire de la Licence.
Vous pouvez demander une retribution nanciere pour l'acte phy-
sique de realisation de la copie, et vous ^etes libre de proposer une
garantie assuree par vos soins, moyennant nances.
Article 2. Vous pouvez modi er votre copie ou vos copies du programme ou
partie de celui-ci, ou d'un travail base sur ce programme, et copier et
distribuer ces modi cations selon les termes de l'article 1, a condition
de vous conformez egalement aux conditions suivantes :
a) Vous devez rajouter aux chiers modi es l'indication tres claire
des modi cations e ectuees, et indiquer la date de chaque chan-
gement.
b) Vous devez distribuer sous les termes de la Licence Publique Ge-
nerale l'ensemble de toute realisation contenant tout ou partie
du programme, avec ou sans modi cations.
c) Si le programme modi e lit des commandes de maniere interac-
tive lors de son execution, vous devez faire en sorte qu'il ache,
lorsqu'il est lance normalement, le copyright approprie en in-
diquant bien la limitation de garantie (ou la garantie que vous
vous engagez a fournir vous-m^eme), qu'il stipule que tout utili-
sateur peut librement redistribuer le programme les conditions
de la Licence Publique Generale GNU, et qu'il montre a tout
utilisateur comment lire une copie de celle-ci. (Exception : si le
programme original est interactif mais n'ache pas normale-
ment un tel message, tout travail derive de ce programme ne
sera pas non plus oblige de l'acher).
Toutes ces conditions s'appliquent a l'ensemble des modi cations. Si
des elements identi ables de ce travail ne sont pas derives du pro-
gramme, et peuvent ^etre consideres raisonnablement comme indepen-
dants, la presente Licence ne s'applique pas a ces elements lorsque
vous les distribuez seuls. Mais si vous distribuez ces m^emes elements
314 Annexe C. Licence Publique Generale GNU
comme partie d'un ensemble coherent dont le reste est base sur un
programme soumis a la Licence, ils lui sont egalement soumis, et la
Licence s'etend ainsi a l'ensemble du produit, quel qu'en soit l'auteur.
Cet article n'a pas pour but de s'approprier ou de contester vos droits
sur un travail entierement ecrit par vous, mais plut^ot de s'octroyer
un droit de contr^ole sur la libre distribution de tout travail derive ou
collectif base sur le programme.
En outre, toute fusion d'un autre travail, non base sur le programme,
avec le programme (ou avec un travail base sur le programme), qui
serait e ectuee sur un support de stockage ou de distribution, ne fait
pas tomber cet autre travail sous le contr^ole de la Licence.
Article 3. Vous pouvez copier et distribuer le programme (ou tout travail derive
selon les de nitions donnees a l'article 2) sous forme de code objet
ou executable, selon les termes des articles 1 et 2, a condition de
respecter les clauses suivantes :
a) Fournir le code source complet du programme, sous une forme
lisible par un ordinateur, et selon les termes des articles 1 et
2, sur un support habituellement utilise pour l'echange de don-
nees ; ou,
b) Faire une o re ecrite, valable pendant au moins trois ans, pre-
voyant de donner a tout tiers qui en fera la demande, une copie
sous forme lisible par un ordinateur du code source correspon-
dant, pour un tarif qui ne doit pas ^etre superieur au co^ut de la
copie, selon les termes des articles 1 et 2, sur un support cou-
ramment utilisepour l'echange de donnees informatiques ; ou,
c) Donner des informations sur l'endroit ou le code source peut
^etre obtenu (cette alternative n'est autorisee que dans le cas
d'une distribution non commerciale, et uniquement si vous avez
recu le programme sous forme de code objet ou executable avec
l'o re prevue a l'alinea b) ci-dessus.
Le code source d'un travail designe la forme de cet ouvrage sous la-
quelle les modi cations sont les plus aisees. Est ainsi designee la tota-
lite du code source de tous les modules composant un programme exe-
cutable, de m^eme que tout chier de de nition associe, ainsi que les
scripts utilises pour e ectuer la compilation et l'installation du pro-
gramme executable. Toutefois, une exception particuliere concerne
tout ce qui a trait a l'environnement standard de developpement du
systeme d'exploitation utilise (source ou binaire) comme les com-
pilateurs, bibliotheques, noyau, etc., sauf si ces elements sont aussi